Frontend
Fast, accessible interfaces that work on a cheap phone as well as a big monitor.
For CTOs and engineers
How we build, and the tools we trust
Our service pages are written for the people who run the business. This page is for the people who will review our pull requests. It covers the stack we know well, the standards we hold ourselves to and exactly what you get when a project is handed over.
$ git initOur first commit went in back in 2014. We have been shipping ever since.
Our approach
Boring technology, chosen on purpose
New tools are fun. Paging someone at three in the morning is not.
We default to mature technology with good documentation and a large community, because that is what your future developers will be able to hire for and maintain.
We pick something newer only when it clearly solves a problem the proven option cannot, and we write down why in an architecture decision record so the reasoning outlives the conversation. If your team already knows a stack, that counts for a lot. We would rather extend what you have than rewrite it in our favourite language.
The stack
What we work with most
Not an exhaustive list, and not a promise to use all of it. These are the tools we have run in production and can support with confidence.
Backend and APIs
Plain services with thorough tests, documented APIs and no clever tricks to untangle later.
Data
Lakehouses, pipelines and reporting that finance and compliance can trust.
Cloud and infrastructure
Everything defined in code, deployed by pipelines and watched by monitoring.
Mobile and devices
Apps and connected prototypes that bring sensors, phones and cloud dashboards together.
Distributed ledgers
Used only where several organisations genuinely need to share one record.
Engineering standards
What you can expect on every project
These apply whether we are building something new or working inside your existing codebase. Where your team already has standards, we follow yours.
-
Code review
Every change goes through a pull request and is reviewed by a second engineer before it reaches the main branch. Reviews look at readability and risk, not just whether it works.
-
Automated testing
Unit tests for business rules, integration tests for the places where systems meet, and a handful of browser tests for the journeys that make you money. All of them run on every change.
-
CI/CD
Builds, tests, security scans and deployments run in pipelines, never from someone's laptop. Releasing becomes small, frequent and dull, which is exactly how it should feel.
-
Infrastructure as code
Cloud resources are defined in Terraform or Bicep, reviewed like application code and reproducible from scratch. No servers built by hand that only one person understands.
-
Observability
Structured logs, metrics, traces and alerts that point to a cause, with dashboards your own team can read. We would rather hear about a problem from a graph than from a customer.
-
Documentation
A README that gets a new developer running in an afternoon, architecture diagrams kept next to the code, decision records for the important choices and runbooks for when things go wrong.
Security
Secure by default, reviewed like an attacker would
Our team includes a Certified Ethical Hacker, which changes how we look at our own work. We assume someone will try to break it and design accordingly.
- Threat modelling for anything that handles money or personal data.
- Access limited to what each person and service needs, with SSO and MFA for everyone.
- Secrets held in a managed vault, never in code or chat messages.
- Dependency and container scanning on every build, with alerts for new vulnerabilities.
- Encryption in transit and at rest, and personal data masked outside production.
- GDPR considered at design time, with data kept only as long as it is needed.
- Independent penetration tests welcomed, and findings fixed promptly.
Delivery
How work moves from idea to production
We are pragmatic about process. The right amount is the least that keeps everyone informed and the work flowing.
Scrum or Kanban, sized to the team
Short planning, a visible board and a regular demo of working software. We drop any ceremony that is not earning its place. Our team includes a Professional Scrum Product Owner who knows the difference.
DORA metrics, tracked honestly
Deployment frequency, lead time for changes, change failure rate and time to restore service. We share them with you, including when they look bad, because that is when they are most useful.
Handover
What you own when we step back
From the first day, the work lives in your accounts. Handover is a checklist, not a negotiation.
- All source code in your own Git repositories, with full history.
- Cloud resources in your subscriptions and accounts, defined in code.
- Admin access for your team, and ours removed on a date you choose.
- Architecture diagrams, decision records and a README that matches reality.
- Runbooks for deployment, incidents, backups and restores.
- A walkthrough session with your developers, recorded if you like.
Next step
Want to talk to an engineer?
If you're evaluating us for a project, we're happy to go deep on architecture, code samples and how we'd approach your system. Bring your hardest questions.