From Concept to Launch: The 5-Phase MVP Process We Use at VeltrexLabs

Most agencies keep their process vague. We don't. We've built MVPs for food-tech platforms, SaaS tools, e-commerce brands, mobile apps, and enterprise systems. Across all of them, five phases have emerged that — when done in order and without shortcuts — consistently produce products that launch on time and survive real users.

Here's exactly what we do, and why each phase exists.

Phase 1: Discovery (Week 1–2)

Discovery isn't a kickoff call. It's a structured process for turning a business idea into a buildable specification. We spend the first two weeks doing nothing but asking questions, mapping user flows, and challenging assumptions.

We ask every client three questions at the start of discovery: Who is the first user? What is the one thing they must be able to do? What does failure look like in 6 months?

The answers to those three questions shape everything. If a client can't answer question one precisely — not 'small business owners' but 'a 35-year-old restaurant owner in Gujarat with 4 staff and no POS system' — discovery isn't over yet.

What we produce in Discovery

• A prioritized feature list with Must Have / Should Have / Won't Have
• User flow diagrams for the core journey
• Technical architecture proposal with rationale
• Timeline and budget allocation across phases
• Risk register: what could delay launch and how we'll mitigate it

Phase 2: Design (Week 2–4)

Design at the MVP stage is not about beautiful. It's about clear. Every screen should answer one question: what does the user do next? If a user has to think, the design failed.

We design in Figma with full interactive prototypes before development starts. This is non-negotiable. A click-through prototype takes two days to change. A built feature takes two weeks. If we're going to find that a flow doesn't work, we want to find it in Figma.

What we do — and don't do — in Design

• We do: complete wireframes for all MVP screens
• We do: high-fidelity designs for the core user journey
• We do: component library in Figma that developers build from
• We don't: spend time on brand exploration — that's pre-engagement work
• We don't: design screens that aren't in the MVP scope, even if they're 'quick'

Design review is a client checkpoint. Nothing goes into development without sign-off. Not because we're covering ourselves — because building the wrong thing is the most expensive mistake in software.

Phase 3: Build — Backend First (Week 3–7)

We start building backend before the frontend is done. The data model, API structure, and auth layer are the foundation. If those are wrong, everything built on top of them is wrong. We don't rush the database.

Our typical MVP backend stack: Next.js API routes or Node.js (Express/Fastify) for the API layer, PostgreSQL with Prisma for the database, Supabase or Firebase Auth for authentication, S3-compatible storage for media. We containerize from day one — not as a DevOps exercise, but because it eliminates 'works on my machine' issues that destroy momentum.

Frontend development principles

Frontend work runs parallel to backend from week 4. We build with real API endpoints — never mocked data — from the moment they're available. Design systems are strict: developers work from the Figma component library, not from memory or personal preference.

Phase 4: QA and Testing (Week 7–9)

QA is not an afterthought. It's a dedicated phase with a dedicated checklist. We test on real devices, in real network conditions, with real user data volumes. We deliberately avoid testing only the happy path — we spend equal time on error states, edge cases, and failure conditions.

1. 1.Functional testing: every user flow works end-to-end
2. 2.Cross-device testing: mobile, tablet, desktop — all form factors in scope
3. 3.Performance testing: time to interactive under 3s on a mid-range device
4. 4.Security review: auth flows, input validation, API endpoint protection
5. 5.Accessibility baseline: keyboard navigation, contrast ratios, screen reader basics

We give clients access to a staging environment during QA. Their feedback during this phase — not after launch — is when changes are cheapest.

Phase 5: Launch and Handoff (Week 9–12)

Launch week isn't just flipping a switch. We prepare a launch checklist that covers infrastructure, monitoring, error tracking, analytics, and rollback procedures. We've seen too many products fail at launch because the infrastructure wasn't ready for traffic — not because the code was bad.

• Production environment provisioned and load-tested
• Error monitoring configured (we use Sentry)
• Analytics wired up (GA4 or Mixpanel depending on product type)
• Domain, SSL, and CDN configured
• Backup and recovery procedures documented
• On-call procedure agreed: who gets paged if something breaks in the first 48 hours

What Handoff Looks Like

Handoff is a live session, not a document drop. We walk the client's team through the codebase, the deployment pipeline, the database schema, and the admin tooling. We record it. We write a runbook. If a client can't maintain their product without us after handoff, we haven't done our job.

Why This Process Works — And Why Agencies Skip Parts of It

Each phase exists because we've experienced the cost of skipping it. Compressed discovery leads to features nobody needed. Skipped design review leads to rebuilt screens. Rushed QA leads to launch-day crashes. Skipped handoff leads to clients who can't iterate without calling us.

Agencies skip these phases because they're not billable in the way coding is. But they're the difference between a product that launches and one that dies on the runway.

“Speed in software development doesn't come from cutting phases. It comes from doing each phase well enough that you don't have to redo it.”