The price of a custom web application is mostly set by four decisions you make before you ask for a quote: who uses it, what it connects to, what data comes with it, and what has to work on day one.
If you are collecting quotes to replace a tangle of forms, spreadsheets and email threads with one web app, you have probably seen bids so far apart they seem to describe different projects. Usually they do. Each firm filled the gaps in your brief with its own guesses. Close those gaps yourself and the quotes start to line up.
What actually drives the cost
Screens and features are what people picture, but they are rarely what makes a build expensive. These are.
Users and roles
An app used by one internal team is a different job from one used by staff, customers and subcontractors who each see different data. Every role adds permissions to design, screens to vary and cases to test. Write down every type of person who will log in and what each one must never see.
Integrations
Connecting to your accounting system, CRM, payment processor or email platform is where estimates tend to grow. Each connection depends on the other system's API, its limits, and what should happen when it is down or sends back bad data. List every system the app must read from or write to, and which direction the data flows.
Data migration
Years of records kept in spreadsheets are rarely clean. Duplicates, free-text fields and missing values all have to be resolved before they can live in a real database. Decide how much history you truly need on launch day. Sometimes the last two years is enough and the rest can stay in an archive.
Rules and exceptions
The normal path is cheap. The exceptions are not: the discount that applies only to some clients, the approval that skips a step on rush jobs, the invoice that gets split three ways. Every exception your team handles from memory today becomes logic someone has to build and test.
How finished version one must be
A tool only your staff will use can launch rougher than one your customers will see. Polish, accessibility, reporting and admin screens all cost money. Decide what version one must do well and what can wait for version two.
A brief that makes quotes comparable
Before you contact anyone, put these on two pages:
- The business problem in one paragraph, and how you will know it is solved.
- Every user role and what each one does in the app.
- Every system it must connect to, with the direction of data.
- The data you need to bring in, and how far back.
- The exceptions your team handles most often.
- What must work at launch and what can come later.
Give every firm the same brief. If their numbers still differ, ask each one to show which assumptions moved the price. That conversation tells you more about a future partner than the number does.
Count the cost after launch
The build is only part of what you will pay. Hosting, security updates, changes when a connected system changes, and small improvements continue for as long as the app runs. Ask every firm what ongoing support covers, how changes are billed, and who owns the code and the data if you part ways. A cheaper build with unclear ownership can cost more over its life than a pricier one you fully control.
Three ways to bring the number down
- Cut roles before features. Launching for internal staff first and adding customer access later can remove the hardest permissions work from version one.
- Buy the generic parts. Login, payments, email delivery and file storage rarely need to be custom.
- Retire exceptions instead of coding them. If a rule exists only because it has always been done that way, dropping it may be cheaper than building it.
When custom is the wrong answer
If an existing product covers most of what you need and the gap is in how your team works rather than what the software does, configure that product first. Custom earns its cost when the workflow is part of how you win or deliver work and no product fits without forcing your team into workarounds.
If you are weighing quotes now, I can help you write the brief, compare what each firm assumed, and decide whether custom is the right call at all. Book a conversation with me at daks.me.
