Chapter 00 — Introduction: we built an invoicing SaaS, and you can too
This is the story of FoxyInvoice — a real, live, multi-tenant invoicing SaaS — and a complete, step-by-step guide to building, hosting, securing, operating, and growing one yourself. Not a toy tutorial: the app this series documents sends real invoices, takes real payments through Stripe, calculates real US sales tax, and serves real users today at foxyinvoice.com. Its enterprise twin runs the books of an actual business at invoices.seolith.com.
Everything you'll read here happened. The bugs are real bugs. The costs are real costs. When we tell you a deploy once silently shipped stale code for eight hours while reporting success — that's a Thursday we lived, not a hypothetical. That's the difference between this series and most "build a SaaS" content: you get the postmortems, not just the brochure.
What you'll build (and learn)
By the end of this series you will understand, end to end:
- The stack and why each piece is there — Angular for the app, .NET for the API, Postgres for truth, a worker for everything slow, Docker to make it reproducible, one Caddy in front of it all. Boring on purpose: boring survives production.
- Multi-tenant data security — how thousands of businesses can share one database without ever seeing each other's invoices, enforced at the query layer and proven by tests.
- Deployment as a habit — push to
main, and eight minutes later it's live with health gates, secret scanning, and automatic rollback pressure. No staging server. No devops team. One person. - The economics — the actual monthly cost sheet, Stripe's take, what a free-tier user costs you (spoiler: almost nothing), and where the break-even lines really sit.
- The operating cadence — the 20-minute daily routine that runs the whole business: find people with the problem (Reddit, HN), read every piece of feedback, turn bugs into fixes into deploys into replies.
- Modern reach — why the AI crawlers (GPTBot, ClaudeBot, PerplexityBot) couldn't see client-side-rendered pages, and how being machine-readable became a growth strategy, not a chore.
Who this is for
You, if you can write some code and want to ship a product with it. We teach every term as it comes up — Git, UI vs UX, relational databases, REST APIs, DNS, TLS, Docker — always tied to the exact place it matters in this app. If you already know a term, skim; the why is usually still worth your time, because the why comes from an incident.
You do not need: a team, investors, a staging environment, or a budget beyond a coffee-priced VPS and a domain.
The honesty contract
Three rules this series lives by:
- Every claim is checkable. Numbers, dates, and behaviors come from the production system and its git history.
- Mistakes stay in. The six incidents in Chapter 13 are the most valuable pages in this series. You will make different mistakes; the shapes will rhyme.
- No fantasy scale. This is not a "how we got 100k users" story. It's a "how the machine works and what each part costs" story — the thing nobody writes because it isn't glamorous. It's also the thing you actually need before you have users to serve.
The tour
Before Chapter 1, watch the machine run: a visitor with no account picks an industry invoice template, fills it in, and their work auto-saves in their browser. They ask us to email it to them — we capture it, no signup required. When they're ready, one click carries that exact invoice into a new account as a real draft. A founder sends a quote link; the client approves it from their phone; a real invoice appears, ready to send with a payment link. Behind the screen: tenants isolated to the row, money stored as decimals never floats, deploys gated by tests, and a feedback widget that records the user's screen when words aren't enough.
That tour, diagram by diagram and gif by gif, is this series.