At the start of 2025, I launched my first product to the public. Not a client project, not a prototype that lived on my laptop: a product of our own, built from scratch, with real people signing up. By the end of the same year, we had shelved it.
It wasn't a product nobody built properly, or a team that fell apart, or an idea nobody believed in. We had most of the things that are supposed to matter. It still didn't move forward. This post is my attempt to explain why, as honestly as I can, from the point of view of the person who was responsible for building it.
What we had
The product was a web and mobile platform for nutritionists and personal trainers: a place to prescribe meal plans and workouts, follow each client's progress and manage appointments, all in one app.
We were a good group of partners, each with a clearly defined role. I was the "CTO", in quotes, because the title is generous for a company that small. We had contacts inside the market we were going after. We built it from zero, launched it, and took the meetings that come after a launch. We even sat down with investors: conversations and negotiation, no money in the end, but real interest in what we had built.
If you had shown me that list before we started, I would have called it a good position to be in. Product, team, network, launch, investor interest. Most of the projects I had seen die didn't have half of that.
Where I thought the risk was
As the person building it, I thought the risk was mostly technical. Would the app be stable? Would payments work? Would it hold up once people used it for real? Those were the questions I spent most of my energy on, and they were the ones I knew how to answer.
Looking back, that was the most comfortable place to put the risk. It was the part I controlled. If the problem was technical, I could fix it with more work. I didn't have a plan for the case where the product worked and people still didn't come.
Where it stalled
Some people did come. A few professionals used the platform with their own clients on it. So it isn't true that the product didn't work for anyone. It just never reached the point where it could grow on its own.
We tried the usual channels: Meta Ads, Google, and direct contact with people in the niche. The problem wasn't that we picked the wrong channel. It was what the customer found on the other side of every channel: a market with established competitors who stood out more than we did.
And when people did try us, we ran into two things I had underestimated. The first was support. A professional who runs part of their business on your app needs answers quickly, and we fell short there. The second was features we simply hadn't thought of: the edge cases of real use, the things that only show up when someone's actual routine meets your product. Each one was small. Together, they were the difference between trying the product and staying on it.
None of that is a coding problem. I could have written better code, and nothing on this list would have changed.
How it ended
There was no single day when it died. The product faded slowly, and at some point a conversation between the partners made official what was already true. By the end of 2025, we put it on the shelf.
Being the "CTO" of something that clearly didn't work is a strange feeling. The part you were responsible for held up. The company didn't. And you start to see that the line between those two things was never as clear as you thought.
What I'd do today
If I started it today, I know where I'd begin, and it wouldn't be the code.
- Validate the thesis before building. Not whether people like the idea, but whether the market actually needs this product, from us, enough to switch from what they already use.
- Distribution from day one. Not as a phase that starts after the product is ready, but as part of the product. Who is going to hear about this, and why would they believe us?
- Positioning. In a market with established competitors, "we also do this" is not a reason to switch. Knowing exactly who it's for, and why it's better for them, is work that has to happen before the first ad.
- Build in public. Show the work while it's being done, so people can see it's good. Trust in a product often starts as trust in the people building it, and that trust takes longer to build than any feature.
- Support as part of the product. For someone running their work on your platform, how fast you answer is part of what they're paying for.
What I took from it
In my last post I wrote that at some point, writing code stops being the hard part. This was where I learned it the expensive way. We built the product. What we didn't build was a reason for anyone to choose it.
I still carry that into how I work on products today. Not as "engineers should do marketing," but as questions I ask much earlier than I used to: who is this for, how will they find it, and why would they trust it? Code can answer a lot of questions. Those aren't among them.
We built the product. Distribution was the product.