Lessons Learned from Building a SaaS

The product worked long before the business did. That gap - between a thing that runs and a thing people pay for, renew, and tell their colleagues about - is where most of my hard-won lessons live.

Ship the boring version first

Our first paying customer signed up for a feature set I was embarrassed by. No SSO, no audit log, billing held together with a Stripe webhook and a prayer. They did not care. They had a problem that cost them hours every week, and we removed most of it. Every grand feature I delayed launch for turned out to matter far less than the one workflow that actually hurt.

Multi-tenancy is a decision, not a feature

We started with a shared schema and a tenant_id column on every table, enforced in application code. It was fast to build and a constant source of low-grade anxiety - one missing WHERE clause away from a data leak. If I did it again I would push isolation into the database with row-level security from day one, so the safe path is the default path rather than the disciplined one.

Churn tells you the truth

Sign-ups flatter you. Cancellations are honest. The month we started reading every cancellation reason out loud in the team standup was the month we stopped guessing what to build. Half of them were not product gaps at all - they were onboarding failures, people who never reached the moment the product became useful.

Build the smallest thing that delivers the core value, watch where people fall off before they reach it, and treat your billing and tenancy model as architecture rather than plumbing. The rest is iteration.