Custom software development
Web applications, internal tools, customer portals, APIs and mobile apps. Built by small senior teams in short increments, on infrastructure you own — so leaving us would be inconvenient rather than catastrophic.
What usually goes wrong with outsourced builds
The common failure is not bad code, it is a slow feedback loop. Requirements are agreed, a team disappears for three months, and what returns is a faithful implementation of a specification that stopped being right in week two.
The second failure is dependency. Code in the supplier's repository, infrastructure in the supplier's cloud account, domains registered to the supplier, and no documentation — so the cost of changing supplier quietly becomes higher than the cost of tolerating a bad one.
Both are avoidable with arrangements agreed at the start: working software every two weeks, and every asset in your name from the first commit.
What we build
Web applications
Customer portals, internal tools, dashboards and marketplaces. Server-rendered where SEO and load time matter, rich client applications where interaction does.
APIs and integrations
Services connecting systems that were never designed to talk — including the awkward ones with SOAP endpoints, flat-file exports or no documentation.
Mobile applications
Cross-platform by default because it is usually the right economic answer, native when the product genuinely needs platform capabilities. We will tell you which you are.
MVPs for startups
A first version narrow enough to build quickly and real enough to learn from. Scoped around the one question the product needs to answer.
Legacy modernisation
Incremental replacement of systems still doing real work — strangling the old system function by function rather than a rewrite-and-cutover that risks the business.
AI where it earns its place
Because it is what we do, but only where it beats a simpler solution. A form validation rule does not need a language model, and we will say so.
Typical stack
Chosen per project, not by habit. If your team already runs something that works, we use it.
- Frontend
- TypeScript
- React
- Next.js
- Astro
- Tailwind CSS
- Backend
- Node.js
- Python
- PostgreSQL
- Redis
- REST and GraphQL
- Mobile
- React Native
- Flutter
- native Swift or Kotlin where required
- Infrastructure
- Docker
- AWS
- GCP
- Azure
- Terraform
- GitHub Actions
How a build runs
Two-week increments with working software at the end of each — not a status report. Priorities can change between increments, which is the entire point of working this way.
- 01
Scoping
A paid discovery producing a technical scope, architecture outline and fixed price for the first phase. You keep the document whether or not you continue.
- 02
Increments
Two-week cycles, each ending in something you can use. Deployed to a real environment from the first increment, not the last.
- 03
Launch
Pipelines, monitoring, backups and documentation completed before go-live, because doing them afterwards means never.
- 04
Afterwards
We keep running it on a retainer, or hand over to your team with documentation and a transition period. Both are normal.
Common questions
Who owns the code?
You do, from the first commit — in your repository, under your account, with infrastructure and domains in your name. There is no arrangement where you pay for software and we hold the keys.
How do you price projects?
Fixed price per phase after a paid scoping engagement. Estimating a whole project before understanding it produces either a padded number or an argument later, so we scope first and price a phase at a time.
What if our requirements change mid-project?
Expected. Priorities can be reordered between two-week increments at no penalty. Substantial scope additions get re-scoped and re-priced rather than absorbed silently and delivered late.
Can you work with our existing codebase?
Yes. We usually start with a short audit so we can be honest about its condition and what changing it will realistically cost, rather than discovering that in month two.
What happens after launch?
Whatever suits you: a support retainer with agreed response times, a handover to your own team with documentation and a transition period, or nothing at all. The system is built to be operable by someone other than us either way.
How big are your teams?
Small and senior. Two or three experienced engineers who talk to you directly, rather than a large team filtered through an account manager. It costs more per head and less per outcome.
Start with a scoping call.
Thirty minutes, no obligation. If we are not the right fit we will tell you on the call rather than after a proposal.
Related services
Web application development
Portals, internal tools, dashboards and SaaS products. Built to be fast on a mediocre connection, operable by …
Mobile app development
Cross-platform by default, because it is usually the right economic answer. Native when the product genuinely …
API development & integrations
Connecting systems that were never designed to talk to each other — including the awkward ones with a SOAP end…