Web application development for systems that have to last
Customer portals, internal tools, APIs and the admin panels behind them — built on deliberately conventional technology, because the fashionable stack is usually the one nobody can maintain in three years.
What we actually get asked for.
Few of these projects are public marketing sites. Most of it is the software a business runs on.
Customer portals
Where your clients check orders, download documents, raise tickets and pay. The hard parts are rarely visual: permissions per account, audit trails, document generation and an authentication model that survives a security review.
Internal business tools
The systems that replace a spreadsheet nobody is allowed to touch. Scheduling, stock, quoting, approvals, reporting. Built around how the work is actually done, which is usually not how the process documentation says it is done.
APIs and integrations
REST and webhook layers that connect what you run to what your partners run. Rate limiting, retries, idempotency and useful error messages — the parts that decide whether an integration is a one-off or something you can rely on.
Conventional on purpose, and documented.
We pick technology on one criterion above all others: whether a competent team other than ours can pick it up in three years and understand it. That rules out a lot of what is fashionable at any given moment, and it is the single decision that most affects what the software costs you over its life.
Stack
PHP and Node.js on the server, PostgreSQL or MySQL for data and plain server-rendered pages wherever a single-page application would only add moving parts. React or Vue when the interface genuinely needs it — a dashboard with live state, a complex editor, a drag-and-drop planner. We host what we build, so we carry the cost of any over-engineering ourselves.
What comes as standard
- Automated tests around the parts where a bug costs money — billing, permissions, data integrity
- CI/CD with a staging environment that mirrors production, so releases are routine rather than an event
- Database migrations under version control; no manual schema changes applied straight to a live system
- Structured logging and error alerting, so failures reach us before they reach your customers
- Written handover documentation — how it deploys, what it depends on, how to run it locally
Performance is a feature, not a phase
Slow software quietly costs more than it appears to: staff work around it, customers abandon it, and search engines rank it lower. We treat query plans, caching and payload size as part of the build rather than as an optimisation project scheduled for after launch — a date that, in practice, never arrives.
Things clients ask before starting.
Do you work with our existing system or replace it?
Who owns the code?
Can you host it as well?
How do you handle changes after launch?
Often built alongside.
Tell us what the system has to do.
A short description of the process and the systems involved is enough to start. We will come back with questions and a scoped estimate.