Web application development services built around who is allowed to see what
The hardest problem in an application is not the feature list. It is making certain that one customer can never reach another customer data, on every route, forever. That never shows up in a demo, because a demo has one user.
Permissions modelled before features, enforced server side, and tested as a matter of course rather than checked by hand at the end.
What are web application development services?
Web application development services build software that runs in a browser and does work on behalf of a logged-in user: portals, dashboards, internal tools, booking and quoting systems, marketplaces and SaaS products. The defining features are accounts, stored state, permissions that differ by user, and business logic that has to stay correct as data changes.
The difference from a website is not size or budget. It is that a website mostly shows the same thing to everyone and can be cached, while an application computes a different answer for every user and has to be right every time.
Do you need an application or a website?
This is worth settling before anyone quotes, because the two carry different risks and different ongoing costs.
You want a website
The valuable behaviour happens before a login. Content changes often, logic rarely, and most visitors are anonymous. A gated download or a single client area does not change this. Start with custom web development.
You want an application
The valuable behaviour happens after a login. Users have roles, records change, and two people signed in at once should see different things. Testing, permissions and data correctness dominate the work.
Getting this wrong in either direction is expensive. Building an application when a website would do buys you years of maintenance you did not need. Building a website when the requirement was an application produces something that works in the demo and falls apart on the second customer.
Permissions are where applications actually fail
Broken access control is the most common serious weakness in web applications, and it sits at the top of the OWASP Top 10. It is not an exotic attack. In its most ordinary form somebody changes a number in a URL and sees a record that belongs to another company.
The reason it is so common is that it is invisible during normal development. A developer signed in as one user, clicking through the interface the way it was designed to be clicked, will never encounter it. The interface does not offer a link to another customer record, so the absence of a check goes unnoticed until somebody types the URL directly.
The rule we build to: every request re-checks that this user may act on this specific record, on the server, regardless of what the interface offered. Hiding a button is presentation. It is not access control, and anyone can call the endpoint the button would have called.
This is also why we write automated tests for permissions rather than checking them by hand. Hand-checking works once, on the day it is done. A test runs on every change and catches the release six months from now where somebody adds an endpoint and forgets the check.
What has to be decided before anyone builds a screen
These decisions are cheap at the start and extremely expensive to revisit once real customers have data in the system.
The permission model
Who exists, what roles they hold, and what each role may do to which records. Written down as rules before it is written as code, because retrofitting this into a working application is close to a rewrite.
Tenancy
If several organisations use the system, how their data is separated and enforced. This decision reaches into every query in the application and is the one most often made by accident.
The data model
What the real entities are and how they relate. Application data outlives the interface, survives redesigns, and is the part you genuinely cannot afford to get wrong.
History and audit
Whether you need to know who changed what and when. Trivial to include from the start, and impossible to reconstruct later for the period before you added it.
How change ships
Migrations, staged releases and rollback. An application with live users cannot be updated by copying files over the top and hoping nobody was mid-task.
What happens when it breaks
Error tracking, alerting and a support path. Applications fail for one user at a time, which means nobody notices unless something is watching for it.
How our web application development services run
Model
Entities, roles and permission rules written down and agreed before any interface work. This is the document the whole build is checked against, and the one that prevents the expensive class of mistake.
Thin slice
One real workflow built end to end, including authentication, permissions, storage and tests. It proves the architecture with something you can actually use rather than with a diagram.
Build in slices
Each workflow shipped complete rather than every screen half-built. You get something usable early, and scope changes cost a slice instead of a rewrite.
Harden and hand over
Permission tests across roles, load behaviour checked, monitoring and error tracking wired up, migrations and rollback documented, and the repository handed over in your name.
We do not quote applications as a single fixed lump for a fixed date. The requirements that matter are usually discovered by using the first slices, and a fixed-everything contract just moves that discovery into a change request argument.
What our web application development services include
Authorisation on every route
Server-side checks that this user may act on this record, applied consistently rather than per screen, with tests that fail the build if a route is left unguarded.
Authentication done properly
Established libraries or an identity provider rather than a hand-rolled login. Session handling, password reset and multi-factor where the data justifies it.
Tenant isolation
Separation enforced at the data layer so a missing filter in one query cannot leak across organisations, plus tests that specifically try to cross the boundary.
Automated test suite
Coverage concentrated on permissions, money and anything irreversible. Applications change constantly, and tests are what let you change them without fear.
Migrations and releases
Versioned schema changes, staged deployment and a documented rollback. Shipping to an application with live users is a procedure, not a file copy.
Monitoring and error tracking
Errors captured with the context to reproduce them, plus alerting, because an application usually fails for one user who then simply gives up and leaves.
Audit trail
Who changed what and when, on the records where it matters. Built in from the start because it cannot be backfilled for the past.
Accessibility to WCAG 2.2 AA
Applications are used all day by people who did not choose the software. Keyboard operation, focus management and clear form errors are functional requirements here.
Handover you can staff
Mainstream stack, documented decisions, a running local environment and everything in your accounts. If another team cannot take it on, the build is not finished.
When you should not build a web application
Building is the expensive answer and often the wrong one. These are the cases where we say so.
Existing software does 80% of it
If a product covers most of the requirement, the honest comparison is its subscription against building and then maintaining your own forever. Configuring something established usually wins, and it wins by a wide margin.
The process is not settled
If the workflow still changes month to month, encoding it in software freezes a process nobody has finished designing. Run it manually until it stops moving, then automate the version that survived.
Only a handful of people will use it
For a small internal team, a well-structured shared sheet plus a couple of automations often delivers the same outcome this quarter for a fraction of the cost and none of the maintenance.
There is no budget after launch
An application is a commitment, not a delivery. Dependencies age, browsers change and users ask for things. Without an ongoing budget it starts degrading the week it launches.
Where the requirement is really about connecting systems you already run rather than building a new one, workflow automation is usually faster and cheaper to own, and we would rather point you there.
Web application development services alongside the alternatives
Web Development
The parent service, covering build standards, the performance budget and what happens after handover.
Explore web development →Custom Web Development
When the valuable behaviour happens before a login and the site presents rather than computes.
Explore custom development →Workflow Automation
For connecting systems you already run. Often delivers the outcome without a new application to maintain.
Explore workflow automation →AI Agent Development
When the logic is judgement rather than rules, with permissions, step budgets and cost ceilings set before the build.
Explore AI agents →SaaS SEO
If the application is the product, this is how people find it once it exists.
Explore SaaS SEO →Website Maintenance
The ongoing obligation that begins at launch, which for an application is a requirement rather than an option.
Explore maintenance →How much do web application development services cost?
Cost follows the number of distinct workflows and the number of roles, because each role multiplies what has to be built and tested. Screens are the cheap part.
Internal tool
$15,000 to $40,000. One or two roles, a handful of workflows, a known user group. Typically two to four months. The most common project we take and the one that pays back fastest.
Customer portal
$40,000 to $100,000. External users, multiple organisations, tenant isolation and integrations with the systems you already run. Four to eight months, built in slices.
SaaS product
$100,000 upwards. Where the application is the business. Billing, subscription states, onboarding and support tooling are all part of the product, not extras added later.
Budget 20 to 25% of build cost per year to keep it running, which is higher than a website because dependencies move faster and users keep asking. Add hosting, error tracking and any identity or payment provider on top. An application quoted without those numbers has not been quoted honestly.
Common questions about web application development
A website presents largely the same content to everyone and can be cached. An application computes a different answer for each logged-in user, stores state, and has to remain correct as data changes. The practical test is whether the valuable behaviour happens before or after a login. A marketing site with one gated area is still a website.
Two to four months for an internal tool, four to eight for a customer portal, and longer for a product where billing and onboarding are part of the scope. We build in slices, so you have something usable well before the end. The parts that extend timelines are integrations with systems you do not control and permission rules that turn out to be more nuanced than anyone said.
Buy if existing software covers most of it. The comparison people get wrong is subscription cost against build cost, when it should be subscription cost against build plus maintenance plus the internal time to specify and test it, for as long as the business runs. Building wins when the workflow is genuinely yours, or when the application is what customers pay for.
By enforcing it at the data layer rather than trusting each query to remember. Every request re-checks that the signed-in user may act on that specific record, on the server, and the test suite deliberately attempts to cross tenant boundaries so a missing filter fails the build rather than reaching production.
Yes, starting with an audit of permissions, data model, tests and dependencies. We will not take responsibility for an application we have not read. That audit sometimes finds work that has to happen before new features are sensible, and we would rather say so before quoting a roadmap that sits on top of something unstable.
Usually not at first. A well-built responsive application works on phones, needs no app store approval, and updates for everyone at once. Native apps earn their cost when you genuinely need offline use, push notifications or device hardware. Building both from the start doubles the surface area before anyone has confirmed people want the first one.
You should be able to. The repository, hosting and accounts are yours throughout, the stack is mainstream enough to hire for, and the documentation covers decisions rather than restating the code. A reasonable test at any point is whether another developer could run it locally from the README alone.
Find out whether you need an application at all
Tell us the workflow you are trying to fix and we will map the roles, the records and the rules, then tell you honestly whether this is a build, a configuration of something that already exists, or an automation between the tools you already run. No obligation, no sales pitch.
Get my free build review- Roles and permissions mapped
- Build, buy or automate
- True cost of ownership