Web Application Development Services
Software with accounts, roles, and real data behaves nothing like a website. It's never finished, it's used every day by people who notice when it changes, and the expensive mistakes are made in the first fortnight of scoping.
Getting the category right
The distinction matters because it changes the cost, the timeline, and what happens after launch. Plenty of projects described as apps are websites, and a few described as websites are quietly applications.
Scoping
Every feature sounds essential during scoping. Most of them aren't, and the ones that genuinely are only become obvious once people are using the thing. A large version one is the most reliable way to spend a lot of money on features nobody opens.
A typical version one
The invisible half
Permissions is the clearest example. It sounds like one line in a scope and it's a grid of decisions, every cell of which has to be decided, built, and tested.
Someone will always need to fix a record, resend an invitation, or undo a mistake. Without an admin view, that becomes a developer task forever, and every one of them costs you money.
Payment declined, upload interrupted, two people editing the same record. These aren't rare once you have real users, and deciding the behaviour late means rebuilding something.
An export sounds like a nice extra until you want to move, report on something the app doesn't cover, or prove what happened. It's cheap to build in and awkward to retrofit.
How it gets built
Long silent build periods are how projects end in an unpleasant surprise. You should be able to click through the thing well before it's finished.
Stage 01
What the app stores and how those things relate. Get this wrong and everything built on top inherits the problem, so it's settled before interface work starts.
Stage 02
Accounts, permissions, and the core workflow end to end. Unglamorous, and it's the part that decides whether the rest is straightforward or painful.
Stage 03
A small group using it properly on staging, with their own data. Invented test data hides the problems that matter, because nobody invents the awkward cases.
Stage 04
Released with a rollback path and somewhere for users to report problems. Then the next set of work gets chosen from what usage actually showed.
Changes after launch are normal and expected, not a sign that scoping failed. Any application in genuine use generates requests, because people find out what they need by using it.
Before you commit
This gets left out of a lot of proposals because it makes the number look worse. It's better to know it before you start than to discover it in month four.
Hosting, a database, backups, and any services it depends on. Small at first, and it scales with your usage, so it's worth understanding the shape of that early.
Libraries get security updates, platforms change their interfaces, and browsers change behaviour. An app left untouched for two years becomes expensive to restart work on.
Somebody has to answer questions, fix data, and decide which suggestions become work. That's a real job even at modest scale, and it usually lands on whoever is least busy.
Retain us, hire your own developer, or take it in house once it's stable. The documentation and code are written to make all three possible. Smaller pieces of work sit under custom web development.
Common questions
The range is wide enough that a number here would be meaningless. What decides it is how many distinct workflows exist, how many roles, and what it has to connect to.
The more useful exercise is scoping a version one and pricing that, because it's the number you'd actually be committing to. Bigger ambitions get sequenced rather than priced up front.
Worth asking properly, because the answer is a website more often than people expect. If users aren't creating and changing their own data, and nobody needs to see something different from anyone else, it's probably a website.
The cost difference is large and it continues after launch, so this is a question worth spending half an hour on.
Yes, and for anything unproven it's usually the sensible order. A clickable prototype settles arguments about how it should work without anybody paying for the version that gets thrown away.
The thing to agree up front is whether the prototype is disposable or the beginning of the build, because that changes how it's made.
You do. Code ownership transfers on final payment and it's written into the agreement. Hosting and any service accounts are set up in your name from the start rather than under ours.
The data is yours throughout, and the export exists partly so that's not a theoretical statement.
The basics are not optional and they're built in: proper authentication, permissions enforced on the server rather than only hidden in the interface, encrypted connections, and dependencies kept current.
If you're handling payment details, health information, or anything with a specific compliance regime attached, say so at scoping. That changes architecture decisions and it isn't something to bolt on afterwards.
It'll work in a phone browser, and for most applications that's sufficient. Whether every screen deserves a properly designed mobile version depends on who uses what, and that's a scoping decision rather than an assumption.
If you need something installed from an app store with offline use or device features, that's a different project and it sits under app development.
If what you need is functionality added to an existing site rather than an application in its own right, custom development is the closer fit. Pricing sits on the main web development page.
Other development services
Thirty minutes on what the app needs to do, who uses it, and where the line should sit for a first launch.
Or email hello@culmen.digital