01/SOFTWARE ENGINEERING
We build the software, and we keep it running.
Web applications, SaaS platforms, APIs and the internal tools that hold a business together. Because the same team owns the infrastructure underneath, architecture decisions get made once, by the people who will carry them.
01/When you would call us
Four situations we hear a lot.
You have a product idea and a rough spec, and you want it running in production without a six-week discovery phase in front of it.
Your application works, but nobody wants to touch it. Releases are manual, the test suite is decorative, and every change carries risk that nobody can size.
You have designs from an agency and no engineering team to build them, and you would rather not hire four people before you know the product works.
An internal process runs on a spreadsheet that three people email around, and it has quietly become load-bearing for the business.
02/What we do
The work, itemised.
- Web applications
- Customer-facing applications in React and Next.js — server-rendered where it matters for speed and search, interactive where the product actually needs it.
- SaaS platforms
- Multi-tenant products with the parts that are painful to retrofit handled early: the tenancy model, authentication, roles and permissions, billing hooks and usage metering.
- APIs and backends
- HTTP and event-driven services in TypeScript or Python, with a documented contract, versioning that does not break existing clients, and authentication that survives review.
- Internal tools
- Admin panels, operations dashboards and back-office systems. Unglamorous work that takes a spreadsheet off the critical path and tends to pay for itself quickly.
- System integrations
- Connecting software you built to software you bought — CRMs, payment providers, ERPs, partner APIs — with retries, idempotency and a clear story for what happens when the other side is down.
- Legacy modernization
- Bringing an older codebase forward in increments, so the application keeps earning while it improves instead of stopping for a rewrite that overruns.
- Testing and quality
- Automated tests placed where they earn their keep: unit tests around the logic, integration tests at the boundaries, and a smoke suite that runs on every deploy.
03/How we approach it
The order matters more than the list.
Frame the problem
We work out what the software has to do and, more usefully, what it does not. You get a scope we both recognise and an explicit list of what sits outside it.
Design the architecture and the bill
Data model, service boundaries, and the AWS shape it will run on. Costing the architecture at this stage is the point of doing both halves — it stops an expensive decision becoming permanent.
Build in vertical slices
We ship a thin working path through the whole stack early, then widen it. You have something to react to in weeks instead of a demo at the end.
Harden before launch
Behaviour under load, error handling, an authentication review, backups we have actually restored from, and alerts that point at a cause rather than a symptom.
Release and hand over
Production deploy, a runbook written for someone who was not in the room, and a walkthrough with whoever owns it next — your team or ours.
04/Technology
What this pillar is built with.
- Languages
- TypeScript
- JavaScript
- Python
- SQL
- Frontend
- React
- Next.js
- Tailwind CSS
- Backend
- Node.js
- FastAPI
- Django
- REST
- GraphQL
- Runtime on AWS
- Lambda
- ECS
- Fargate
- API Gateway
- Testing
- Vitest
- Jest
- Playwright
- pytest
05/What you get
Things you can point at.
- A repository you own, with readable history and no vendor lock on the code
- A running application in production, plus a staging environment that matches it
- An architecture document covering the data model, the service boundaries and the trade-offs
- Automated tests, and a pipeline that runs them on every change
- A runbook: how to deploy, how to roll back, what each alert means, who to call
- A recorded handover session, with your team asking the questions
Related services and solutions
06/Questions
Software Engineering, asked about.
01Can you work from designs we already have?
Yes, and it usually speeds things up. Send whatever exists — Figma files, a written spec, or screenshots of the current system. We will tell you which parts are ready to build and which will raise questions once they meet real data.
02Will you take over an existing codebase?
Often. We start with a read-through and a written assessment of what we found: what is solid, what is risky, and what we would change first. You keep that assessment whether or not you continue with us.
03Who owns the code?
You do, from the first commit. Work happens in your repository under your organisation where possible, or in ours and transferred at handover. There is no proprietary framework you have to keep paying us to use.
04What happens after launch?
Whatever you want to happen. Some clients take the runbook and run it themselves; others keep us on for ongoing engineering and infrastructure work. Both are normal, and neither is a condition of the build.
Describe the problem.
A few lines is enough. You will get a reply from an engineer within one business day, and it will address what you actually asked.