Web Development
Web Application Development
Portals, tools, dashboards and internal systems. Different from a website in almost every respect that matters to a quote.
A web application is software that runs in a browser rather than a website with forms attached. The Nexclick scopes the logic, the permissions and the edge cases before quoting, because applications fail on the states nobody specified rather than on the features everyone discussed.
Is this you?
What usually prompts the call
- Your business runs on a spreadsheet several people edit and nobody trusts.
- You have a process that works and cannot scale because it depends on one person.
- You need customers or staff to log in and do something a CMS was never designed for.
- You have been quoted for a "website" that is clearly an application.
What we do
The actual deliverables
Things that appear on an invoice, not adjectives.
- Requirements and logic scoping
- What the system must do, who can do what, and what happens when things go wrong. Applications are quoted from this, never from a feature list.
- Permission and role modelling
- Who sees what and who can change it, mapped before development. Retrofitting permissions into a working application is one of the more expensive things you can do.
- Data model design
- The structure everything else depends on. Getting it wrong is recoverable early and progressively more expensive with every week of real data.
- Edge case specification
- Concurrent edits, partial failures, permission changes mid-session, data that arrives incomplete. These are where applications actually break.
- Interface design for repeated use
- Efficiency rather than persuasion. A screen someone uses forty times a day has different requirements from one they see once.
- Automated testing
- Critical journeys covered by tests, so a change in month eight does not silently break something built in month two.
- Deployment and monitoring
- Staging, a deployment pipeline, error reporting and uptime monitoring. An application without error reporting is one where you find out from a user.
Decision tree
Do you need an application, or something cheaper?
Custom software is the most expensive way to solve a process problem and frequently not the right one. Work through these first — several branches end somewhere considerably cheaper than a build.
01The process works and only breaks at a scale you have not reached
Wait. Building for a scale you may never hit is the most common waste in this category, and the spreadsheet is cheaper than the software until it genuinely is not.
02An off-the-shelf product does 80% of it
Buy it and adapt your process. Custom software to avoid changing a process is almost always the more expensive option over five years.
03The problem is data moving between systems you already own
Automation, not an application. n8n, Make or Zapier will connect them for a fraction of the cost and a fraction of the maintenance.
04You need a form, a database and a few reports
A no-code tool — Airtable, Notion, a low-code platform — will do it faster and you can change it yourself.
05The logic is genuinely specific to how your business works
Custom is justified. This is the case where off-the-shelf forces you to work in a way that costs you your advantage.
06You will sell access to it as a product
Custom, and it is SaaS development rather than a web application — multi-tenancy, billing and onboarding change the scope substantially.
07You need it integrated with a system nothing else talks to
Custom, or custom integration around an off-the-shelf core. Scope the integration before deciding, since it is usually the expensive half.
How it works
Step by step, with timeframes
Timeframes are typical rather than guaranteed, and they assume we get account access and approvals when we ask.
- 01Week 1–4
Discovery and specification
Logic, roles, data model and edge cases, written down and agreed. The longest scoping stage of anything we build, and the reason the price holds.
- 02Week 4–6
Prototype the critical flows
Clickable prototypes of the journeys that matter most, tested with real users before development. Cheaper to change here by an order of magnitude.
- 03Week 6–20
Build in increments
Working software every fortnight, in an order that lets you use part of it before all of it is finished.
- 04Week 20–24
Test, deploy, support
Full testing including permissions and failure paths, deployment with monitoring, then a support period while real usage surfaces what testing did not.
What you get
Reporting and ownership
- A written specification covering logic, roles and edge cases before a price is agreed.
- Working software every fortnight, in an order that lets you use part before all of it exists.
- Automated tests on the critical journeys, so later changes cannot silently break earlier work.
- Error monitoring configured from launch, so you learn about failures before your users tell you.
- Full repository ownership and documentation sufficient for another developer to continue.
Tools and platforms
- Next.js, Laravel or Node.js
- PostgreSQL or MySQL
- TypeScript
- Playwright & Vitest
- Sentry or equivalent error reporting
- Git-based CI/CD
Timeline
How long this actually takes
Twenty to twenty-six weeks for a substantial first version, of which three to four are scoping. Applications are quoted from a specification rather than a conversation, and where a client wants a price before scoping, the honest answer is a scoping engagement first. Two things worth saying plainly. Applications are never finished — budget for ongoing development, because the first version teaches you what the second should be. And building software to replace a spreadsheet is often the wrong call: if the spreadsheet works and only breaks at scale you have not reached, wait.
Pricing model
Project, then retainer
A fixed-price discovery and specification engagement first, then either a fixed price against that specification or a monthly team rate for ongoing development.
Questions
Web Application Development questions
Why can you not quote from our feature list?
Because a feature list describes what the software does when everything goes right, and the cost is in what happens when it does not. Two applications with identical feature lists can differ threefold on permission complexity and edge cases alone. That is what the specification stage establishes.
Should we replace our spreadsheet with software?
Only when the spreadsheet is genuinely failing — data conflicts, no audit trail, more editors than it can survive. If it works and you are anticipating scale you have not reached, wait. Software built for a future you never arrive at is the most common waste in this category.
How do you handle changes mid-build?
Quoted against the specification before anything is done. Some change is normal and expected — the first version always teaches you something. What we avoid is absorbing changes silently and presenting a larger invoice, or refusing all change and delivering something nobody wants.
What happens after the first version launches?
Real usage surfaces what testing did not, so budget for a period of adjustment. Applications are never finished, and the honest planning assumption is ongoing development rather than a single project with an end date.
Can we start small and expand?
Yes, and it is usually the better approach. Build the part that solves the most painful problem, use it, then extend. What matters is that the data model and architecture anticipate the expansion — that is a scoping decision, not something to bolt on later.
Who owns the code and can anyone else maintain it?
You own it, in your repository, with documentation written for a developer who has never seen it. That is deliberate. Software only one supplier can maintain is a commercial risk to you regardless of how good the supplier is.
Last reviewed 28 July 2026.
Tell us what you are trying to fix
A 20-minute call, no pitch deck. The Nexclick will tell you what we would do, roughly what it costs, and whether we are the right people for it.