Most MVP conversations a founder has go the same way. A big agency wants a quarter and a budget you cannot justify. A marketplace freelancer shows up, disappears, and reappears two weeks late. Somewhere in the middle there is supposed to be a senior team that actually ships — and that is what we built TrioMav to be.
Our default engagement ships a production MVP in four to six weeks. Scope is shaped around your budget, not a fixed template. Here is exactly what happens, week by week.
The scope week comes before any engineering
Every engagement starts with a scope week. Five working days, one kickoff call, and at the end you have a 6–10 page scope document you can show investors, lawyers, or a future acquirer. The scope document contains:
- Who the product is for — one or two user personas, not six
- The five to seven core screens and the flows between them
- The data model — tables, relationships, and sample records
- The full tech stack we will use, named and versioned
- Delivery timeline broken into weekly milestones
- A realistic budget band, shaped around what you told us you can spend
The scope week exists because we have seen too many MVPs fail not because the engineering was bad but because everyone had a slightly different idea of what was being built. Writing it down makes disagreements visible when they are still cheap to resolve.
If, at the end of the scope week, we decide the engagement is not a fit — too large, too small, outside our stack — we part ways professionally. You keep the scope document. You can take it to any other developer.
Week two is design and plumbing, not features
In week two we do the infrastructure work that nobody likes but everything depends on:
- GitHub repo created in your organisation
- Next.js scaffold with the latest App Router, TypeScript, and Tailwind
- PostgreSQL database on Supabase or Neon
- Auth with Clerk or NextAuth
- Transactional email with Resend
- Payments with Stripe in test mode, switched to live at launch
- Hosting on Vercel, connected to your domain
- Observability — Sentry for errors, basic product analytics
- CI/CD — every pull request gets a preview deployment
By the end of week two, the staging URL exists and shows a "hello world" with a real auth flow. No product features yet, but the rails are laid.
This is also when we finalise design. You have three options: bring your own Figma and we build from it, use our starter design system (a minimal institutional-clean look that works for most B2B and consumer products), or have our designer do bespoke work. We adapt to what you bring.
Weeks three and four are sprints with mid-sprint demos
With rails in place, feature development moves fast. We work in one-week sprints with two checkpoints per week:
- Wednesday: mid-sprint demo. A Loom video showing what was built, what is in progress, and what blockers exist. You respond in writing.
- Friday: end-of-sprint review. The deployed product in your browser. Twenty-minute call. Agree what ships next week.
We default to four sprints for a single-sided MVP, six for two-sided marketplaces, and eight for AI-native products. The scope document sets the pace — if we said four weeks, we ship in four weeks. If a feature is genuinely harder than estimated, we either cut scope with your agreement or eat the extra week ourselves.
The single-sprint cadence matters because it keeps you surprised only by things you can do something about. A founder who sees product every Friday cannot be told in week four that the direction was wrong in week two. Feedback is tight, corrections are small.
The last week is launch, not just "deploy"
The final week — four, six, or eight depending on scope — is not another build sprint. It is specifically:
- Final QA against the scope document
- Performance audit — Lighthouse 95+ on mobile is the target
- Security audit — headers, secrets, auth edge cases
- Documentation — a 12–20 page runbook covering how to deploy, how to debug, how to add a new feature, who to contact at each service we integrated
- Handover meeting recorded on Loom, with your successor developer in attendance if you have one
- Thirty days of post-launch bug-fix support, included
We have strong opinions about handover documents. A good handover is the difference between a product you own and a product you rent. Ours covers not just the architecture but the thinking — why we chose Supabase over Firebase, why we did not ship a native mobile app yet, why the auth flow goes through Clerk instead of rolling our own. Any mid-level React developer should be able to read it and pick up where we left off.
About budget — why we don't publish a price list
You will notice we never quote fixed dollar amounts in our public content. That is deliberate. Real engineering cost depends on real scope, and we would rather shape scope to your budget than force your budget to fit a template.
In practice, this works the same way every time. You tell us your budget range and your requirement in one message. We respond within four business hours with what is achievable inside that budget, what would require cutting, and what would require expanding. No sales calls, no quote-chasing, no multi-round negotiation. If our floor is higher than your ceiling, we say so immediately and it saves us both time. If it is not, everything from there is fast.
Where this process breaks
This is not the right process for every kind of product. Specifically:
- If you need native iOS and Android as the primary surface, not a web app, four weeks is not enough. We quote six to ten for mobile-first work.
- If the AI feature is the entire product (not just one feature), the scope week alone usually needs two weeks of exploration.
- If you have two or more co-founders still disagreeing on what the product is, no engineering process will save you. We tell you to come back when you agree.
For everything else — the standard founder-with-an-idea-that-needs-shipping case — this is what we do, week in and week out. If you are in that position, send us a scope request with a two-line description of what you want to build and what budget you have in mind. We will respond within four business hours with whether we can help, what is achievable, and when we can start.