Why We Built 13 Projects Before Selling One
We have thirteen projects on GitHub. A podcast automation pipeline with 763 tests. A UFC fight predictor with 878 engineered features. A swing trading bot. A dopamine detox app. A permits lookup tool. A Twitch bot. A real estate scraper. A budget tracker. A recipe API. A workout logger. A sentiment analyzer. A healthcare data pipeline from our time at Sift. This portfolio site.
Thirteen projects. Thousands of tests across all of them. Zero revenue.
We're not writing this as a success story. We're writing it because we think a lot of developers will recognize the pattern, and recognizing it is the first step toward doing something about it.
The Builder's Loop
We got into software through a side door. Our founder was a personal trainer — NASM certified, working with clients, building workout programs. He liked the systematic thinking more than the gym floor, so he started learning to code. That led to a data engineering role at Sift Healthcare, working on production ETL pipelines processing healthcare claims data. Real systems, real scale, real consequences when something broke.
After Sift, we started building side projects. The first few were learning exercises — a budget tracker, a recipe API. Normal stuff. But then we hit the pattern that would define the next year: we'd start a project, get deep into the engineering, ship something that worked, feel the dopamine hit of a passing test suite, and immediately start thinking about the next one.
The podcast pipeline is the clearest example. A friend needed help automating his show's production workflow. We built an audio ingest system, added Whisper transcription, integrated Ollama for show note generation, wired up FFmpeg for audio processing and clip generation, added multi-platform publishing to Spotify and YouTube. Then we made it multi-client ready with YAML-based configuration. Then we added video input support. Then per-client voice personas. Then a compliance checker after a YouTube copyright strike.
Forty-nine phases. Seven hundred sixty-three tests. A production system that genuinely works.
And then, instead of finding a second client, we started building a UFC fight predictor.
Why Builders Build
There's an honest answer and a comfortable answer. The comfortable answer is that we were "expanding our skills" and "building a portfolio." The honest answer is that engineering problems have clear solutions and we're good at them, while sales and marketing problems are ambiguous and we have no idea what we're doing.
Writing a feature engineering module that computes momentum stats from a fighter's last five bouts? We know how to do that. Cold-emailing a podcaster to pitch them on our automation service? That triggers a completely different part of the brain — the part that wants to go refactor something instead.
We think this is common in developers who come from technical backgrounds. The feedback loop in engineering is tight and rewarding. You write a test, it fails, you write code, it passes. You deploy, it works. You fix a bug, the error goes away. Every day you can measure progress.
Sales has no test suite. Marketing has no compiler. You send ten outreach messages and maybe get one reply that leads nowhere, and you can't git bisect your way to figuring out what went wrong.
We eventually had to be honest with ourselves: "getting clients is what we really struggle with." The engineering was never the bottleneck. The go-to-market execution was. And no amount of additional features would fix that.
The Turning Point
The realization wasn't dramatic. There was no rock-bottom moment. It was more like looking at our GitHub contribution graph one evening and doing the math: hundreds of commits across thirteen repos, at least a thousand hours of engineering work, and we couldn't name a single person who had paid us to use any of it.
We had a podcast pipeline ready for clients — the code was literally multi-client ready, with onboarding templates and per-client configuration. We had a permits app with Stripe integration and a pricing page. We had an ML system generating betting predictions with backtested profitability. The engineering was done. The products existed.
What didn't exist was a single customer.
What Changed
We made a deliberate decision to stop building and start selling. Not "after one more feature." Not "once we clean up the tests." Now.
For the podcast pipeline, that meant: it's a done-for-you service. We're not selling software — we're selling the outcome. You give us your raw audio, we give you a published episode with show notes, social clips, and multi-platform distribution. The pipeline is the infrastructure, but the product is "you don't have to think about post-production anymore."
For the permits app, that meant: the Stripe integration is live, the pricing page exists ($29/month for Pro), the free tier gates at five lookups per day. The code is complete. The only thing missing is traffic and conversion.
We also adopted a more disciplined approach to building itself. This portfolio site, for instance, is being constructed through a structured phased process — six phases, each with defined plans, success criteria, and verification steps. Not because the methodology is revolutionary, but because it prevents the thing we're most prone to: scope creep disguised as craftsmanship.
What We're Not Saying
We're not saying building is bad. Those thirteen projects taught us more than any bootcamp or degree program could have. We can architect a Python pipeline, train ML models, build React Native apps, deploy to Railway and Vercel and Fly.io, write hundreds of tests, and debug production systems at 2 AM. That's a real skill set, and it came from building real things.
We're also not going to pretend this is some "entrepreneur grindset" narrative. We didn't drop out of anything or risk our savings. We're a team that likes building things and needs to get better at the business side. That's a mundane, common story, and we think the mundane version is more useful than the mythologized one.
The Pattern
If you're a developer reading this and you've got five or six side projects on GitHub, each one technically impressive, none of them making money — we see you. The pull toward "just one more feature" is real, and it feels productive because it is productive. You're producing code. You're shipping commits. Your test coverage is going up.
But shipping code is not the same as shipping a product, and shipping a product is not the same as making a sale. Those are three different skills, and being excellent at the first one doesn't automatically develop the other two.
The podcast pipeline doesn't need more features. It needs five clients. The permits app doesn't need more endpoints. It needs traffic. The UFC predictor doesn't need more features. It needs a track record of profitable live bets. In every case, the next step is not engineering.
Where We Are Now
We have a portfolio site (you're reading it). We have a lead service that's production-ready. We have several other projects that demonstrate range and depth. The engineering side of our work is strong.
The sales side is a blank page, and that's where we're focusing now. Not because building stopped being interesting — it didn't — but because building without selling is an expensive hobby, and we'd like it to be a business.
Thirteen projects. Time to sell one.
Ready to build something that ships? See our work or book a free call.