Accounts, permissions, relational data and workflow put a project into a different category of risk, testing and maintenance. It is worth knowing which side you are on.
Any one of them changes how it has to be built, tested and maintained.
Marketing sites and applications look similar in a design file and behave nothing alike in production. The distinction is not visual complexity. It is whether the system holds state that matters.
The first is accounts. As soon as users log in, there is authentication, session handling, password recovery, permissions and a real security surface. That is not a feature. It is a category change.
The second is relational data that users create. Records that reference each other, that have to remain consistent, and where an error is not a display problem but a wrong answer somebody acts on.
The third is workflow: states, transitions, approvals, notifications and audit. This is where most of the requirement lives and where most estimates go wrong, because a workflow described in a sentence takes a fortnight to build properly.
The fourth is anything with a compliance or financial consequence. Personal data at scale, payments, or records the business is required to retain. Those change the testing standard rather than the feature list.
Not the design work. Everything around it.
| Concern | Marketing website | Web application |
|---|---|---|
| Failure | A page looks wrong until it is fixed | Data is wrong, and someone may already have acted on it |
| Testing | Visual and journey checks | Automated tests around the logic that must not break |
| Security | Standard headers and a form | Authentication, authorisation and an ongoing responsibility |
| Data | Content, versioned in one place | User-created records requiring backup, retention and recovery |
| Change | Publish, and the change is live | Migrations, releases and a rollback that has been rehearsed |
| Maintenance | Dependency updates and content | Dependency updates, monitoring, backups and support |
This is why an application is never quoted from a written brief alone. The brief describes the features, and the cost sits in the states and the failure cases underneath them.
A bounded, paid stage with its own deliverable.
A specification, a data model, a screen inventory and a prioritised build order. That is usable by any developer, including one who is not us, which is the point.
Most application briefs contain a version that is half the size and delivers most of the value. Finding it is the highest-return hour of the project.
Applications usually have to talk to something else. The other system’s API, its limits and its owner set the constraints, and finding them after a fixed price is agreed helps nobody.
An application needs monitoring, backups, dependency updates and support. Deciding whether that is you, us or a third party is part of the design rather than a conversation after launch.
Discovery is credited against the build where the project proceeds.
Retrofitting any of these costs more than building them.
These are the parts that are invisible in a demonstration and decide whether an application survives its second year.
A restore that has never been tested is not a backup. It is a belief about a backup, and it is usually examined for the first time on the worst possible day.
Published starting figures in GBP and USD, excluding VAT.
Scoped after discovery
Software, not a site
From £4,000From $5,200
Authentication, application behaviour, relational data, private merchant tooling or a custom Shopify app. Requirements beyond what a marketing site or a theme can hold.
Starting price · scoped after discovery
One bounded piece
£1,500$2,000
One bounded improvement: landing pages, a template rebuild, an analytics implementation, or a build-readiness review credited against a larger project.
Fixed price
Monitoring, updates and capacity
Per month
From £1,250From $1,650
A live improvement programme on one site. You set the priorities each month, we work the queue in order, and the month closes with what changed and what it did.
Starting price
Per month
From £3,000From $4,000
Continuous delivery across an agreed portfolio, with planning ahead of the work rather than a queue you have to keep feeding.
Starting price
Applications are not instant-priced. Discovery is quoted on its own and credited against the build, because a fixed price offered before the data model exists is a number chosen for its persuasiveness.
After discovery, usually yes for a defined first release. Before discovery, no. A fixed price quoted from a written brief is either padded heavily or destined for a difficult conversation, and neither serves the project.
Sometimes not. A configured off-the-shelf tool, a spreadsheet with a proper process, or a small addition to a system you already run can be the better answer. We would rather say that than build something that duplicates a product you could subscribe to.
You do, on the terms set out in the agreement, and it lives in a repository you control. Nothing is held in an account only we can reach.
Applications need monitoring, dependency updates, backups and support. That is agreed as part of the project: it can be our ongoing responsibility, your team’s, or a third party’s, but it has to be somebody’s and it should be named before launch.
The current spreadsheet or manual workflow describes the requirement more accurately than a feature list.
