What to put in a super app development company RFP

A super app development company RFP should name the shell, the first two or three revenue modules, the shared services every module depends on, each integration with the person who owns it, measurable acceptance thresholds, the data and residency rules, and the commercial terms. Leave any of those out and the bids you receive will not be comparable, and the winning quote will move within a month.

What follows is the document itself, section by section: what each section must contain, what happens when it is missing, the thresholds worth writing down, and the point at which issuing an RFP is the wrong move altogether.

What a super app RFP is really buying

A super app is one consumer application that hosts several distinct services behind a shared identity, wallet and notification layer. Food ordering, payments, ticketing and loyalty living in one shell is a super app; four apps with the same logo is not. What a super app is and whether you should build one covers the strategic question your RFP is assuming you have already answered.

That assumption matters, because an RFP for a super app is not an RFP for an app. You are buying a platform that will host modules built by other teams for years. The parts of the quote that hurt you later are the shell contracts, the shared services and the module boundaries, and those are exactly the parts vendors quote loosely when the brief lets them.

So the purpose of the document is narrow. A good super app development company RFP forces every bidder to price the same platform, so that price differences reflect delivery ability rather than differences in what each firm quietly assumed.

The sections a super app development company RFP must contain

Twelve pages is plenty. Length is not the point; specificity is. The table below is the skeleton we ask clients to fill before they send anything out, and the third column is what we have watched go wrong when a section was left blank.

Write the shell contract down, not the shell wish list

The shell is the part of a super app that every module negotiates with, so it is where an RFP earns or loses its money. Ask bidders to describe how a module registers itself, how it receives the signed-in user, how entitlements are checked, how deep links resolve and how a module can be dark-launched or rolled back without an app release. Our own breakdown of shell, modules and shared services is a reasonable template for the questions to ask.

Name the integration owners, with people attached

List every external system the platform touches, and beside each one put the name of the person on your side who can get sandbox credentials. Payment gateway, KYC provider, ERP, loyalty ledger, courier APIs, WhatsApp Business: each is a dependency with a human bottleneck. An RFP that lists systems without owners is the single most common reason a fixed-date super app programme slips.

What acceptance criteria should a super app RFP set?

Acceptance criteria should be numbers a tester can check on a device, not adjectives. These are the thresholds we accept being held to, and they are a fair bar to put in front of any bidder.

• Crash-free sessions at or above 99.5 per cent across your two lowest-spec supported devices, measured over a fortnight, not a demo.
• Cold start to interactive shell under three seconds on a mid-range Android device on a 4G connection.
• Module handover measured: switching from the shell into a module and back preserves session, cart and scroll position.
• Payment success rate within an agreed margin of your existing checkout, measured per method rather than in aggregate.
• Offline behaviour defined per module: which screens must render from cache and which may show an honest empty state.
• Accessibility to a stated level, with the audit performed before the final payment milestone rather than after launch.
• Store review passed on first submission for the launch build, with the vendor responsible for policy rejections in their own code.
• Runbook completeness: on-call rota, alert thresholds and one rehearsed rollback before go-live.

Apple's App Review Guidelines are worth reading before you write this section, because section 4.7 sets specific conditions on apps that host mini apps, mini games and third-party content. If your super app plans a mini-app runtime for partners, the guideline shapes your architecture, and it belongs in the RFP rather than in a surprise rejection email.

What budget and timeline should you state?

State a band, not a number, and state the phase. Withholding budget entirely produces bids that are unresponsive in both directions. Our super app development programmes start at $63,000 or ₹41,60,000 and run to $210,000 or ₹1.4 crore and beyond, depending on how many modules ship at launch and how much of the shared services layer already exists. Every starting price is published on the pricing page, so a bidder quoting far below that band is either scoping a single module or planning to recover the difference through change orders.

On timeline, the honest shape is a Sprint Zero of ten days, a proof of the hardest module in about three weeks, then eight to sixteen weeks for a scoped first release. A ten-day discovery sprint at $3,250 or ₹2,00,000, credited to the build, is often better value than a three-month RFP cycle, because it produces the scope document the RFP was trying to write.

The commercial terms to write in, not negotiate later

Three clauses decide whether the quote you accept is the price you pay. Put them in the RFP so bidders price them rather than dodge them.

Scope lock and a priced change process

Ask each bidder how scope is frozen and what a change costs. We work to a fixed price against a locked scope, with changes priced against a published rate rather than absorbed silently; the mechanics are in fixed price, fixed date.

Ownership, spelled out item by item

Code, designs, CI configuration, infrastructure definitions, store accounts and documentation should transfer to you, and the RFP should say so before anyone quotes. Our position is that you own everything, described in why we transfer code, prompts and models.

What support costs after launch

A super app needs a named response commitment from day one. Ask for monthly support pricing in the bid, not afterwards. Ours runs from $1,000 or ₹68,000 a month for business-hours cover to $5,250 or ₹3,40,000 for round-the-clock cover with a named engineer, set out under maintenance and support.

When an RFP is the wrong instrument

If you cannot yet name the first two modules and the number each must move, an RFP will produce five confident documents that disagree with each other, and you will pick on presentation. Run a paid discovery instead and issue the RFP with its output attached.

An RFP is also the wrong tool when the real decision is build versus buy. Some of what a super app does can be assembled from existing platforms, and the honest case for building or buying is worth settling first. Finally, if your timeline is under eight weeks, a competitive RFP cycle will consume most of it. Shortlist two firms, pay both for a week of scoping, and choose on the work.

What a good response looks like

Strong responses argue with your brief. They tell you which module should not ship at launch, they price the shared services separately from the modules, they name the integration they expect to be hardest, and they show a comparable platform they have run in production. A last-mile operator we worked with needed exactly that argument before committing; the dispatch platform and offline-first driver app described in our logistics case study started as a scope half that size once the evidence was in.

Weak responses restate your requirements as a feature list, quote one blended day rate, and put integrations, migration and store submission in an assumptions appendix. Score that appendix first; it is where the real quote lives.

Before you issue it

• Write the two or three numbers the platform must move in its first year
• Fix the launch module list and mark everything else phase two in writing
• List each integration with a named owner and confirm sandbox access exists
• Set numeric acceptance thresholds for crash rate, cold start and payment success
• Decide who owns the App Store and Play Console accounts before bids arrive
• State the budget band and the decision date
• Attach your data residency and retention rules rather than asking bidders to guess
• Agree internally who signs off scope changes once delivery starts

Related reading

Questions to ask a super app development company vendor before you sign covers the conversation after the bids arrive, and the hidden costs quotes leave out lists what to ask bidders to price explicitly.

An RFP is worth writing only to the level of detail you are willing to be held to yourself; write it that way and the bids become comparable for the first time.