Expect BestWeb application development is often described as a bigger version of building a website. It is not, and the difference matters because it changes what you are buying, what it costs and what can go wrong. Plenty of businesses across the UK commission one without ever being told what separates the two.
A website presents information. An application does work: it holds state, enforces rules, and different people see different things depending on who they are.
What actually makes it an application
Three things, usually. There are user accounts, and what you can see depends on which account you are. There is data that changes and has to stay consistent, so two people acting at once cannot leave it in a nonsensical state. And there is business logic, meaning rules specific to how your organisation works rather than to how websites generally work.
Once all three are present, the plugin approach stops being viable. That is the practical dividing line, and it is worth establishing early, because a quote for a website and a quote for an application are not comparable numbers. Two firms quoting wildly different figures are often answering two different questions.
What web application development costs in the UK, and why
Not where people expect. The screens are rarely the expensive part. The cost is in the awkward exceptions, the things everybody in your business knows and nobody writes down. What happens when a customer part pays. What happens when a job is cancelled after the parts are ordered. Who is allowed to override a price, and whether that gets recorded.
Every one of those is a decision, and decisions nobody made during discovery become change requests later, at a worse price. This is why a serious discovery stage saves money rather than costing it.
The other underestimated cost is the ongoing one. Hosting, framework updates and a support arrangement are not optional for software your business depends on, and they should be in the budget from the start.
How long it takes
A focused first version is usually eight to sixteen weeks. Quotes far below that are describing a prototype, and quotes far above it usually mean the project has not been broken into stages properly.
Staging matters more than the total. Get something real in front of the people who will use it early, because their first week of actual use will tell you more than three months of meetings did.
Expect the first version to be wrong in places. That is not a failure of planning, it is the only reliable way to find out what the software actually needs to do, and building in stages is what makes being wrong cheap.
When not to commission one
If a well known product does most of it and the gap is a preference rather than a cost, buy the product. If the process changes every few months, wait for it to settle, because you will be paying to rebuild the same thing repeatedly. And if nobody internally will own the project, do not start: these builds fail far more often through the loss of the person who understood the requirement than through anything technical.
What good looks like from your side
You should finish with code in a repository you own, your data, documentation, and a support arrangement you understand. You should have seen the thing in stages rather than at the end. And you should have been told no at least once during scoping.
If you want an honest read on whether your project is a website or an application, our Laravel development and custom systems pages explain how we approach each, and the answer is sometimes that you need neither.