Fintech: Do You Need an App, a Website, or Both?

Almost every fintech founder arrives with the same sentence: we need an app. It is said as settled fact, before anyone has asked what the product requires people to do.

Sometimes it is right. A wallet people tap at a counter has to be an app. But a lending product, an advisory service or a B2B payments tool often does not, and building the app first costs months that the business did not have.

The short answer

Build for where the money moment happens. If people need you standing in a shop or several times a week, build the app. If they need you a few times a month, at a desk, with a document open, build the web product first.

The question that settles it

Not "would an app be nice": an app is always nice. The question is: how often, and where, does someone have to do the thing?

Several times a week, away from a desk. App. Payments, transfers, anything at a point of sale.
A few times a month, at a desk. Web. Applications, statements, portfolio reviews, anything involving documents.
Once a year. Neither, probably. A good page and a phone number.

A wallet with separate customer, agent and merchant experiences only works as apps, because agents and merchants are standing behind counters. A lending journey involving payslips and bank statements is miserable on a phone and always has been.

The costs people forget about apps

The build is the visible part. The rest arrives afterwards and never stops:

Two stores, two review processes, each capable of rejecting you for something unrelated to your code.
Update friction. Users on old versions, indefinitely, and a security fix nobody installs.
OS releases that break something every year.
Availability problems. A listing can be fine in one market and unavailable in another, which is a real and unglamorous risk in payments.

None of that is a reason to avoid apps. It is a reason not to build one before the product needs it.

What the website is doing in the meantime

In fintech the public site carries more weight than in most industries, because the visitor is deciding whether you are safe. It needs to say clearly who is behind the company, which regulator or registration applies, how money is held, and what happens if something goes wrong.

That is trust infrastructure, not marketing. It is also the thing the app store, a partner bank and a compliance reviewer will all look at.

The usual right order

For most teams:

Website that explains and converts, including the trust and compliance pages.
Web product for the parts done at a desk.
App once you know which actions people repeat, from real usage rather than a workshop.

Doing it this way means the app you eventually build contains what people actually do, rather than everything you imagined they would.

The exception

If your product is genuinely tap-to-pay, agent-assisted cash-in, or anything where someone is standing up and holding a phone, skip to the app. Trying to do that on a mobile website is a worse product, not a cheaper one.

A note on how these get built

Cross-platform is the normal answer now: one codebase, both stores, which makes "iPhone or Android" much less of a budget decision than it used to be. I have written a fuller comparison of React Native and Flutter, and separately about what actually goes into a wallet build once you have decided to make one.

When to build nothing yet

If you have not signed a payment partner, or you are waiting on a licence, building the app is the most expensive possible way to fill the time. A clear site and a waiting list costs a fraction and tells you whether anyone wants it.

What it costs

A website, a web product and an app are three different projects and three very different numbers. The estimator will separate them for you in a minute.

If you are about to start, send me a WhatsApp with one sentence on what a customer does on the day they use your product. That sentence usually decides the order, and quite often it says the app can wait six months.