Most MVP advice reduces to "don't over-engineer it." Correct, and dangerously incomplete. A small set of decisions made in week one are brutally expensive to reverse once you have production data and paying customers — and the teams that ship fast and survive are the ones who can tell those decisions apart from everything else.
The test is not "is this best practice." The test is reversal cost: what does changing this cost with live customers on the system? High reversal cost, decide carefully now. Low reversal cost, do the scrappiest thing that works.
We apply this test to our own product. TeleVox, our voice-AI SaaS, runs five production services answering business phone calls 24/7 — and is operated by one person. That is not heroics. It is compound interest on a handful of boring week-one choices, the same ones we make on client CRM and SaaS builds. Here is the list.
Decide carefully in week one
The data model
The UI of your MVP will be rewritten. The data model will be migrated — it is the one artifact that survives to Series A, so it deserves more care per hour than anything else you do in week one.
The specifics are unglamorous: created_at and updated_at on every table. Money as integer cents, never floats. IDs you won't regret (UUIDs are fine). A real migration tool from the first commit, so every schema change is code — no hand-edited production schemas. Each of these costs minutes now. Each becomes a multi-week project later, run against live data.
Tenancy
Put org_id on every table from day one, even if the MVP feels single-tenant. Retrofitting tenant isolation means touching every table, every query, and every cache key, with customer data live underneath you. It is the single most painful migration in SaaS.
TeleVox runs on Supabase Postgres with row-level security, which moves isolation into the database itself:
alter table calls enable row level security;
create policy tenant_isolation on calls
using (org_id = (auth.jwt() ->> 'org_id')::uuid);
With that policy in place, an application bug cannot leak one customer's calls to another — the database refuses. It is also the answer to the security questionnaire every enterprise prospect will eventually send you.
The honest exception: a genuinely single-user internal tool doesn't need this. But if there is any future in which two customers share the deployment, there is no cheaper moment than now.
Auth
Do not build auth. Pick a provider — Supabase Auth, Clerk, Auth0, whichever fits your stack — and spend your week-one attention on the parts that are hard to change later: user IDs that are stable and decoupled from email addresses, and a role model kept deliberately small. Owner, admin, member will carry you to Series A. A permissions matrix in week one is a warning sign.
Billing hooks, not billing
You do not need Stripe at MVP. You need the events that billing will eventually read, written from day one. TeleVox meters phone calls: every call writes a row with duration, direction, and outcome. When pricing evolved, billing became a query over data that already existed. Analytics and TCPA compliance read the same rows. The failure mode is deciding on usage-based pricing in month six and discovering you never recorded usage. That data cannot be backfilled.
The deploy pipeline
One command, migrations run automatically, a rollback path. If deploying is scary, you will deploy rarely, and rare deploys are how MVPs rot.
Statelessness is the other half. TeleVox's voice workers run as a fleet on Fly.io behind LiveKit's load balancing and hold no state that outlives them. A deploy is a replacement, not surgery. That property — boring, decided in week one — is most of the reason one person can operate the platform.
Keep scrappy on purpose
Everything below is cheap to reverse. Spending week one on it is how MVPs miss their window.
- Admin UI. Use the Supabase dashboard or a SQL console. Build an admin panel when support load forces you to, not before.
- Analytics. Saved queries, not a dashboard. A dashboard is one sprint whenever you want it; it can wait.
- Service count. Start with one deployable. TeleVox runs five services, but every split was forced by a real constraint — voice workers scale and deploy on a completely different rhythm than the web app. Split when a constraint forces you to; a speculative microservice architecture is the most expensive way to slow down a small team.
- Design system. A component library and Tailwind. The post-product-market-fit redesign happens regardless of what you build now.
- Kubernetes, multi-region, caching layers. No. Postgres is faster than you think. Add a cache when a measured number tells you to, and not a day earlier.
The asymmetry is the point: rewriting the analytics dashboard is a sprint. Retrofitting tenancy is a quarter.
The Series A test
Technical due diligence asks a predictable set of questions. Is customer data isolated? Can you ship quickly and roll back safely? Does the usage data behind your revenue metrics actually exist? Can a new engineer get productive in days? The week-one list above is precisely the set of things that produce good answers. The scrappy list is the set of things nobody in diligence will ask about.
This checklist is the backbone of how we run SaaS product development engagements, and the same discipline shapes our custom software work at any stage: find the decisions that are expensive to reverse, get those right, and be unapologetically scrappy about everything else.
If you're scoping an MVP and want a second pair of eyes on the decisions you'll be living with at Series A, talk to us. A week-one review is cheap. A tenancy retrofit is not.