"What does an app cost?" has no single answer — but there is a method behind the number, and it can be explained. Below is how we estimate internally. You can use it to judge any vendor's quote, not just ours.
Cost comes from three parts
| Part |
What it covers |
Notes |
| Engineering time |
Requirements, design, development, testing, launch |
The bulk of the cost, and it grows faster than scale does |
| Third-party services |
LLM APIs, SMS, maps, payment channels, push notifications, identity verification |
Usage-based; charges begin only after launch |
| Infrastructure |
Servers, bandwidth, storage and databases — plus GPUs for on-premises deployments |
Ongoing, budgeted annually |
Most arguments over a quote come down to the first item. The other two have published pricing — estimate the usage and you can calculate them.
Engineering time is driven by things you can count
Instead of asking "roughly how much?", count the items below — the range narrows immediately:
| Dimension |
How to count it |
Effect on time |
| Screens |
Customer-facing plus admin — count every distinct screen |
The most direct measure of scale |
| API endpoints |
How many distinct actions need to talk to the backend |
Drives backend and integration work |
| Roles and permissions |
How many roles, and whether permissions differ field by field |
Each extra role multiplies the test combinations |
| Platforms |
Mini-program only; both mobile platforms; either of those plus an admin console |
The backend and design carry over to a second platform; the client build and its testing do not |
| Payments and reconciliation |
Do you take payments, split settlements, or handle multiple currencies? |
Payments add noticeably to both testing and compliance |
| Data source |
Your own data, or integration with the client's existing systems |
Third-party integration carries the most uncertainty |
| Deployment |
Cloud, or on-premises |
On-premises adds environment setup and acceptance work |
Which end of the range are you on?
Once you have counted, use the table below to place your own project:
| Dimension |
Bottom of the range |
Top of the range |
| Platforms |
One platform |
Two platforms, or two plus an admin console |
| Roles and permissions |
One or two roles, permissions set per module |
Several roles, permissions set field by field |
| Payments |
No payments, or single-payment checkout only |
Split settlement, refunds, reconciliation, multiple currencies |
| Data source |
All data is your own |
Integration with existing client systems |
| Deployment |
Cloud |
On-premises, including environment fitting and audit |
| Compliance |
No sensitive personal data |
Personal data, finance or healthcare |
If most rows land on the left, budget for the bottom of the range. If two or three land on the right, budget for the top. The right-hand column carries more weight for these reasons:
- Payments and reconciliation. Taking money is not the hard part; refunds, split settlement, reconciliation and exception-order handling are — together with the testing each of them adds.
- Multiple roles and permissions. Going from three roles to six is not twice the work — what grows is the number of permission combinations that have to be tested.
- Integrating the client's existing systems. The quality of the other side's API documentation, its stability and its response times are all outside our control. This is the single largest schedule risk.
- On-premises deployment. Fitting the client's server environment, network policy and audit requirements makes the acceptance cycle longer than it is for a cloud deployment.
- Regulatory requirements. Where personal data, finance or healthcare are involved, the compliance review is itself a phase of work.
Timelines for common project types
These are our time ranges for common project types; where a given project falls in its range depends on the dimensions above. These are timelines, not prices — but timeline is the main driver of cost.
| Project type |
Phase |
Timeline |
| Mini-program (with admin) |
MVP |
3–5 weeks |
| AI application (LLM integration) |
MVP |
2–4 weeks |
| E-commerce app (both platforms + payments) |
MVP |
6–12 weeks |
| AI agent |
Proof of concept |
1 week |
| AI agent |
MVP / full version |
2–4 weeks / 6–12 weeks |
| Custom AI skill |
Scoping, build and delivery |
1–2 weeks |
| Enterprise knowledge base |
Standard edition |
A few weeks (depending on document volume and number of data sources) |
| GEO foundation work |
First round |
2–4 weeks |
Every figure above is for an MVP or a first round of delivery; a full version is quoted per module on top of the MVP. The spread within each row comes from the table in the previous section. Whether an e-commerce app lands at six weeks or twelve depends on multi-merchant support, whether reconciliation is built in-house, and how many currencies are involved.
Estimating annual running costs
After launch, budget these four items separately; together they are your annual running cost:
| Item |
Basis |
What moves it |
| LLM calls |
Token usage |
Daily active users, conversation length, whether retrieval is involved |
| Cloud servers |
Instance spec and runtime hours |
Concurrency, and whether autoscaling is needed |
| Bandwidth and storage |
Traffic and capacity |
Images and video, and whether a CDN is used |
| On-premises |
One-off hardware plus hosting |
Model size determines GPU memory requirements |
A small cloud project and an on-premises deployment with GPUs can differ substantially in annual cost, depending on model size and concurrency. We estimate against your actual expected usage rather than quoting a generic figure.
How we quote
- Requirements review. Work through the dimensions above and produce a scope inventory.
- Fixed quote. Price and timeline are fixed against that inventory. We do not bill open-ended day rates.
- Changes go through assessment. Small adjustments that do not affect the architecture are usually covered by the project; anything that adds a module or changes the technical approach is assessed, quoted, and scheduled once you approve it.
We do not publish prices on the site, for exactly the reason this page describes: a number detached from scale tells you nothing and can mislead your budget. For a number you can actually use, send us your situation and we will quote a fixed price after the review.
Our position on acceptance criteria, source-code ownership and the maintenance period is in the FAQ.