SaaS MVP development

## what this is

a first version that can charge real money and handle real users. not a prototype with billing stubbed out. not something that needs a full rewrite before you can hire a second developer. the infrastructure that every SaaS needs — auth, subscriptions, transactional email — done before the core feature, not after.

## why it matters

the shortcuts that feel fine in week one tend to be the things that block every feature six months later. hardcoded user IDs, missing error handling, billing wired in "temporarily" — they don't get cleaned up, they get worked around, and the workarounds accumulate. building the plumbing properly at the start is almost always faster than fixing it after users are already in the system.

## how I work

• scope is the first deliverable. the hardest part of an MVP is deciding what's not in v1. I'll push back on anything that can ship later and make the case for the things that have to be there before you collect money. you should leave the scoping call knowing exactly what gets built and what doesn't.
• billing and auth before the core feature. stripe subscriptions and user management are load-bearing. building the exciting feature first and bolting these on at the end means retrofitting them — which takes longer and usually leaves gaps.
• one feature end-to-end before the next one starts. you see working software every few days, not a big reveal at the end of the project.
• written to be handed off. I write the code assuming someone else — or a future version of you — needs to understand it without a call from me. no framework magic, nothing that requires a long explainer to work with.

## stack

next.js, typescript, postgresql with drizzle, clerk or better-auth for authentication, stripe for subscriptions, vercel, resend for transactional email.

## what you get

• auth: sign up, login, password reset, email verification, invite-only mode if needed
• billing: stripe subscriptions, upgrade/downgrade, customer portal for self-serve changes
• core feature set scoped to what the first paying users actually need
• a codebase structured enough that a second developer is productive within a day
• basic usage data so you know what's getting used before you plan v2

## get in touch

tell me what you're building and who the first ten users are. the more specific you can be about who's paying and why, the faster we can work out what the MVP actually has to include.