Ship Before You Scale: The Decisions That Waste Time and the Stack That Does Not
Ship Before You Scale
Most SaaS products die before they launch. Not because the idea is bad, not because the market does not exist, but because the developer spent four months building authentication infrastructure, a custom deployment pipeline, and a microservices architecture for a product that has zero users. The infrastructure is impressive. The product does not exist.
This book builds a SaaS product from blank repository to first paying customer. The product is Marketflow, a platform for farmers market and artisan market organizers to manage their operations. The decisions made along the way are not theoretical. They are the decisions a bootstrapped developer makes when the budget is their own money and the timeline is measured in weeks, not quarters.
The Product
Marketflow solves a real coordination problem. Farmers markets and artisan markets run on spreadsheets, email chains, and phone calls. A market organizer juggles vendor applications, stall assignments, weekly schedules, and payment collection across dozens of vendors. When the Saturday market has 30 vendors and a waitlist, the organizer is managing this in a Google Sheet with conditional formatting and a prayer.
Marketflow gives organizers a dashboard. Vendors apply through a public-facing page. Organizers review applications, assign stalls, set up recurring market days, and collect fees. Vendors see their bookings, upload required documents (insurance certificates, health permits), and pay through the platform.
The business model is freemium. Markets with up to 20 vendors use Marketflow for free. Markets with more than 20 vendors, or organizers running multiple markets, pay a monthly subscription. The free tier is not a trial. It is a permanent plan that handles small markets completely. The paid tier unlocks scale and multi-market management.
This is the product every chapter builds. No hypothetical examples. No “imagine a todo app.” A real product with real features, real billing logic, and real deployment concerns.
The Five Opinions
Every decision in this book passes through five filters. They are opinions, not universal truths. They apply to a specific situation: a single developer or small team, bootstrapped, shipping a product that needs to reach paying customers before the motivation or the savings account runs out.
Ship a Working Product Before Optimizing Anything
The correct order is: working, secure, fast, scalable. A SaaS that handles 50 paying customers on a single VPS is more valuable than a perfectly architected system that never launched. The urge to optimize is strong. The database query that takes 200ms instead of 20ms feels wrong. But if the product has three users, that query runs perhaps ten times per minute. The optimization that turns 200ms into 20ms will matter. It does not matter yet.
This does not mean writing sloppy code. It means choosing the path that reaches a working product fastest and deferring optimization until measurements prove it is needed. Chapter 11 covers performance. It comes after the product is built, deployed, and handling real traffic, because that is when performance problems become real problems rather than hypothetical ones.
Use What Exists
Supabase Auth handles authentication, JWT issuance, password resets, OAuth providers, and email verification. Writing this from scratch takes two to four weeks and produces code that is less secure, less tested, and less maintained than what Supabase ships. The correct decision is obvious.
Stripe Billing handles subscription creation, payment processing, invoice generation, proration, cancellations, and retry logic for failed payments. Implementing any of this custom is a mistake at this scale. Stripe charges 2.9% + $0.30 per transaction. On a $29/month subscription, that is $1.14. The alternative is building payment infrastructure, which is not what Marketflow is.
Resend handles transactional email. Configuring an SMTP server, managing deliverability, handling bounces, and maintaining IP reputation is a full-time job. Resend sends the email. That is the entire surface area.
The pattern repeats throughout the book. When a managed service or library handles the job, it is chosen. Custom code is written for the 10% that no service covers: the business logic of stall assignments, the vendor application review workflow, the market day scheduling rules. That is where developer time creates value.
Coding Assistants Are a Force Multiplier with a Failure Mode
This book treats GitHub Copilot and Claude as first-class development tools. They generate boilerplate faster than any developer types it. They produce working FastAPI endpoints, React components, and SQL migrations from a well-written prompt in seconds.
They also generate code that looks correct, passes a visual scan, and contains a SQL injection vulnerability because the prompt did not specify parameterized queries. They produce React components that work in development and break in production because the effect cleanup is missing. They write Stripe webhook handlers that process the event but do not verify the signature.
Chapter 3 establishes the review discipline. Every AI-generated code block passes through a checklist before it enters the codebase. The checklist is mechanical and non-negotiable. The speed of AI-generated code only compounds if the code is correct.
The Homelab Is for Development and Staging, Not Production
A homelab server running behind a Cloudflare Tunnel is a legitimate development environment. It provides a real Linux server, real Docker, and real network conditions without paying for cloud compute during development. Cloudflare Tunnel makes it accessible over HTTPS without a static IP or open firewall ports.
Production runs on a Hetzner VPS. The CX22 instance costs €4.51/month, provides 2 vCPUs, 4 GB RAM, 40 GB NVMe storage, and 20 TB of transfer. For a SaaS handling its first 500 customers, this is more than sufficient. The jump from “it works on my homelab” to “it runs in production” happens in Chapter 9, and the architecture built in the preceding chapters requires no changes to make that transition.
The homelab is useful. It is not production. Production means predictable uptime, a physical location you can disclose in a privacy policy, and hardware that does not go down because someone tripped over a power cable.
Stripe Is the Payment Infrastructure
Payments are not a feature to build. They are a liability to outsource. Stripe handles PCI compliance, payment processing, subscription lifecycle management, invoicing, tax calculation, and dispute handling. The SaaS developer’s job is narrow: create the right Stripe objects when users sign up, handle the webhooks Stripe sends when billing events occur, and keep the local database consistent with Stripe’s state.
Chapter 8 covers this completely. Every webhook is handled. Every edge case (failed payment, subscription downgrade mid-cycle, disputed charge) has a code path. The complexity is real but bounded.
The Stack
Every component in the stack was chosen for a specific reason. No component is included because it is popular or because a tutorial recommended it.
| Component | Role | Monthly Cost (Launch) | Why This One |
|---|---|---|---|
| Python 3.12 + FastAPI | API server | $0 | Async-native, auto-generated OpenAPI docs, Pydantic validation built in |
| React 18 + TypeScript | Frontend | $0 | Component ecosystem, type safety, TanStack Query for server state |
| PostgreSQL (Supabase) | Database | $0 (free tier) | Relational data with RLS for multi-tenant isolation, managed backups |
| Redis | Caching, rate limiting | $0 (self-hosted) | Session data, rate limit counters, background job queues |
| Supabase Auth | Authentication | $0 (free tier) | JWT-based auth, OAuth providers, no custom auth code |
| Stripe Billing | Payments | 2.9% + $0.30/txn | Subscription management, invoicing, webhook-driven billing |
| Cloudflare | DNS, CDN, Tunnel | $0 (free tier) | DDoS protection, SSL termination, Tunnel for homelab access |
| Cloudflare R2 | File storage | $0 (free tier, 10 GB) | S3-compatible, no egress fees, vendor document storage |
| Hetzner CX22 | Production VPS | €4.51/mo | European data residency, NVMe storage, predictable pricing |
| Coolify | Deployment platform | $0 (self-hosted) | Docker deployments, zero-downtime deploys, no vendor lock-in |
| GitHub Actions | CI/CD | $0 (free tier) | 2,000 minutes/month free, push-to-deploy pipeline |
| Resend | Transactional email | $0 (free tier, 100/day) | API-based email, no SMTP configuration, React email templates |
| Sentry | Error tracking | $0 (free tier) | Exception tracking, performance monitoring, source maps |
| Grafana Cloud | Metrics | $0 (free tier) | 10,000 series free, dashboards, alerting |
Total monthly cost at launch: €4.51. That is the Hetzner VPS. Everything else is free tier until the product generates enough revenue to justify paid plans.
The free tier of Supabase provides 500 MB of database storage, 50,000 monthly active users for auth, and 1 GB of file storage. For a SaaS at launch, this is generous. The point at which these limits matter is the point at which the product has revenue to cover the upgrade.
What This Book Is Not
This is not a software architecture textbook. The architecture is minimal and pragmatic: a monolithic FastAPI backend, a React SPA frontend, a PostgreSQL database. Microservices are not discussed because they are not needed.
This is not a startup advice book. There is no chapter on finding product-market fit, raising funding, or building a team. The assumption is that the reader has a product idea and the ability to build it. This book covers the gap between “I can write code” and “I have a deployed SaaS that processes payments.”
This is not a Python or React beginner guide. The reader knows how to write a function, build a component, and use a package manager. This book does not explain what a REST API is. It shows how to build one that handles authentication, validates input, processes payments, and runs in production.
The Build Log
The remaining thirteen chapters are a build log. Each chapter adds a feature to Marketflow. By Chapter 14, the reader has a working product: deployed on a Hetzner VPS, processing payments through Stripe, sending emails through Resend, storing files in Cloudflare R2, monitored by Sentry and Grafana Cloud, and serving real customers through a React frontend backed by a FastAPI API.
The order matters. The development environment comes first because every subsequent chapter depends on it. Authentication comes before the business logic because every endpoint needs it. The security baseline comes before payments because Stripe requires HTTPS and webhook verification. Deployment comes after the core product is built because deploying nothing is pointless.
Each chapter ends with a cost breakdown. At every point in the build, the reader knows exactly what this product costs to run. The numbers are real, pulled from the pricing pages of the services used. When a service’s free tier runs out, the book says so and states the cost of the next tier.