01. What actually makes the price
The number of screens gives a first impression, but it misleads. Two screens can take a day or three weeks depending on what sits behind them.
Four factors weigh more, and they are discussed before starting: the scope actually retained, how many platforms are targeted, which systems must be connected, and the security or volume requirements.
- The scope retained: what is genuinely needed at launch, as opposed to what might serve one day.
- The platforms: web alone, or web plus mobile, or web plus mobile plus desktop.
- The integrations: every existing system to query is a development in its own right.
- The requirements: concurrent users, expected availability, security or regulatory constraints.
02. Custom or subscription: where the line falls
A subscription always looks cheaper in the first year, and often is. The honest comparison runs over three to five years, and on your figures, not in general.
Three situations tip towards custom. The first is arithmetic: when the per-user cost multiplied by your headcount durably exceeds amortising a build. The second is functional: when adapting the market tool costs more than building. The third is strategic: when the specificity you want to automate is exactly what distinguishes you from competitors.
Outside those three, a well-chosen package remains the better purchase, and an honest supplier will tell you so.
03. The signals of a budget about to slip
An overrun almost never arrives by surprise: it announces itself in the first exchanges. These signals are visible before signing.
- A quote handed over without a scoping phase, on the basis of a conversation.
- A scope described in adjectives — “complete”, “modern”, “scalable” — rather than in screens and rules.
- No mention of the existing data or its migration.
- Time-and-materials billing with no cap and no milestones.
- No demonstration planned before final delivery.
04. What you must receive at the end
The deliverable of a custom build is not only an application that works. What protects you is what comes with it: the source code, its documentation, the hosting access.
Without those, you do not own your tool; you rent the availability of whoever wrote it. That is a point to settle in writing before starting, not at delivery.
- The source code and its history.
- The technical documentation and deployment procedures.
- Access to hosting and third-party services.
- A warranty period, then a costed maintenance contract.