Questions to ask a super app development company vendor before you sign

Ask a super app development company vendor five things: how the shell contract lets a module ship and roll back, who owns the code, infrastructure and store accounts, what the platform costs to run each year, how an incident escalates at two in the morning, and what exit looks like. Firms that have shipped a super app answer in specifics. The rest answer in adjectives.

Below are the questions themselves, grouped by what each one is actually testing, with the shape of a strong answer and the shape of an evasive one. Use them in the shortlist meeting rather than in the written response, because the interesting information is in what a vendor says when they cannot edit it.

What these questions are testing

A super app is a platform that will host modules for years, so the vendor decisions that matter are the ones that are expensive to reverse: the shell contract, the shared services boundaries, the data model behind identity and the wallet, and the operational commitments. Almost every serious problem we are called in to fix on an existing super app traces back to one of those four, not to a feature that was built badly.

So the questions are not a technology quiz. They test whether the vendor has operated a platform of this shape after launch, which is a different experience from having built one. A firm that has only ever handed over at go-live will answer confidently about architecture and vaguely about incidents, and that pattern is worth more than any reference call.

Questions about architecture

How does a module register with the shell, and how do I roll one back?

A strong answer describes a versioned contract: what a module declares, how it receives the signed-in user and entitlements, how deep links resolve to it, and how it can be disabled remotely without an app store release. A weak answer talks about navigation and tabs. The rollback question is the sharp one, because it separates firms that have run a live platform from firms that have shipped one. Our own view of that layer is set out in shell, modules and shared services.

Which shared services are you building, and which are you assuming exist?

Identity, wallet, payments, notifications, search, analytics and support are the shared layer. Ask the vendor to say which of the seven they are building, which they are integrating and which they have assumed you already have. The gap between that answer and reality is where most change orders come from. Press on the wallet in particular: a ledger that three modules write to needs an owner, a reconciliation process and a definition of what happens when a module's write succeeds and the payment provider's callback never arrives.

How do you instrument the platform, and can I take the telemetry with me?

Ask whether tracing and metrics use an open standard or the vendor's own stack. OpenTelemetry is a vendor-neutral specification for traces, metrics and logs, and a vendor instrumenting to it is one you can leave without losing your observability history. A vendor whose monitoring only works inside their own tooling has created a switching cost you did not agree to.

Questions about ownership and exit

Who owns the code, the designs, the infrastructure definitions and the store accounts?

The answer should be you, item by item, including CI configuration, Figma files, Terraform or equivalent, the App Store Connect and Play Console accounts, and the documentation. Our position on this is unambiguous and is described in why we transfer code, prompts and models. If a vendor holds the developer accounts, they hold your ability to ship.

What does a handover to another team look like, and what does it cost?

Ask for the exit price now, while you have leverage. A credible answer includes a runbook, an architecture decision record, environment setup verified by someone outside the team, and a fixed number of transition days. We have been on the receiving end of enough of these to have written up taking over a system you did not build; the vendors who make that easy are the ones who documented as they went.

Questions about cost and operations

What does this platform cost to run in year one, excluding your fees?

A vendor who has operated a super app can answer this in categories without hesitating: infrastructure, observability tooling, payment gateway economics per method, app store fees on any digital goods, two operating-system upgrade windows a year, and the engineering allowance for partner API changes. The volume assumptions behind each category matter as much as the numbers, because a running-cost estimate without stated assumptions is a guess presented as a budget. A vendor who has only built one will quote infrastructure and stop. The hidden costs quotes leave out is the full ledger to compare their answer against.

What happens at two in the morning when payments fail?

You are testing whether a support commitment exists in writing. Ours runs from $1,000 or ₹68,000 a month for business-hours cover through to $5,250 or ₹3,40,000 a month for round-the-clock cover with a one-hour response and a named engineer, under maintenance and support. Ask for severity definitions, the escalation path, and who is on the rota. A vendor who answers with a generic service level and no names has not thought about it. Ask also what their last production incident was and how long it took to resolve; a firm that has operated platforms will tell you, and the willingness to describe a bad night is itself the signal.

How is scope frozen, and what does a change cost?

Super app scope moves more than most because module owners appear as the platform becomes real. Ask for the change mechanism and its price. We work to a fixed price against a locked scope with changes quoted against a published rate, and every starting figure sits on the pricing page, so a bid well under the $63,000 or ₹41,60,000 entry point for super app development deserves an explanation of what has been left out.

How to score the answers

Score the shape of the answer, not its confidence. Confidence is the cheapest thing in a shortlist meeting, and specificity is the most expensive, because only experience produces it. The pattern below is the one we use when clients ask us to sit in on their vendor shortlist.

The documents to ask for before you sign

• A reference architecture for a platform they have run in production, not a sales diagram drawn for you.
• The shell contract specification, even in draft, showing how a module is registered and disabled.
• A severity table with response and resolution commitments, and the escalation names behind it.
• Their security posture, covering access control, secrets handling, subprocessors and data residency.
• A named team list with the people who will actually work on your platform and their availability.
• The assumptions appendix from their proposal, read before the price page rather than after.
• A sample handover pack from a previous engagement, redacted, so you can judge documentation quality.
• The change order rate card, signed as part of the contract rather than issued later.

For the security items, our security questionnaire for vendors is a reasonable starting list, and the data residency and consent questions in it apply just as directly to a consumer platform handling Indian personal data under the DPDP Act.

When these questions are the wrong use of your time

If you have not yet fixed the launch module list, no vendor answer will be comparable, because each will be answering about a different platform. Fix scope first; what to put in a super app RFP covers what that document needs.

Equally, if your programme is genuinely small, a single module with a payment path rather than a platform, then interrogating a vendor about shell contracts and module governance wastes everyone's afternoon. Buy the app, ship it, and have this conversation when the second service is real. Vendors who happily sell you platform governance for a one-module product are telling you something about themselves, and what they are telling you is that they will not say no to scope they can bill for.

What good looks like in practice

The best sign is a vendor who argues with your plan before they have won it. On the university ERP programme described in our modernisation case study, the useful conversation was about what not to rebuild, and it happened before the contract rather than after. Apply the same test here: a vendor who tells you which module should move to phase two is worth more than one who agrees with your whole list. If you want to run these questions past us, talk to our team and we will answer them about our own work first.

Related reading

Five ways super app programmes fail shows what the weak answers above turn into eighteen months later, and what a super app costs in 2026 gives you the price context to judge a bid against.

The question that tells you most is the one about two in the morning, because only a vendor who has lived through it has an answer with names in it.