Multi-tenancy
If you will serve organisations rather than individuals, decide the tenancy model now. Retrofitting it is among the most expensive rewrites in software.
The short answer
An MVP should do one job completely: prove that a specific group of people will take a specific action, ideally including paying. Build that loop properly on production infrastructure, instrument it so you can measure the result, and cut everything else.
The common mistake is horizontal thinning — implementing 30% of every planned feature. That produces a product that is bad at everything and proves nothing, because users abandon it for reasons you cannot attribute.
Define the one thing you are testing
Before writing a feature list, write the sentence you want to be able to say in twelve weeks. Something like: 'Independent clinics will pay a monthly fee for automated appointment reminders.' That sentence tells you what to build and, more usefully, what not to.
If you cannot write that sentence, you are not ready to build. You are ready to talk to more potential customers, which is considerably cheaper.
What belongs in v1
- The core loop — the sequence that delivers the value, from start to finish, working properly.
- Authentication, built correctly the first time, because retrofitting identity is unpleasant.
- Payment, if the thing you are testing is whether people will pay. If it is not, defer it.
- Analytics and event tracking, because an MVP without measurement teaches you nothing.
- Basic admin tooling, or every support request becomes an engineering task.
- Production deployment on real infrastructure that can take real users.
What to cut, almost always
| Commonly built in v1 | Why it can wait |
|---|---|
| A second user type | Doubles the surface area; prove the first one wants it |
| Settings and preferences | Choose sensible defaults; add options when users ask |
| Notifications beyond the essential | Each channel is separate work and separate testing |
| Onboarding tours | Fix a confusing interface instead of narrating it |
| Integrations you 'might need' | Build the one a customer has actually asked for |
| Native mobile apps, if web works | Store review adds weeks before you have learned anything |
| Advanced permissions | Necessary at ten customers, not at your first |
Decisions that are expensive to reverse
Most of an MVP can be rewritten cheaply. These cannot, so make them deliberately even under time pressure:
The core data model
Renaming a field is easy. Discovering that your central entity should have been two entities is not.
Authentication and identity
Migrating users between auth systems later means password resets for everyone and a measurable drop in retention.
Money handling
If the product touches money, use a proper ledger from the start. Reconstructing financial history is grim.
Audit and event history
Recording what happened is cheap now and impossible retrospectively.
Hosting region
Data residency requirements discovered after launch mean a migration, not a config change.
Prototype, MVP, or v1?
| Prototype | MVP | v1 product | |
|---|---|---|---|
| Purpose | Test a concept or design | Test demand with real users | Serve a paying market |
| Real users | No | Yes | Yes |
| Production infrastructure | No | Yes | Yes |
| Reusable codebase | No | Yes | Yes |
| Feature breadth | One flow, faked | One flow, real | Complete for the segment |
The expensive error is building a prototype and then pressing it into service as an MVP. The marginal cost of building on production architecture from the start is small; the rebuild cost is not.
How long should an MVP take?
Shorter than you think is reasonable, and the constraint is usually decision speed rather than engineering speed. Projects slip because a founder takes a week to choose between two flows, not because the code is hard.
We shipped a three-app logistics platform from brief to live in 13 days. That was possible because the scope was cut aggressively and the founder answered questions the same day. Both halves mattered.
How to know if it worked
Decide the success criteria before launch, in writing, because after launch you will find a way to read the data favourably. Useful criteria are behavioural rather than attitudinal:
- What proportion of signups completed the core loop at least once?
- What proportion came back within seven days without being prompted?
- How many paid, if payment was part of the test?
- What did the people who dropped out have in common?
- Did anyone use it in a way you did not anticipate? That is often the real product.
'People said they liked it' is not a result. Compliments are free; actions are not.
After the MVP
There are three honest outcomes. It worked, and you extend it. It failed, and you have learned something for the cost of weeks rather than a year. Or it partially worked, and the interesting behaviour was in an unexpected corner — which is the most common outcome and the reason instrumentation matters.
Because we build MVPs on production architecture, a pivot reuses the authentication, payment, and infrastructure layers even when the product logic changes entirely.
Questions, answered.
How much should an MVP cost?
Less than you can afford to lose, because it may not work — that is the point of building one. The scope should be set by what you can risk, not by what you can imagine. Send a feature list and we will quote it fixed within 24 hours so the decision is made against a real number.
Should the MVP be a mobile app or a website?
A web app, unless the product genuinely requires the phone — camera, location, offline, or push as the core mechanism. Web means no store review, instant updates, and no install barrier, all of which get you to learning faster. Add native later once demand is proven.
Can I build an MVP with no-code tools?
Sometimes, and it is worth considering seriously. If the product is forms, workflows, and a dashboard, no-code may validate demand faster and cheaper. It becomes limiting when you need custom logic, real performance, or full data control. Validating with no-code and then building properly is a legitimate sequence.
How many features should an MVP have?
As few as complete the core loop, which is usually fewer than the founder's list. A useful test: for each feature, ask what you would learn if it were absent. If the answer is 'nothing important', it is not in v1.
What if investors want to see more?
Investors respond to evidence of demand, not feature count. A narrow product with real users and real retention is far more persuasive than a broad product nobody has used. If a specific investor genuinely requires breadth, that is a targeted addition rather than a reason to build everything.
Six things we put in writing.
Not values on a wall — contract terms. Ask any other supplier to match them line by line.
A price in 24 hours
Send a brief, get a fixed written price and a delivery date the next working day. Free, no obligation, and the scope document is yours to keep even if you go elsewhere.
The price does not move
Fixed, not an estimate. If scope changes we re-quote in writing and you approve before we build it. You will never open a surprise invoice.
Half on delivery
50% to start, 50% when it is live and you are satisfied. You never fund the whole project up front.
Unlimited design revisions
We do not write production code until you approve the screens. Changing your mind at that stage costs nothing.
You own everything
Full source code, design files and credentials on delivery. No licence, no platform fee, nothing that stops another developer taking over.
30 days of fixes included
Free bug fixing for a month after launch, then an optional retainer only if you want one.
Every one of these is in the agreement before you pay anything. See how we evidence our claims →
Free quote
Tell us what you're building.
A paragraph is enough to start. You get a scoping conversation and a fixed written price with a delivery date within 24 hours — free, and yours to keep whether or not you go ahead with us.
- A senior engineer replies, not a salesperson
- Written quote inside 24 hours
- NDA before you send anything sensitive — just ask
- No obligation, no follow-up sequence
Prefer to talk now? WhatsApp +92 300 097 0544 or hello@qalmax.com.
Have a project in mind?
Fixed price, written delivery date, and full code ownership.