We sell cross-platform mobile app development. It starts at $599 and takes one to seven weeks. It is good work and we are glad to do it.
We also talk roughly half the people who ask for it into something else, because the request usually arrives attached to a belief that does not survive contact with the numbers:
An app is not a growth channel. It is a retention channel.
Apps do not find you customers. Being in an app store is not distribution in any meaningful sense — nobody browses the store hoping to discover your clinic. An app takes people who are already your customers and makes them slightly more likely to stay, buy again and respond to a notification.
That is genuinely valuable. It is also a completely different business case from the one most people are making when they ask for an app, and if you are not already retaining customers, an app is an extremely expensive way to find out you are not.
The three gates
An app earns its cost when it passes all three. Not two.
Gate 1: frequency
Do your customers already interact with you weekly, unprompted?
Not "would we like them to". Do they already? Check your own data: repeat purchase rate, login frequency, how many customers came back within thirty days.
An icon on a home screen is a reminder of an existing habit. It does not create one. If your customers touch you four times a year, they will install your app, open it once, and it will sit in a folder called "Other" until the next phone.
This gate alone eliminates most requests. Estate agents, wedding venues, B2B service firms, anyone with a long purchase cycle: you do not have a frequency problem an app solves. You have a frequency reality.
Gate 2: device capability
Does the experience require something only a native app can do?
The real list is shorter than it used to be: background location, reliable background sync, Bluetooth or peripheral access, camera work beyond a single capture, biometric-gated local storage, offline operation over hours rather than minutes, and genuinely reliable push on iOS.
Almost everything else — camera capture, payments, maps, notifications on Android, offline caching of recent data — works in a browser now. If your feature list is "browse, search, book, pay, see my history", every item is a web capability, and the app adds packaging rather than function.
Gate 3: the install is worth paying for
Will enough people complete an install to justify building for the ones who do?
Every install is a funnel with four steps that each lose people: go to the store, find the right app, download it, open it and sign in. You pay for that funnel in conversion rate, forever, on every new customer.
The question is whether what you get on the other side — the notification channel, the offline mode, the home-screen presence — is worth more than what you lost at the door. For a daily-use product it plainly is. For a booking you make twice a year it plainly is not.
What usually wins instead
A fast mobile web experience
The unfashionable answer, and the right one surprisingly often. No install, no store review, no two codebases, indexable by search engines, linkable from anywhere, and it works on the device your customer is holding right now.
Most businesses that think they need an app need their existing site to stop being unusable on a phone — which is a website project from $99 in three to ten days, not a one-to-seven-week app build.
A Telegram Mini App
Where your customers live in Telegram, this is the strongest option available and it is badly under-considered outside the region where it dominates. There is no install, no store approval, and the identity is already verified — the user is signed in silently from Telegram's own signed launch data.
We built exactly this for Bronjoy: a customer picks a service, branch and time inside Telegram, is signed in without a form, pays, and gets confirmations and reminders in the same chat, with buttons back into the Mini App. And for BiliMind, a learner opens an AI-generated course straight from a conversation with no registration at all.
At $199 and one to three weeks, a Telegram bot or Mini App is a third the cost of an app build and skips the install funnel entirely. We make the wider case in Telegram is a storefront.
One shared codebase, escalated later
If you genuinely might need an app but are not sure, build the web product properly first and wrap it when the data says so. That is what we did with BiliMind: the same Nuxt codebase runs on the web and ships as Capacitor Android and iOS builds. The app was not a separate project; it was a packaging decision taken once the product existed.
The retention arithmetic, done properly
Gates are qualitative. Here is the number, because "it will improve retention" is where most app business cases stop.
An app earns its keep when the extra value from app users exceeds the build, the upkeep and the customers you lose at the install step.
You need four figures you already have:
- A — annual value of a customer today
- R — the retention lift you expect from app users (be conservative: 10–20% is a realistic band for a genuinely repeat-use product, and zero is the honest number for everything else)
- I — the share of your customers who will actually install (for a non-daily product this is rarely above 10–15%)
- N — customers per year
Annual gain ≈ N × I × A × R
A worked example. A service business with 3,000 customers a year at $180 each. Assume a generous 15% install rate and a 15% retention lift on those who install:
3,000 × 0.15 × $180 × 0.15 = $12,150 a year
Against that: the build at $599 entry and one to seven weeks, plus the part nobody budgets — two store accounts, OS updates twice a year, and a release every time either platform changes its rules. Call upkeep a few hundred dollars and a handful of developer days annually.
On those numbers it works, and comfortably. Now change one assumption. Drop the install rate to 5% — which is what you should expect for a business people use twice a year — and the gain falls to $4,050, against the same permanent upkeep. Set the retention lift to zero, which is the correct value if the app does nothing the website cannot, and the whole thing is a cost centre with an icon.
The sensitivity is almost entirely in I and R, and those are the two numbers every app business case invents. Before you commission anything, write down what you are assuming for both, and then ask what evidence you have. Your existing repeat-purchase rate is the best available proxy for R, and it is usually a sobering one.
If you pass all three gates
Then build it properly, and hold your builder to four things.
One codebase, both stores. You should pay for one app, not two, and every fix should land on both platforms in the same week. That is the entire economic argument for cross-platform, and it holds.
Native feel, not a wrapped webpage. Real navigation, real gestures, real transitions. Users cannot articulate what is wrong with a wrapped site, but they can feel it within ten seconds, and they will judge your whole business on it.
Offline as a designed behaviour. Data cached on the device and synced when signal returns. A lift, a basement, a metro ride. If offline was not in the scope conversation, it was not designed, and it will be retrofitted badly.
Released under your accounts. This is the one that catches people. The app must be published from your Apple and Google developer accounts, with the signing keys, the source and the release pipeline handed to you. An app published under an agency's account is an app you cannot update without them — the purest form of lock-in available in software, and it is depressingly common.
Our mobile builds are $599 and one to seven weeks, and the release and handover phase is a named part of it for exactly this reason.
The honest budget comparison
| Option | Entry price | Delivery | Install friction |
|---|---|---|---|
| Landing page | $99 | 3–5 days | None |
| Telegram bot / Mini App | $199 | 1–3 weeks | None |
| Corporate site | $299 | 7–10 days | None |
| Mobile app, both stores | $599 | 1–7 weeks | Store install |
The right-hand column is the real comparison, not the left. An app costs six times a landing page in money and roughly five times in calendar, and then charges you again on every single customer acquisition in the form of install drop-off.
That is worth paying when the retention gain exceeds it. It is a bad trade when the app is a status project, and the tell is easy to spot: if nobody can say what the app does that the website cannot, it is a status project.
Telling clients that costs us the larger invoice. Saying so anyway is one of our five commitments — we would rather lose a project than sell you one you do not need.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
Our competitors all have apps. Does that not matter?
Check whether their apps have recent reviews and recent updates. A large share of small-business apps ship, get a launch push, and are abandoned within a year. Matching a competitor's abandoned project is not a strategy.
What about push notifications — we want those.
On Android, web push works well and needs no app. On iOS, web push exists but is weaker and requires the user to add your site to their home screen. If push to iPhone users is genuinely the core of the business case, that is a legitimate reason to build — but say so explicitly, because it is a much narrower justification than "we need an app".
Is a PWA a real alternative?
For many businesses yes, and it is how BiliMind and several of our other products ship on the web. Installable, offline-capable, no store. The limits are the iOS restrictions above and the fact that most users will never install it, so design it to work perfectly as an ordinary website first.
How do we know when it is time?
Two signals. Your mobile web usage is high and repeat, and your customers are asking for an app unprompted — not answering yes when you ask them. The second one matters more, because "would you use an app?" is a question almost everyone answers politely.
Can you build the app later without rebuilding?
Usually, if the product was built with an API from the start rather than as a monolithic website. That is an architecture decision worth making at the beginning even if you never exercise it — it costs almost nothing early and a great deal later.
