What drives the cost of a custom web app?
Five things drive the cost of a custom web app, and none of them is technical. How many screens and business rules it has. How many different user roles log in. How many systems you already use it has to talk to. Who cleans and loads the data you already have. And how clearly your process is mapped before the first line of code. Two requests that read the same in one sentence can differ by five to ten times once those five are answered.
That is why a serious quote never comes before a scoping conversation. A fixed price is only honest when it sits on a fixed scope — a screen-by-screen list of what will be built. At ApexDev that mapping comes first, and the price that comes out of it is per project, not per hour. Most web projects then ship in 4 to 12 weeks; a focused MVP app in 8 to 14.
Why the same request gets three very different quotes
"We need a system to manage our appointments" is a legitimate request. For a clinic with two practitioners and a receptionist, it is a four-week build. For a group with six locations, insurance rules, per-provider commission and a link to billing, it is the same sentence and eight months of work. Send that sentence to three vendors and you will get three numbers that cannot be compared — because each one scoped a different project, and probably none scoped yours.
The number in the footer of a proposal is the least useful line on it. The useful lines are the list of screens, the change policy, who owns the code, and what happens after launch. Two proposals that agree on those four can be compared on price. Before that, comparing price is comparing different things.
The most expensive item in any project is never a feature. It is the business rule nobody mentioned at the start that shows up in week three.
The five factors that actually move the price
Almost all of the variation between one project and another comes down to these five. They depend far more on you than on whoever builds it.
- Screens and rules. A screen with a simple form is cheap. A screen that calculates commission differently per service type, blocks discounts above a threshold and alerts the manager when that happens costs several times more — and is still one screen. Count rules, not screens.
- User roles. A system where everyone sees everything is the cheapest there is. Every additional role — front desk, technician, manager, finance, the end customer — multiplies screens, permissions and tests.
- Integrations. Connecting the new app to your invoicing tool, your CRM, WhatsApp or a payment terminal can be trivial or can be the most expensive part of the project, depending on how open and documented the other side is. Ask each vendor how they priced the integration you care about most; the answer tells you whether they looked.
- Data migration. If your current records live in one clean spreadsheet, moving them is fast. If they live in three spreadsheets, a notebook and one person's memory, someone has to clean that first. It is real work and it is billed.
- How mapped your process already is. This is the most underestimated factor. A team that can explain its own workflow step by step saves weeks. A team that discovers its rules during the project pays for each discovery.
What a serious quote includes — and what almost always sits outside it
A quote you can trust separates the two before you sign. Included, in the serious end of the market: the scoping phase, screen design, the build, testing, launch and training your team.
Almost always outside the quote:
- Hosting. The rent for where the app lives. Anyone promising free hosting forever is charging for it somewhere else.
- Monthly maintenance. Optional on paper, unavoidable in practice — the next section explains why.
- Third-party services the app uses: messaging, e-signature, payment processing, tax filing. Each bills per use, and the account is yours, directly with them.
- Scope changes after signing. If the price is fixed on a defined scope, a new request after signature is a new quote. That is not a trick; it is exactly what stops a fixed price from turning into an open tab.
Why there is a monthly cost after launch
Software that sits still rots, and that is not a figure of speech. Your customers' phones update themselves, browsers change, the third-party service you rely on changes how it talks, and a security flaw discovered somewhere else becomes your problem here. An unmaintained app does not stay where it was. It gets worse sitting down.
That maintenance agreement should be separate and cancellable — never a leash. And the code has to be yours. At ApexDev, code ownership transfers to the client at delivery and the monthly retainer is optional: if you want to take the system to another team, you can. If you cannot, you did not buy a system. You rented one.
What a suspiciously cheap quote is hiding
A price well below the market usually hides one of these five. You find out which one after you have paid.
- The scope they understood is smaller than yours. They quoted half of what you asked for and will bill the other half as extras.
- There is no scoping phase. They start building and discover your process alongside you, on your clock and your money.
- It is an off-the-shelf product with your logo. You pay for custom and get configuration, with limits that only appear when you need the rule specific to your business.
- No testing, no launch, no training. The app arrives; the rest is on you.
- Nobody is left to answer afterwards. The system runs until the day it breaks, and then there is no one to fix it.
Rebuilding a badly built app costs more than building from scratch. You pay for demolition before construction starts.
Two legitimate ways to pay less
Neither of them is asking for a discount.
The first is cutting scope on the first release. You do not need the whole system in month one. You need the part that removes the worst bottleneck — live, working, with your team using it. The rest comes in a second phase, paid later, with the system already producing results. That also improves the project, because phase two gets designed on real usage instead of assumption.
The second is arriving prepared. Write down your process before the first call: who does what, in what order, what is allowed and what is not, and the exceptions everyone already knows by heart. One well-written page of that cuts days of scoping and removes most of the risk of an expensive discovery mid-project.
What does not work is hiring cheaper to do exactly the same thing. The work does not disappear because the price dropped. It comes out worse, or comes back as an extra later.
The number that matters is not the price of the app
The right question is not what the app costs. It is what the current problem costs you every month, while you decide. How many hours a week does your team spend filling in spreadsheets, checking spreadsheets and fixing what the spreadsheet got wrong? Multiply by what those hours cost. How many quotes, appointments or invoices slip every month because nobody remembered to follow up? How many decisions last year were made on a wrong number because the information lived in three places that did not agree?
Run that with your own numbers. If it does not add up, the honest answer is not to build the app now — not every problem justifies custom software. But almost nobody runs that calculation before asking the price, and it is exactly the calculation that turns the price from frightening into a decision.
What stays
Five factors move the cost: screens and rules, roles, integrations, data, and how mapped the process is. A serious quote sits on a fixed scope and tells you what is outside it. And the cheapest option is the one that removes the worst bottleneck first, not the one with the smallest number.
ApexDev builds custom web apps for clinics, shops, firms and distributors in the United States and Brazil, and the first conversation is where the scope gets mapped: a 30-minute diagnostic, looking at what you have today, before any proposal.
Want this applied to your project?
Tell us what you need and we'll come back with scope, price and timeline.