Skip to content
~/ tommybuilt .dev

// blog /

I Shipped a SaaS by Myself. Here Is What It Actually Took.

by Tommy
  • #saas
  • #solo_dev
  • #stripe
  • #shipping

Everyone says ship. Almost nobody tells you what shipping a real SaaS involves once you are doing it alone, with no team to cover the parts you are bad at. TextSpeakPro is the first product I took all the way, from one sentence to a live platform with paying customers. Here is what that took.

The product is easy to describe. You paste in text, pick a voice, download a voiceover. The good voices cost money. That sentence took an afternoon to land on. The thing behind it took months.

The build was the easy part, and I mean that literally. AI agents are genuinely good at spitting out a working frontend, a backend, a database schema. The part they cannot help with, the part no demo ever shows you, is the connective tissue that turns a working app into a business. That tissue ate most of the months.

Billing was the longest fight by a mile. Stripe is powerful and it will also lose you for a week at a time. Test mode versus the newer sandboxes. Live data and test data sitting in separate universes, so a product you make in one is just invisible in the other and you sit there refreshing, wondering where it went. Webhooks that have to be wired up exactly right or subscription status quietly drifts out of sync and you do not notice until a customer emails you. And one checkout that broke because a single environment variable pointed at the wrong domain, so everyone who paid got bounced to a dead page. Once you understand any of it, it is easy. You just do not understand it until it is already on fire.

Then there was the build-time thing, which cost me an embarrassing afternoon. A static frontend bakes its environment variables in at build time, and a change you make later at runtime does nothing. I changed pricing in the dashboard, redeployed, and checkout kept charging the old numbers. Everything I could see said the new prices were right. They just were not in the build that was live. What I had to learn there was a property of how static sites work. A value gets frozen into the build at build time, and changing it in the dashboard afterward does nothing until you rebuild.

Usage metering was the second real fight, and that one is about money. Every voice generation calls a provider, and the second the call fires, it costs me real money. The obvious way to build the meter is to generate first and deduct the credit after. That leaves a gap a clever person can drive a truck through, racking up provider cost before the app ever charges for it. You have to reserve the usage first, then generate. I did not learn that from a tutorial. I learned it from a security audit, which is a polite way of saying I learned it the way you learn most of this stuff, by almost getting got.

One decision shaped the whole thing. The product never says a vendor’s name. Nobody paying for a voiceover cares which company made the voice. They care that it sounds good, comes back fast, and costs what they expected. So the product talks in tiers, and the actual providers live in the backend and the legal pages where they belong. Sounds like a footnote. It saved me later, when a provider changed its pricing out from under me and the customer-facing product never had to move.

It launched late one night at the end of February 2026. First signups the next day. First paying customer not long after. The part I actually care about is what has happened since, which is that it kept growing. Signups keep landing, the paid base keeps building, the line has stayed pointed up instead of spiking and dying. A stranger can find the site, get the product, trust the checkout, and pay, with no human anywhere in the loop, and then enough of them keep doing it that it adds up to something. That is the whole game.

Post-launch taught me as much as the build did. A chunk of my early subscribers churned, and the detail that still bugs me is that some of them paid for a higher tier and only ever used the free voices. For about a day I wanted to blame the customers. Then I looked at the onboarding, and the onboarding was mine. They paid, nothing on screen showed them what they had just unlocked, and they quietly decided it was not worth it. The product worked. People bounced in the first five minutes anyway, before it ever got to show them what they were paying for.

So that is what shipping a SaaS alone took. A few hundred small, boring, correct-enough decisions about billing edge cases and abuse and metering and onboarding, stacked up in a row until the thing could hold weight. The build was maybe twenty percent of it. The other eighty is the part nobody writes a thread about. Doing it once, all the way through, changed how I look at every project I have started since.

// keep reading