A Singapore founder hired a development agency in January. Their agreement was an 8-week MVP. It's November. The app is still not launched.
No malice involved. The agency is competent. The founder has good intentions. The problem is scope: every week, a new "critical" feature was added. Every addition seemed small. None were removed. The cumulative effect is a project that has been in development for 10 months and still isn't ready.
This is the most common failure mode for MVPs. It's not a development problem. It's a decision-making problem.
What An MVP Actually Is
The word "minimal" in Minimum Viable Product gets systematically ignored. What most founders actually build is a "Comprehensive First Version" — which is not an MVP, takes 3–5x longer, and usually teaches them the wrong things.
An MVP is the smallest product that:
- Solves a specific problem for a specific user
- Is complete enough that someone would use it (not just try it)
- Teaches you whether your core hypothesis is correct
It is not a demo. It is not a prototype. It is not a "version 1 with all the basic features." It is the literal minimum viable product — the one after which removing any feature would make it impossible for someone to solve their problem.
The Scope Decision Process
Before writing a single line of code, answer these three questions in writing:
Who is the specific user? Not "Singapore SME owners." A specific person. "A Singapore operations manager at a 10-person logistics company who is manually tracking deliveries on WhatsApp." The more specific, the better.
What is the one problem they have? "They don't know which deliveries are late until a customer calls to complain." One problem. Not five.
What is the simplest possible solution to that problem? A driver updates delivery status via a mobile form. The ops manager sees a dashboard with live status. An automatic alert goes out when a delivery is late. That's it. That's the MVP.
Everything else — route optimisation, customer portal, invoicing, driver management, reporting — is not the MVP. It may be the product eventually. It is not the thing you need to prove the hypothesis.
The 8-Week MVP Build Structure
If the scope is truly minimal and the tech stack is well-chosen, 8 weeks is achievable for a focused MVP. Here's how we structure it:
Week 1: Specification and architecture
User stories written. Data model designed. API endpoints defined. Tech stack confirmed. No code yet. This week exists to make sure weeks 2–8 are building the right thing.
Week 2–3: Foundation and auth
Database schema created. Authentication implemented (sign up, sign in, password reset, session management). Basic navigation structure. No features yet — just the bones.
Week 4–5: Core feature build
The primary user workflow. The thing that solves the problem. This is the heart of the MVP. Everything else is in service of this working correctly.
Week 6: Secondary features and integrations
Email notifications, any necessary third-party integrations, admin panel for the founder to manage the product. These support the core but aren't the core.
Week 7: QA and bug fixes
Structured testing. Real devices. Real users (the founder, team members, 1–2 test users). Fix what's broken. No new features.
Week 8: Launch preparation and deployment
Production deployment. Monitoring setup. Error tracking. Domain and SSL. App store submission if mobile. The product ships.
Week 9 onward: Real users. Real feedback. The next iteration is driven by what you learn, not what you planned.
The Tech Stack for Singapore MVP Builds
Speed to market matters more than perfect architecture at the MVP stage. What we use for Singapore MVPs:
Web app MVPs: Next.js + Supabase + Tailwind + Vercel. The fastest path from spec to production-ready web application with proper auth, database, and hosting in Singapore region.
Mobile app MVPs: Flutter + Supabase + Firebase/OneSignal. Cross-platform for both iOS and Android from one codebase. No separate native builds until you've proven the concept.
Avoid for MVPs: Microservices, Kubernetes, separate frontend/backend repos with a REST API in between, GraphQL, any ORM that requires significant configuration. All technically interesting. All slower to build than the alternatives. None appropriate before product-market fit.
The Scope Freeze Rule
For 8-week delivery to be achievable, scope must be frozen after Week 1.
This means: features added after Week 1 go into a backlog, not into the current build. No exceptions.
This is uncomfortable. Founders find it very hard to not add features when they come to mind. Every addition seems small and necessary. But the accumulation of "small" additions is precisely what turns 8 weeks into 10 months.
The discipline required: when you have a new idea during the build, write it in the backlog, evaluate it against your launch criteria (does the product solve the core problem without it?), and release it in the next iteration if it still seems important after launch.
Most ideas that seem critical during the build seem much less critical once real users are providing feedback.
What Singapore MVP Builds Cost
Realistic ranges for a focused, properly scoped MVP:
Simple web app (1 core workflow, no mobile, no complex integrations): S$15,000–S$28,000
Web app with basic integrations (email, payment, 1 third-party API): S$28,000–S$45,000
Mobile app MVP (Flutter, iOS + Android, Supabase backend): S$30,000–S$55,000
Web + mobile MVP: S$50,000–S$80,000
These are for a properly scoped MVP — not for a "complete product." Every feature beyond the minimum adds cost. The discipline of scope is where the budget is managed, not in the hourly rate.
The Question That Matters Most
Before spending any money on development, ask: how will I know if this MVP is successful?
If your answer is "when we launch," you don't have a success criterion. If your answer is "when we have 50 active users" or "when we have 3 paying customers at S$200/month" or "when we see users completing the core workflow without calling us for help" — now you have something to build toward.
MVP success criteria defined before building = a project with direction. MVP success criteria undefined = a project that never officially fails, never officially succeeds, and keeps running until the budget runs out.
At NICKTUNG, we define success criteria in the specification phase before writing code. It's what makes 8-week delivery achievable and meaningful.
Have an app idea that needs to be validated quickly? Let's talk about what a properly scoped MVP looks like for your specific problem.