In the last 12 months, we've launched 4 SaaS products from zero to production. Not prototypes. Not landing pages with waitlists. Real products with real users, real payments, and real infrastructure behind them. This post is about how we did it — the stack we chose, the process we follow, and the lessons we learned about shipping fast without cutting the corners that matter.
Our Stack and Why
Consistency is the single biggest accelerator when you're shipping multiple products. Every time you pick a new framework, a new database, or a new hosting provider, you're burning weeks of productivity on decisions that don't differentiate your product. Here's what we standardized on:
Frontend Vue 3 + Nuxt.js Backend PostgreSQL + FastAPI Payments Stripe AI Anthropic + Google + Microsoft Email Resend Hosting Containers + Cloudflare
Every choice here was deliberate. Vue and Nuxt give us SSR and static generation with minimal config. FastAPI is the fastest way to build typed Python APIs — and since our AI layer is Python-native, we avoid the serialization tax of crossing language boundaries. PostgreSQL handles everything from user data to vector embeddings. Stripe means we never touch payment card data. And Cloudflare gives us global edge caching without managing CDN infrastructure.
The Process
Week 1: Problem Definition
Before we write a single line of code, we spend a full week defining the problem. Not the solution — the problem. Who has this pain? How are they solving it today? What would “good enough” look like? We talk to potential users, study the existing tools, and write a one-page brief that everyone on the team can reference.
Week 2–3: Core Flow
We build the one thing the product must do. Not the dashboard, not the settings page, not the onboarding flow — the core action that delivers value. If it's a billing tool, that's generating and sending an invoice. If it's a screening tool, that's running a background check and returning results. Everything else is scaffolding.
Week 4–6: Complete MVP
Now we build around the core: authentication, billing integration, basic admin views, email notifications, and error handling. The goal is a product that a real user could sign up for, pay for, and get value from — even if it's rough around the edges.
Week 7–8: Polish & Launch
The final push: loading states, empty states, edge cases, mobile responsiveness, and the marketing site. We deploy to production, set up monitoring, and start onboarding early users. The product is live, but it's not done — it's just the beginning of the feedback loop.
What We Skip
- Lengthy specification documents — We write a one-page brief, not a 40-page PRD. If the problem can't be explained in one page, we don't understand it well enough yet.
- Pixel-perfect design upfront — We use a component library and iterate on design in code. Figma files that take weeks to produce are weeks we could be building.
- Feature parity with incumbents — We ship 20% of the features that solve 80% of the problem. The rest comes from user feedback, not assumptions.
- Custom infrastructure — We use managed services for everything. Databases, hosting, email, payments — if someone else can run it better, we let them.
- Multi-platform from day one — Web first. Always. Mobile apps come after we've validated the product and the demand.
What We Don't Skip
- Type safety — Every API contract is typed end-to-end. TypeScript on the frontend, Pydantic on the backend. This catches entire categories of bugs before they reach production.
- Auth & authorization — Security is not a feature you add later. Every product ships with proper authentication, role-based access control, and session management from day one.
- Payment processing — If the product has a price, Stripe is integrated before launch. We don't do “free for now, we'll figure out billing later.”
- Error handling & monitoring — Structured logging, error tracking, and uptime monitoring are part of the launch checklist, not a post-launch afterthought.
- Audit trails — Especially for our products in regulated industries, every significant action is logged with timestamps, user IDs, and context. You can't retroactively add compliance.
Lessons from 4 Products
- The stack matters less than you think — We've seen great products built on every framework. What matters is picking something and getting deeply proficient. Switching costs are measured in weeks, not features.
- Users forgive ugly, they don't forgive broken — A product that works reliably with a rough UI will outperform a beautiful product that crashes. Every time.
- Shipping is a muscle — The first product took us 10 weeks. The fourth took 6. The process compounds — reusable components, shared infrastructure, and pattern recognition all accelerate with each launch.
- Feedback loops beat planning cycles — Every hour spent planning beyond the first week is an hour that could have been spent learning from real users. Plans are guesses. Shipped code is data.
Shipping fast isn't about cutting corners — it's about knowing which corners don't exist yet. Build what matters, skip what doesn't, and let your users tell you the difference.
