Loading
Product line
The artefact is a typed domain model, an authorisation layer that is tested rather than assumed, a working transaction path on real data, and an audit record of every state change.
Web platform · in the build
Anatomy
A web application is mostly four things, and only one of them is screens. The order matters: the model constrains the interface, never the other way round.
What the entities are, which states each one moves through, who may move it, and what must be recorded at each move. This is the expensive thing to change later, so it is settled first, in writing, with the people who perform the process.
Signing in is the easy half. The half that matters is whether a user can read or change a specific record — enforced on the server for every request, tested as its own suite, and never left to a hidden menu item.
The core sequence the business actually runs, built end to end on real data before any convenience feature. You get something usable early rather than a demonstration late.
Agreed metric definitions, exports people can take away, and an immutable record of who changed what and when. Reporting built on a disagreement about definitions just distributes the disagreement faster.
Why it matters
The same artefact described above, read as outcomes rather than as engineering. Each one follows directly from a decision already explained on this page.
Permissions enforced on the server, not just hidden in the interface, mean a support agent or a departed employee can't reach a record they shouldn't just because a button wasn't shown to them.
An append-only audit trail means "who changed this, and when" has a real answer the day an auditor or an unhappy customer asks it, instead of a shrug.
Building the core transaction path on real data first means the business gets a usable system in weeks, not a polished demo that slips to eighteen months.
Bulk operations running in a queue with retries and a named failure report mean a large monthly import doesn't time out and silently drop half the rows.
Infrastructure defined in code means a second environment, or a recovery from an incident, is a command to run rather than a week of archaeology.
Key features
Behaviour of the built thing, not a list of adjectives. Every entry below is something you can check after delivery.
Where a website publishes, a web application computes. People sign in, records change hands, permissions decide who may do what, and somebody eventually has to answer the question "who changed this, and when". That last question is the one that separates a real platform from a form with a database behind it, and it is designed in at the start rather than added when an auditor asks.
Technology
A stack we actually run in production. Where your team already has a preference and it is a reasonable fit, we work in yours instead of arguing for ours.
Runs on
Before we quote
These three are the difference between a platform that extends cleanly and one that has to be rewritten in year two.
Not job titles — capabilities. A supervisor who may approve up to a limit and view every branch is a different thing from a supervisor who may approve anything in their own branch only. We write the matrix out and turn it into tests, because a permission model discovered feature by feature ends up as a pile of special cases nobody can reason about.
This sets both the cost and the fragility of the integration, so we check it early rather than mid-build. The practical question is what your existing systems expose: a documented API, a supported database view, a scheduled file exchange, or nothing at all. "Nothing at all" is a real answer and it changes the plan rather than ending it.
Migrating five years of records with inconsistent formatting is frequently larger than building the new system. Sometimes the right answer is to bring across open items only and keep the old system readable for reference. That decision belongs to you, and it should be made with the size of the work visible rather than assumed.
Pricing and engagement
There is no fixed price for web applications because the scope varies by how many roles and states the domain model actually has, and how much of it already exists — here is how the work is actually engaged, and which of these usually fits this product line.
For work where the requirements are genuinely settled. A written scope, a phased plan and a price we hold. Best for a defined build, a migration, a security engagement or a design phase.
Named engineers at a monthly rate, working on your board and in your repository. The right shape when the roadmap is still moving, which is most products after their first release.
Ongoing maintenance, monitoring response, dependency updates and a block of hours for changes, under a written arrangement agreed before launch rather than during an incident.
Where it is used
Sectors where we are asked for this artefact most often. It is a statement about the fit of the shape, not a client list.
How the work is run
This page describes the artefact. Scope, delivery model and engagement terms live on the service pages, which is where they belong — follow whichever applies rather than reading it twice.
Questions
Mostly by who uses it. A web application here typically has users outside the building — customers, dealers, suppliers, field staff — which means public exposure, self-service onboarding and a support surface. Custom software is usually internal, with named users and a process to encode. The engineering overlaps heavily; the risks and the release rhythm do not, so we keep them separate on this page.
Yes. Everything we build is containerised and defined in code, so an on-premises deployment is a target rather than a rewrite. What changes is who holds the operational burden: backups, patching, certificates and monitoring become yours or become a support arrangement. We will lay out both versions with their real ongoing costs.
Indexing, pagination and query shape are design decisions, not a later optimisation, and we test against a data volume in the range you expect rather than against twenty demo rows. Where a report genuinely cannot be fast against live tables we say so and build a read model for it, rather than letting a dashboard slowly become the thing that stalls the database.
Yes, in your repository, from the first commit rather than at the end. The handover documentation is written as the work happens, because documentation written in the last week is a summary of what somebody remembered. That includes the domain model, the permission matrix, the runbook and the decisions we made and rejected.
By building the transaction path first and refusing to widen it. The core sequence, on real data, in production, with a small group of real users — then reporting, then integrations, then convenience. A release that tries to be complete before anyone uses it accumulates guesses, and every guess is a thing to unpick later.
Also in products
Internal system
An internal system shaped to a process no package models correctly — with the exceptions encoded, not ignored.
SaaS product
A multi-tenant product with the boring half finished: tenancy, billing, onboarding and the admin console.
Describe what the finished thing has to do and who has to use it. We will tell you which parts of a web applications build are the expensive ones in your case, and where a smaller first release would get you most of the value.
What happens next
