// blog /
I Shipped a SaaS by Myself. Here Is What It Actually Took.
- #saas
- #solo_dev
- #stripe
- #shipping
Everyone says ship. Far fewer people tell you what shipping a real SaaS involves once you are doing it alone, with no team to absorb the parts you are bad at. TextSpeakPro is the first product I took all the way, from a sentence to a live platform with paying customers, and this is the honest accounting of what that took.
The product is simple to describe. TextSpeakPro is an AI text-to-speech platform. You paste in text, choose a voice, and download a voiceover. The better voices sit behind paid plans. That description took an afternoon to land on. The product behind it took months.
Here is the first thing nobody tells you: the build is the easy part. AI coding agents are genuinely good at producing a working frontend, a backend, a database schema. What they are not good at, and what no demo ever shows you, is the connective tissue that turns a working app into a business. That tissue is most of the actual work.
Billing was the longest fight. Stripe is powerful and it is also genuinely confusing once you are in it. Test mode versus the newer sandboxes. Live data and test data living in completely separate worlds, so a product created in one is invisible in the other. Webhooks that have to be registered correctly or subscription status silently drifts. And a checkout flow that broke because one environment variable pointed at the wrong domain, so the redirect after payment landed users in the wrong place. None of that is hard once you understand it. All of it is invisible until it breaks.
Then there was the build-time problem, which cost me a genuinely confusing stretch. A static frontend bakes its environment variables in when it builds, not when it runs. I updated pricing in the dashboard, redeployed, and checkout kept charging the old prices. The new values were correct everywhere I looked. They just were not in the build that was live, because that build had been frozen with the old ones. The fix was not code. It was understanding when a value stops being editable.
Usage metering was the second real fight, and this one is a money problem. Every voice generation calls a provider, and that call costs real money the instant it fires. The naive way to build metering is to run the generation, then deduct the user’s credits. That leaves a hole: someone can trigger provider cost before the app ever accounts for it. The correct way is to reserve the usage first, before the provider call, and only then generate. I learned that from an audit, not from theory, and it is the kind of thing that does not show up until someone is exploiting it.
One more decision shaped everything: the product never names a vendor. Users do not care which company makes a given voice. They care about quality, speed, and price. So the product speaks in tiers, and the actual providers live in the backend and the legal pages. That sounds like a small thing. It is not. When a provider changed its pricing later, and one did, the customer-facing product did not have to change at all. Abstraction is not architecture astronautics. It is what lets a one-person product survive a vendor’s bad week.
It launched late one night in late February 2026. The next day it had its first signups. Not long after, its first paying customer. What it has done since is the part I actually care about: it has kept growing. Signups keep coming in, the paid subscriber base keeps building, and the line has stayed pointed up rather than spiking and fading. That steady growth proves the thing that actually matters: a stranger can land on the site, understand the product, trust the checkout, and pay, with no human in the loop, and then enough of them keep doing it that it adds up. That is the line between a demo and a business.
The post-launch reality taught me just as much. A real share of early monthly subscribers churned, and the detail that stuck with me is that some of them had paid for a higher tier and only ever used the free voices. That is not customers being foolish. That is an onboarding failure, and it was mine. They paid, nothing showed them what they had unlocked, and they decided it was not worth it. The product was fine. The first five minutes of using it were not.
So here is what shipping a SaaS solo actually took. It was not one heroic act. It was a few hundred small, unglamorous decisions about billing edge cases, abuse, metering, and onboarding, made correctly enough times in a row. The build was the easy twenty percent. The other eighty is the part nobody writes a thread about. Doing it once, all the way through, changed how I see every project since.