The published cost ranges for fintech apps are averages over builds that share a label and nothing else, which is why they are useless and why two honest quotes for "the same" app can differ by a multiple. Five things move the number, and screen count is not among them: whether customer money moves, who owns the other end of each integration, what identity verification you are obliged to perform, what you must be able to prove afterwards, and what an hour of downtime costs. Settle those five and the estimate stops being a guess.
Every article on this subject eventually produces a range. We are not going to, and the reason is the whole point of the article: the ranges are arithmetic performed on a category that does not exist. A personal budgeting app that reads transactions through an aggregator and a licensed wallet that holds customer balances are both filed under "fintech app". The second one contains roughly none of the first one. Averaging them produces a number that describes nothing.
What follows is the set of questions we actually ask before quoting, in the order they matter. If you can answer them, any competent firm can price your build — and you will be able to tell which of the quotes you receive were written by someone who understood it.
One: does customer money move through your system?
This is the largest single step change in the whole exercise, and it is binary. Not "do you show balances" — do funds actually move under your instruction.
The moment they do, a set of subsystems becomes mandatory, and none of them are visible in a design file. You need a ledger that balances by construction rather than by reporting. You need idempotency on every path that touches money, because networks retry and users double-tap and neither is allowed to move funds twice. You need reconciliation against whatever rail you sit on, running continuously, with a defined process for breaks. You need to handle reversals, disputes and partial failures as first-class states rather than error cases. And you need an audit trail that a third party can read without your help.
None of that is optional, none of it can be deferred to version two, and all of it sits underneath the one button the user sees.
Two: who owns the other end of each integration?
Integration count is a weak predictor. Integration ownership is a strong one, because it decides whether the work is estimable at all.
A modern payments API with sandbox credentials, versioned documentation and a status page is ordinary engineering. You can scope it, build it and test it on your own schedule. A core banking system reached through a bank's internal change process is a different category of thing: a shared test environment you queue for, a release window measured in weeks, a counterparty whose availability is not yours to plan, and a specification that is frequently correct about the wrong version. The protocol might be simpler. The schedule risk is an order of magnitude higher.
We have written separately about how an Oracle banking stack is actually layered, and the same principle holds everywhere: ask who controls the environment you will be testing against. If the answer is anyone other than you, that integration drives your date.
Three: what identity verification are you obliged to perform?
Onboarding is where the regulator reaches furthest into your product, and the requirements differ enough by jurisdiction that the same flow is cheap in one market and a programme in another. A document upload and a database check is one build. A supervised video session with liveness, recorded and retained, with operator tooling and a review queue, is a different build with an operational team attached to it — and in India, for instance, RBI's rules reach into where the infrastructure sits and which IP addresses you must block.
The expensive part is rarely the verification itself, which is usually a vendor. It is everything around the unhappy path: what happens when the check is inconclusive, who reviews it, how they are tooled, how the decision is recorded, and how you prove later that it was made properly. Budgets routinely include the vendor and omit the queue.
Four: what must you be able to prove, and to whom?
This is the driver that most reliably surprises people, because it is invisible until something goes wrong and then it is the only thing that matters.
If a regulator, an auditor or a counterparty can ask you to demonstrate what happened — which record changed, who changed it, on whose authority, and what the system state was at the time — then evidence is a feature of your system and has to be designed in. Retrofitting it means reconstructing history you did not keep. The cost shows up as immutable event storage, considered retention, access logging, exportable trails and the discipline not to let anything mutate silently.
Teams that have only built unregulated products tend to price this at zero, because in an unregulated product it genuinely is zero.
Five: what does an hour of downtime cost you?
Availability is bought, not configured, and the price is steep and non-linear. A product where a failed hour means irritated users is an ordinary deployment. A product where a failed hour means payments do not settle is multi-region, tested failover, run-books, rehearsals and someone awake.
You do not need to buy the top tier. You do need to decide deliberately, because the difference between tiers is large enough to swamp every feature decision you will argue about.
Where screens actually sit
Near the bottom — and the reason quotes are organised around them is not cynicism, it is that they are the most estimable thing in the project. Everyone can see them, they decompose cleanly, and reasonable people converge on similar numbers. The items above do none of that, so they get a line called "backend" and a figure that was reverse-engineered from the screen total.
That is the mechanism by which two honest firms quote the same brief at very different prices. Neither is padding. One of them has priced the reconciliation.
What to do instead of asking for a range
- Write down whether you hold funds, or whether a licensed partner does and you orchestrate. One sentence, enormous consequences.
- List every system you must talk to, and name who controls its test environment. Mark the ones you do not control — those set your date.
- State the onboarding obligation per market, including what happens when a check fails.
- Say what you must be able to evidence, and for how long.
- Put a number on an hour of downtime, even a rough one, and let it pick your availability tier rather than picking it by instinct.
Take that to three firms and the quotes will cluster. Take a feature list and they will not, and the spread will tell you more about who read the brief carefully than about what your product costs to build.
Questions we get asked
Why do fintech app cost estimates vary so widely?
Because the published ranges average over builds that share a label and nothing else. A budgeting app that reads bank data through an aggregator and a licensed wallet that moves customer money are both called fintech apps, and almost nothing in the second one exists in the first. The range is wide because the category is meaningless, not because estimating is hard.
Does the number of screens affect the cost much?
Less than almost anything else. Screens are the most visible part of the build and among the most predictable to estimate, which is exactly why quotes are organised around them. The cost lives in what sits behind the screens — ledgers, reconciliation, idempotency, limits, screening and audit trails — none of which appear in a wireframe.
What single factor moves the budget most?
Whether customer money moves through your system. The moment it does, you inherit a double-entry ledger, idempotency on every path, reconciliation against the rail, dispute and reversal handling, and an audit trail someone external will read. These are not features you can defer; they are the substrate everything else sits on.
Why does integration count matter less than integration ownership?
Because the cost of an integration is driven by who owns the other end, not by the protocol. A modern API with sandbox access and good documentation is predictable work. A core banking system reached through a bank's own change process, with a shared test environment and a release window, is schedule risk you cannot estimate away — and it is usually the thing that sets the delivery date.
Is an MVP meaningfully cheaper in fintech?
Less than in other sectors, because the parts you would normally cut are the regulated ones. You can ship with fewer features, fewer segments and one platform. You cannot ship with a ledger that does not balance or an onboarding flow that skips verification. The floor in a regulated build is high, and the savings come from narrowing scope rather than thinning the foundation.
What should we settle before asking for a quote?
Whether you hold money or a licensed partner does, which integrations are involved and who controls each one, what identity verification your regulator requires, what evidence you must be able to produce on demand, and what downtime actually costs you. Those five answers move an estimate by multiples. A feature list moves it by percentages.
If you are at the stage of comparing quotes and want help reading them — specifically, working out which ones priced the parts nobody can see — that is a useful conversation to have before you choose, not after. It is where most fintech builds are won or lost.