Going Independent: Notes From the First Stretch
I spent thirteen-plus years inside other people's roadmaps. Software engineer, then senior engineer, then technical director — owning architecture, hiring, and delivery for a multi-product line. It was good work. I led a team of twelve and shipped eight products. And then I left to build on my own.
People assume going independent is a leap. For me it was the opposite: it was the most conservative bet I could make. After enough years you stop wondering whether you can ship something real — you've done it, repeatedly, under deadlines that weren't yours. The only open question left was whether I'd point that ability at problems I actually chose.
Why now
The honest reason is that the gap between "an idea" and "a thing people pay for" collapsed. Applied AI didn't just give me a new feature to bolt on; it changed the unit economics of building. A single person can now stand up retrieval, evals, and a real product surface in the time it used to take to write a design doc. When the cost of trying drops that far, sitting still becomes the expensive option.
So I went heads-down on the place I find most interesting: where AI meets a real-world workflow that's quietly bleeding time. Not demos. Not slide decks. Production software that runs every day whether or not I'm watching.
What I'm shipping
VoltExam is an AI-powered exam-prep platform. It's live on the App Store with paying subscribers across seven verticals. The interesting engineering isn't the model call — it's everything around it: keeping question generation grounded, building evals so quality doesn't drift, and making the whole thing feel fast on a phone.
CapitalGains is a personal finance and tax companion, live on iOS and running in production daily. It started from a specific, unglamorous annoyance: figuring out real-estate capital gains in Canada without a spreadsheet held together with hope. That's the kind of problem I like — narrow, real, and easy to describe in one sentence.
If I can't name the annoyance in one sentence, it isn't ready to build.
What building in public has taught me
First: ship the smallest honest version, then let real usage argue with you. Every assumption I held tightly got corrected within a week of being in front of actual users. The roadmap I would have written in isolation looks nothing like the one usage handed me.
Second: treat AI like any other dependency you have to operate at 3am. The leverage is in the plumbing — retrieval, guardrails, knowing when a plain deterministic function beats a prompt. The model is a primitive now, not a moat.
Third: the director instinct doesn't switch off, and that's fine. I still set the bar, I just clear it myself now. The difference is the feedback loop. There's no committee between a decision and its consequence — which is terrifying and clarifying in equal measure.
I'm still in the first stretch. The products are live, the subscribers are real, and the open problems are more interesting than anything on a backlog I didn't choose. If you're building in the same space — applied AI, real workflows, software that has to actually run — I'd like to hear from you.
More writing
- Charge on Day One: What a Price Tag Taught a Solo Founder
- Boring on Purpose: The Tech Choices That Let One Person Sleep
- The Distribution Problem: Why Shipping Was Never the Hard Part
- The Smallest Honest Version: How I Decide What to Build
- The One-Person Stack: How a Solo Founder Covers a Team's Surface Area
- The Fallback Is the Feature: Designing AI That Never Hard-Fails
- The 2%: Why Edge Cases Decide Whether People Trust Your Product