A custom business application is software built for one company, around the way that company already works. The term covers three different things: a dashboard someone reads, a back office someone types into, and a tool someone opens in the field. Each one prices differently.
The shared file nobody wants to touch
A shared workbook holds the orders, the stock levels, or the schedule. Three people write into it. A fourth built the formulas four years ago and has since left the company.
Raymond Panko, at the University of Hawaii, gathered seven field audits of spreadsheets in live use for a review paper published in 2000. Of the 367 workbooks examined, 24% held at least one error. Across the 54 workbooks from the audits run in 1997 and later, the figure rises to 91%.
Nobody sees the broken formula until the day someone invoices the wrong amount or reorders a part that is already sitting on a shelf.
Count for one day how many times the same piece of information gets typed twice, out of one tool and into another.
If the count is high and the data already lives somewhere, your problem is how it moves between tools, and automation handles that from €2,380. If nothing holds the information until someone types it into the workbook, you need an application.
The three shapes a business application takes
The three have different users and different constraints, which is what puts the price of one of them well above the other two.
| Shape | Who uses it | The signal that points to it | What it replaces |
|---|---|---|---|
| Dashboard | A director or a manager, once a week | Someone spends two hours every Monday assembling a report out of three exports | A reporting file rebuilt by hand |
| Back office | Internal teams, continuously | The same record is keyed into two tools so that both stay current | A shared workbook, or an off-the-shelf tool bent out of shape |
| Field tool or portal | People away from a desk: technicians, drivers, clients | Information comes back by phone, photo or email, and someone retypes it | A notebook, a messaging group, an inbox |
The shape follows from who opens the tool and when. A dashboard gets read on Monday morning. A back office stays open eight hours a day. A field tool gets used standing up, one-handed, sometimes with no signal.
The field tool is the most expensive of the three, because it has to run offline, then reconcile whatever was entered while it was offline.
Name the shape before you ask for a quote, because a price quoted for a business application in general cannot be compared with anything.
What it costs, and what moves the number
I publish my pricing. A targeted tool starts at €7,140, which is twelve working days, delivered in six to eight weeks.
A multi-module business application starts at €16,660, twenty-eight days, delivered in ten to fourteen weeks. The day rate is €595 across every service.
Three things push that number up, in this order.
- How many roles. A tool where everyone sees everything is quick to build. The moment a salesperson must not see margins and a subcontractor must only see their own jobs, you need permissions, an action log, and a different screen per profile.
- How many tools to connect. Accounting, mailbox, calendar: every connection has its own date formats and its own outages to handle.
- The data migration. Pulling four years out of a workbook, duplicates and ad-hoc columns included, often takes longer than the screen that will display the result.
To test custom against a subscription, divide the quote by what you pay in licences each month. A €16,660 tool against €400 a month pays for itself in just under forty-two months. Against €1,200 a month, in just under fourteen.
Then run the number again with upkeep included. I include three months of support after go-live, and past that we sign a separate maintenance contract. Ask for that figure before you sign the build.
Can you build it yourself?
No-code builders and AI coding assistants do handle one of the three shapes. A dashboard reading data that already sits in a spreadsheet or a database is within reach of a careful non-developer in a few days, and that is worth doing before anyone signs anything.
They run into trouble in five specific places, and all five belong to the back office and the field tool.
- Permissions per role, plus an action log that records who changed what and when.
- Offline use, and the reconciliation that has to happen when the device comes back online.
- Migrating years of history out of the old file, duplicates included.
- Anything that has to hold up in an accounting or compliance audit.
- Handover: someone other than the person who built it has to keep it running next year.
Handover is where most of the cost lands, and it is usually the last thing anyone asks about. Ask who maintains the tool if you stop, before the first screen exists. I answer that in writing on the internal tools page: the code lives in your repository from day one, and another developer can pick it up.
Why a delivered application ends up unused
A custom tool nobody opens costs the same as one that gets used every day. Three causes come back, and you can settle all three before you sign.
- Nobody owns it internally. Someone on your side has to arbitrate change requests and answer colleagues. Without that name written into the project, teams reopen the old workbook at the first screen that does not do what they expected.
- The old file survives alongside it. If the data migration stops halfway, your team has two sources and goes back to whichever one is quicker. Set the date after which the workbook goes read-only, and put it in the project schedule.
- The tool asks for more typing and gives nothing back. If an application adds three fields to fill in without removing a step somewhere else, your team works around it within a fortnight. Each input screen you add should remove an action people already perform.
Sometimes no application is warranted. Coddy, one of my own companies, runs urban escape games across nine countries with no central application: the website takes the bookings, automations qualify the requests, take payment and send the instructions. The data already existed in off-the-shelf tools, and what was missing was the movement between them. That is the same reasoning as the four conditions for automation that works.
Key takeaways
- Spend one day counting how many times the same information gets typed twice, out of one tool and into another. If the data already lives somewhere, your subject is movement between tools, and that starts at €2,380 instead of €7,140.
- Name the shape before you ask for a quote: dashboard, back office, or field tool. The field tool is the most expensive of the three, because it has to work with no signal.
- Divide the quote by what you pay in licences each month. That gives you the number of months before the build is paid back. Run it a second time with annual upkeep added in.
- Before signing, write two lines into the project: the name of the person who owns the tool internally, and the date the old file goes read-only.
If you are still weighing connecting your current tools against having an application built, the audit on the internal tools page starts by looking at what your tools already hold.
