15 Products Later, Here's What I'd Do Differently

Most products fail. That's not a cautionary tale -- that's just math. I built 15+ products over five years as CTO of my own startup. A restaurant workflow system, a quiz game, a hotel POS, a family tracking app, an ecommerce website builder, a browser, a game engine project, an emergency alert app, a Covid aggregator, an SSR framework, a CRM. The list goes on.

Out of all of them, maybe 3-4 were truly worth the time I put into them. The rest? They taught me things. Expensive lessons, paid in the only currency that doesn't come back -- time.

This isn't a list of humble brags disguised as "learnings." This is what I'd actually tell myself if I could go back to 2019, sitting in my room, registering Joahquin Technologies, convinced the next product would be the one.

The addiction to building

I didn't start 15+ products because I had a strategy. I started them because I was addicted to building. There's a specific high you get when something you imagined starts working on a screen. A login page. A dashboard. A real-time update. That dopamine hit is real, and it's dangerous.

Every time a product didn't take off, I didn't pause. I didn't ask hard questions. I just started the next one. New idea, new repo, new energy. The pattern was always the same -- excitement at the start, diminishing returns in the middle, quiet abandonment at the end.

I told myself I was iterating fast. Build fast, fail fast -- that's the playbook, right? But there's a difference between failing fast and building without direction. I was doing the second one and calling it the first.

The ones that taught me the most

Zillion Dines -- sales is the real product

Zillion Dines was the biggest bet. A full restaurant workflow system -- table management, kitchen display, billing, the works. Technically, it worked. The product was solid.

The problem wasn't the product. The problem was selling it.

Restaurant owners don't care about your tech stack. They care if the guy at the next table is using it. They care if it's cheaper than what they have. They care if you'll show up when the printer stops working on a Friday night.

I spent months building features nobody asked for, while the actual work -- walking into restaurants, talking to owners, understanding their real problems -- felt uncomfortable. I was an engineer pretending sales would happen on its own.

It didn't.

Zillion Dines taught me the hardest lesson: distribution is harder than product. Most products don't die because they're bad. They die because nobody knows about them. You can build the best restaurant system in the world, and it won't matter if you can't get 10 restaurants to use it.

Covid Tools -- the one that worked, sort of

In 2020, I built a Covid resources aggregator. Hospital beds, oxygen availability, testing centers -- all pulled together in one place. It got traction almost immediately.

Here's the thing though -- I didn't do anything special. The timing was right. People needed this, right now, and I shipped fast. That's it. No genius product insight. No brilliant marketing. Just the right thing at the right time.

That's luck. And I don't say that to diminish the work. The product was well-built and genuinely useful. But the honest truth is -- if I'd built the same aggregator six months earlier or a year later, nobody would have cared.

Most of the time, it's just luck. Talent and hard work put you in the game. Luck decides who gets on stage. Covid Tools worked because I was already building things constantly, so when the moment came, I could move fast. That's what "earned luck" means. You can't predict when the window opens, but you can make sure you're ready when it does.

The traction was temporary though. When Covid faded, so did the product. Another lesson -- timing giveth, timing taketh away.

StageX and the open-source rabbit hole

StageX was a dedicated single-page application server with built-in SSR. I also built 10+ open-source modules and frameworks around the same time. These were purely engineering projects -- built for the love of solving technical problems.

No market validation. No user research. No business model. Just "this is technically interesting, so I'll build it."

I'm not going to pretend I regret these. They made me a significantly better engineer. The depth of understanding you get from building a framework from scratch -- handling routing, rendering pipelines, server-side concerns -- you don't get that from using someone else's tools.

But let's be honest: these were for me, not for the market. I was scratching my own itch and calling it entrepreneurship. There's nothing wrong with building for yourself, as long as you don't confuse it with building a business.

Quizinga and Mace Hit -- fun, but zero

Quizinga was a quiz game based on trending content, TV shows, movies. Mace Hit was a jump-and-balance game built in Unity. Both were fun to build. Both had exactly zero market validation before I started.

I didn't talk to anyone. I didn't test demand. I just built because the idea was exciting. And when I shipped, nobody showed up. Not because the products were terrible -- they were decent. But I'd built solutions looking for problems, which is the most expensive mistake a builder can make.

If something is zero, it doesn't matter what number you multiply it with. I could have added more features, better graphics, slicker UX -- but the foundation was zero. Zero demand. Zero distribution. Zero feedback loops. You can't polish your way out of zero.

What I'd actually do differently

Validate before building

I was addicted to building, not to solving problems. Those are two very different things. Building feels productive. Validation feels slow and unglamorous. Talking to potential users, understanding their pain, checking if anyone actually wants what you're imagining -- that's the work most builders skip because it doesn't produce code.

If I could go back, I'd spend the first two weeks of every project talking to people instead of writing code. Not surveys. Not Google Forms. Real conversations. "What's your biggest problem with X?" and then shutting up and listening.

Stop multiplying zero sooner

I held on too long. Every single time. When a product had no growth after months, I'd tell myself it just needed one more feature, one more pivot, one more push. That's not persistence -- that's denial.

Growth being zero over time is a signal. The foundation is zero. No point multiplying further. The difficult part is telling the difference between "this needs more time" and "this is dead." I don't have a clean formula for it, but I now know one thing: if you've been pushing for 6 months and the trajectory is still flat, it's probably flat. Stop. Start something else. Your time is worth more than your ego.

Presentation and storytelling matter more than the product

This one hurt to learn. I spent years believing the product should speak for itself. Just build something great, and people will come.

They won't.

The world doesn't judge what something is -- it judges how something looks and feels. A mediocre product with great presentation will always outperform a great product with poor presentation. That's not cynicism. That's how humans work. We're wired for stories, not specs.

People buy stories, not products. Marlboro didn't sell cigarettes -- they sold a cowboy on a horse. Nobody buys a product for what it is. They buy the narrative around it. Logic convinces no one. Narrative convinces everyone.

I could have spent 20% less time on code and 20% more time on how I presented these products, and the outcomes would have been wildly different. Every demo, every landing page, every pitch -- I treated them as afterthoughts. They should have been the main event.

Distribution is the real product

This connects to sales. Everything is sales, and communication is the multiplier. Giving an interview? You're selling. Pitching a startup? Selling. Explaining why your product matters? Selling.

I built products in isolation. I coded in a room, shipped to nobody, and wondered why nobody showed up. The products that get traction aren't always the best ones -- they're the ones whose builders understood that getting the product in front of people IS the product.

If I did it again, I'd spend 50% of my time on distribution from day one. Not after the product is "ready." From day one.

Time is the real cost, not money

I didn't spend a lot of money on these 15+ products. Most were bootstrapped, built with sweat equity and late nights. But the time cost was staggering.

Five years. Thousands of hours. Time I can never get back.

Money comes back. Health can improve. Relationships can be rebuilt. But time only moves one way. Every hour spent on the wrong thing is an hour gone forever. The question isn't "can I do this?" but "should this get my time?"

Out of 15+ products, maybe 3-4 were truly worth it. The rest taught me things, sure. But if I'm honest, I could have learned those lessons in half the time if I'd been more ruthless about cutting losses early.

The uncomfortable truth

Most of those products were for me, not for the market. I built what I found interesting, not what people needed. I optimized for the engineering challenge, not the business outcome. I told myself I was an entrepreneur, but I was really an engineer who liked starting things.

That's not a crime. But it is expensive.

The uncomfortable truth about building 15+ products is that the volume doesn't make you a better entrepreneur. It makes you a better engineer. And that's exactly what happened. The breadth of experience -- backends, frontends, mobile apps, game engines, SSR frameworks, real-time systems, POS platforms, CRMs -- that's the reason I'm a Principal Engineer today.

Every "failed" product added a tool to the toolkit. Zillion Dines taught me about real-world systems and the unglamorous parts of shipping. StageX taught me how rendering pipelines actually work. Covid Tools taught me that speed and timing beat perfection. Even Quizinga taught me what happens when you skip validation entirely.

The failures weren't wasted. But the time cost was real, and I could have been smarter about it.

The bit that sticks

Losers fail less than winners. That's not a motivational poster -- it's math. The people who never fail are the people who never tried enough. Winners have a longer list of failures. They just didn't stop.

I have 15+ products on that list. Most of them didn't work. But they put me in the game. They gave me scars that no tutorial, no course, no book can give you. And when luck finally showed up -- it did, in the form of opportunities that recognized the breadth of what I'd built -- I was ready.

If you're building your 3rd or 7th or 12th thing and nothing has worked yet, here's what I'd tell you: don't stop building, but start building smarter. Validate first. Present better. Distribute harder. Cut your losses when the number is zero. And protect your time like it's the only thing you can't earn back.

Because it is.