Service
Web development
Web applications that stay fast and maintainable after the launch team has moved on.
At a glance
- Typical timeline
- Eight weeks for a bounded rebuild; six months or more for a platform
- Indicative price
- Pending commercial sign-off · see engagement models
- Stack we default to
- TypeScript
- React
- Next.js
- Node.js
- PostgreSQL
- Kubernetes
- Engagement models
- Fixed-scope sprint
- Time and materials
- Dedicated team
The problem this addresses
Most web platforms do not fail at launch. They fail eighteen months later, when the people who understood the decisions have left and every change costs more than the last one.
What you get
- 01A running application in your environment, with the deployment pipeline that put it there
- 02Automated test coverage on the paths that carry revenue or risk
- 03Performance budgets enforced in continuous integration, not checked manually before release
- 04Documentation of the decisions that would otherwise only exist in someone's head
- 05A handover period where your engineers deploy while we watch
How the work runs
- 01
Technical discovery
We read the existing code and talk to the people operating it before proposing anything. Where there is no existing system, we prototype the riskiest assumption first.
- 02
Architecture and budget
An agreed architecture with explicit performance and accessibility budgets, written down before implementation starts.
- 03
Iterative delivery
Two-week iterations, each ending with something deployed to a real environment. Nothing accumulates in a branch for a quarter.
- 04
Handover
Your team runs the last deployments. If they cannot, the engagement is not finished.
Where this fits
Web development is the right label when the deliverable is a browser-based application: a customer portal, an internal operations tool, a data-heavy dashboard, a marketing platform with real application behaviour behind it.
If the problem is primarily an integration between systems, API development is closer. If it spans mobile and web with shared logic, start at custom software.
How we keep the second year cheap
The cost of a web application is dominated by change after launch, not construction before it. Three things do most of the work in keeping that cost down: tests on the paths that matter, budgets enforced automatically, and written decisions. None of them are glamorous and all of them are in scope by default.
Proof
Work delivered with this service
Saltea
Rebuilding subscription billing and entitlements at Saltea
Every price change at Saltea needed an engineering release, and mid-cycle plan changes were priced three different ways. We moved pricing out of the application and rebuilt the billing surface on top of it.
Vertigem
Making offline receipt capture reliable in Vertigem's expense platform
Receipts captured outside mobile coverage were dropped without anyone noticing, on shared handsets that killed the app mid-upload. Our engineers worked inside Vertigem's squads on the capture path and the reconciliation queue.
Questions
What clients ask before starting
Will you work in our existing codebase or insist on a rewrite?
We work in the existing codebase by default. A rewrite is occasionally the right answer, but it is expensive and risky enough that it needs to be argued for with evidence, not assumed. Most engagements that start as "we need a rewrite" turn out to be two or three bounded pieces of work.
What happens to the code and infrastructure when we stop working together?
You own it throughout. Repositories are in your organisation, infrastructure is in your accounts, and the pipeline is yours. There is no vendor-hosted component you have to keep paying for to keep the application running.
How do you keep performance from degrading after launch?
Performance budgets run in continuous integration and fail the build when breached, so a regression is caught at the pull request rather than discovered by a customer. We set the thresholds with you during architecture, and they are visible in the repository.
Can you work with our in-house designers?
Yes, and it usually works better that way. We need a design system or component inventory to build against; if one does not exist, we can help establish it, but we would rather your team owns the visual language.
