Service
Custom web application development
Platforms that hold up under real load, real data and real users.
Web is where most of what we build lives: internal platforms that run a business, customer portals, dashboards over real operational data, and public sites that have to be fast and findable. Built as applications rather than assembled from plugins, which is what makes them changeable a year later.
The decision
When this is the right call.
The decision is rarely custom versus nothing. It is custom versus a platform plus the plugins needed to bridge the gap between what it does and what you need. That stack is cheap to start and expensive to own: every plugin is a dependency, a performance cost and a security surface, and the combination breaks on the platform's next major release.
The second cost is the ceiling. Platform-based builds are quick until the first requirement the platform cannot express, and then the workaround becomes the architecture. Businesses end up designing around their software rather than the other way round, which is exactly the position the software was bought to avoid.
Custom is worth it when the domain logic is the product, when the data model is genuinely yours, or when performance and integration matter enough to be engineering decisions. When none of those are true we say so - a well-chosen platform is a better answer than a build we would enjoy more.
What you get
What the work covers.
Architecture that survives growth
Data model, boundaries and deployment decided before the first screen, because these are the choices that are expensive to reverse.
Server-rendered where it matters
Pages a crawler and a slow phone both receive complete, with interactivity layered on rather than required for the content to appear.
Real authorisation
Permissions enforced on the server against every request, not hidden menu items. Checked by tests that try to break them.
Performance as a budget
Core Web Vitals treated as a build constraint with a number attached, not a report run after launch.
Accessibility built in
Keyboard paths, focus handling, contrast and semantics from the first component, which is cheaper than retrofitting and also better for search.
Operable in production
Logging, error reporting, backups and a rehearsed restore, because software that cannot be operated is not finished.
Stack
What we build it with.
Chosen per project. Nothing here is applied by default, and the team who will maintain it counts as much as the problem.
Frontend
TypeScript with React or server-rendered templates, chosen per project. No framework is applied by default.
Backend
Python, Node or .NET, matched to the team who will maintain it as much as to the problem.
Data
PostgreSQL or MySQL, with the schema designed rather than generated. Redis where caching genuinely helps.
Infrastructure
Linux, nginx, containerised where it earns its complexity, on your cloud or ours.
Delivery
Version control, automated tests and a deploy pipeline from day one, not added once it hurts.
Comparison
Platform build vs custom build.
The comparison worth running before you commission anything. For a large share of projects the left column wins, and we will say so.
| Aspect | Platform + plugins | Custom build |
|---|---|---|
| Time to something usable | Days. This is a real advantage and it is often decisive. | Weeks. Justified only when the platform cannot express what you need. |
| Cost shape | Low and recurring: licence, per-seat growth, per-plugin subscriptions, the implementation partner | High and one-off, then hosting. The code is yours with no runtime licence. |
| The ceiling | Reached at the first requirement the platform cannot express; the workaround then becomes the architecture | Set by your own design decisions rather than someone else's roadmap |
| Dependency surface | Every plugin is code you did not write, on its own release cycle, in your security perimeter | Only the libraries you chose, reviewed and pinned |
| Major version upgrades | The plugin combination is what breaks, and it breaks on someone else's schedule | You choose when, and the tests tell you what moved |
| Performance and Core Web Vitals | Theme plus plugin overhead, addressed by adding a caching plugin | A build constraint with a number attached, enforced in the pipeline |
How it runs
From first conversation to live.
Indicative for work of this shape. The pilot is not optional — nothing is switched over until the people using it say it holds.
- 1-2 weeks
Discovery
We model the data and the roles first. This is where the cost actually lives and where platform builds usually go wrong - not in the screens.
- 4-8 weeks
Core build
The highest-traffic path end to end, with your real data loaded and a deploy pipeline from the first week rather than added once it hurts.
- 2-3 weeks
Pilot
One team uses it for real work while the old process continues. Every gap they hit is fixed before anyone else is moved across.
- 1-2 weeks
Launch and handover
Remaining users, monitoring and backups with a rehearsed restore, and the documentation that lets another developer take it on.
After launch
What changes.
- The requirement that the platform could not express stops being handled by a person in a spreadsheet.
- Page performance becomes a number you hold rather than a plugin you hope is working.
- Upgrades stop being an event, because there is no plugin combination to break.
- A change you want in week sixty costs roughly what the same change cost in week six.
Described qualitatively on purpose. We do not publish percentage improvements we cannot attribute to a named client with their agreement.
Questions
Common questions.
How long does a custom web application take?
A focused internal platform is usually eight to fourteen weeks from first conversation to production. Larger multi-module systems run longer and are delivered in stages, with the first module live while the next is being built - we would rather you use something real early than wait for everything.
Do we own the code?
Yes, entirely, including the repository and the deployment configuration. There is no runtime licence and nothing that stops another developer taking it on.
Can you work with our existing system?
Usually. Most builds start by integrating with something already in place - an accounting package, an ERP, a legacy database. Replacing everything at once is rarely the right call, and a phased path is safer.
What happens after launch?
A support period is included, after which most clients take a retainer for changes and monitoring. Neither is a lock-in: the code is yours and documented well enough for someone else to pick up.
Should we just use a platform instead?
Often, yes. If your data model fits the platform and your differentiator is not the software, a platform is faster and cheaper and we will tell you so. Custom earns its cost when the domain logic is the product, when the data model is genuinely yours, or when integration and performance are engineering problems rather than settings.
What happens if our requirements change mid-build?
They will, and the plan assumes it. Phases are re-estimated at each boundary with what was learned, which is why we prefer a capped price per phase to a fixed price on the whole scope - the latter is either padded for risk or heading for a dispute the first time something moves.