Entrepreneurship
A Real Problem Is Not Automatically an Urgent One
I had been carrying the idea since college, when I built a chatbot to help students learn programming with Scratch. The technology was rudimentary. I used the Rasa framework, which at the time was still fairly limited, but the underlying interest stayed with me.
I have always been curious about how people learn, especially through active practice rather than passive consumption. I was drawn to microlearning because it could turn learning into a sequence of small decisions and actions instead of a long block of content someone was expected to absorb.
When LLMs became capable enough to make the original idea more realistic, I saw an opportunity to finally test it. The technology was no longer the main obstacle. The unanswered question was whether the problem was important enough for someone to buy a solution.
Going all in without validation
I decided to leave my job and go all in, but I did not make the decision casually. I assessed the financial, career, and market risks first, thought through the downside of entering without a customer, and defined what I wanted to learn from the experience. I knew I was accepting uncertainty within boundaries I had examined, not jumping into it blindly.
What I had not done was validate the market. I was answering two questions: could I build this, and would people want it? I had underestimated a third question that would matter much more: would someone need it urgently enough to buy it now?
The first version: academic education
I started with a small Slack app built with Slack's Block Kit. The idea was to bring short learning interactions into a tool people already used, rather than ask them to open another platform. I showed the prototype to professors and people connected to the academic world.
The feedback was positive. People understood the idea, saw why it could be useful, and some were genuinely enthusiastic about it. That was encouraging, but it did not answer whether a university or school would actually buy it.
During those conversations, I learned something I had not understood before: selling software to universities was bureaucratic and slow, and getting a university to test a new platform was particularly difficult. That did not mean the idea was bad. It meant the buying process did not fit the constraints of a small founder trying to validate a product. The idea resonated, but the route to purchase did not, so I changed direction.
The second version: corporate learning
I adapted the prototype for corporate learning and started the process again. The feedback was still positive, and people could imagine using the product, but the conversations also exposed a serious constraint. I was told that in a crisis, this would probably be one of the first things cut from the budget. It was useful without being essential, which meant it was not connected to an urgent enough problem.
That was a more important signal than whether people liked the demo. A product can be valuable in theory and still lose every budget discussion against something more urgent. This was the second time I confused interest with demand.
The third version: compliance
I moved into security and compliance because it seemed like a stronger direction. Compliance training is mandatory, regulated, and connected to audit requirements, while better policy understanding can help a company become safer in its day-to-day work. I thought that combination would make the problem more urgent.
By then, the product had also changed from the original idea. It was no longer exactly microlearning. An administrator could define how often short, policy-grounded questionnaires should be sent, and employees could answer them inside the Slack app in less than a minute. The goal was to bring training into the flow of work instead of making employees leave that environment for a third-party learning platform.
That could help both sides. The company would become safer and get better evidence of how policies were handled, while employees would have a better chance of knowing what to do in concrete situations instead of merely completing a course and moving on.
Compliance also raised the technical bar for the LLM. In an educational product, a flawed generated explanation would still be a serious quality problem. In compliance, an invented policy requirement or an unsupported answer would be unacceptable. I needed to know exactly where each piece of text came from.
The model could help interpret the material, but every scenario needed to be grounded in the source policy, with traceable citations. A plausible answer was not enough. The system had to preserve the connection between the generated content and the exact text that supported it.
I also needed a more resilient system and a trustworthy evidence model. I worked on making records tamper-evident, using an independent timestamp authority, and preserving evidence in ways that could be verified outside the application itself. The goal was not simply to record that an interaction happened. It was to establish what happened, when it happened, and whether the evidence could be trusted later.
The product became more robust, and the feedback was still positive. The urgency was still missing.
The issue was not that companies did not care about whether employees understood their policies. That would be an unfair interpretation. The issue was that existing audit incentives mostly rewarded proof that training had been completed. In many cases, a completion record was accepted as sufficient evidence.
A stronger measurement of understanding could be valuable, but it was not always necessary for the buyer to pass an audit. The problem existed, but the current process was good enough.
Three signals I had confused
By this point, I had talked to more than 50 people across education, corporate learning, and compliance. I kept hearing positive reactions, but I learned that several signals that look similar from a distance are completely different in practice.
Resonance means people understand the problem and recognize why the idea could matter.
Product validation means there is evidence that the product solves a real problem in an actual workflow. People use it, return to it, adopt it, or take concrete steps to make it part of their process.
Purchase intent means someone is willing to spend budget, involve the right people, navigate procurement, or commit to a pilot.
These signals can exist independently. People can agree that a problem matters without changing their behavior. They can like a product without prioritizing it. They can want the outcome without being willing to buy the proposed solution.
I had found resonance. I had not found enough urgency or purchase intent to justify continuing, so I decided to stop.
I changed the question
After Svelto, I had another product hypothesis around architectural analysis. This time I wanted to find out whether I had actually learned the lesson, so I defined the kind of organizations that might need it and spoke with people who matched that profile before building a product.
The pain was real, but the urgency to buy a solution was not strong enough. I decided not to pursue it as a commercial product.
Later, I built Maat and released it as an open-source portfolio project. That was a different decision. I was no longer investing in a business hypothesis. I was creating a public technical artifact that demonstrated how I think and what I can build.
I was not claiming product-market fit. I had changed the objective and therefore the success criteria. The first experience taught me not to confuse positive feedback with demand. The second showed me that I could apply the lesson.
The technical lesson
There is a technical lesson in this story as well. I kept the architecture extensible enough that each pivot was relatively cheap, and it gave me room to defer decisions until I had more data. Across the different versions, I could change the system and have a new version ready to validate in roughly three days.
That kind of optionality mattered more than anticipating every future requirement. The architecture was valuable because it preserved my ability to change direction without turning every new piece of market information into a rewrite.
This changed how I think about early product architecture. The goal is not to build the smallest possible thing with no structure, and it is not to build the final platform before the market exists. The goal is to create enough structure that learning remains cheap and later decisions remain available.
What I took with me
The first lesson was that positive feedback is not validation. Feedback is useful, but it has to be interpreted correctly. Interest is evidence that someone understood the idea. It is not evidence that they will use it, budget for it, or buy it.
The strongest signals were concrete next steps: a specific workflow, an internal champion, a request for a pilot, a procurement conversation, or a willingness to allocate money and time. The conversation mattered, but what happened after the conversation mattered more.
Not all feedback was positive, and some of the most useful feedback was difficult to hear. When you are emotionally invested in an idea, it is easy to experience criticism of the product as criticism of yourself. I had to learn to separate the two. A hard comment about the work is not necessarily a personal attack, and treating it that way only makes it harder to learn from it.
The feedback, especially when it was direct, shaped both the product and the idea. I learned to treat it as information instead of as an objection to overcome. When different groups repeatedly told me that urgency was missing, the right response was not another feature or another pivot. It was to accept what the evidence was saying.
As a software engineer, I already knew the rule: do not build extensively before validating the problem. I understood it intellectually, but I still had to learn it through my own decisions. Building a product also taught me how to communicate with potential customers more effectively, ask better questions, and make product decisions with incomplete information.
Apparently, I had a talent for finding problems that were real but optional. At least I stopped confusing that talent with a reason to keep building.
Why I still consider it worth doing
I went all in for two reasons. The first was personal. This was an old idea I had wanted to explore since college. The second was professional. I wanted direct exposure to customers and to the entire process of turning a problem into a product.
I had spent years going deep into engineering and architecture. I wanted to understand what changed when I was also responsible for finding the problem, explaining the value, and deciding whether the problem deserved more investment.
I did not get the outcome I wanted, but I left with considerably more experience than I had when I started. Building Svelto did not make me less interested in engineering or less willing to work with product teams. It made me more deliberate about the problems I choose to solve, and more appreciative of strong product partnership.
I still want to work deeply on backend systems and architecture. I just have a broader understanding of what it means to build the right thing.
A real problem is not automatically an urgent problem, and a positive reaction is not a reason to keep building.