Custom software & product engineering
When off-the-shelf software forces your process to bend, the workaround becomes the job. We build the system that fits — and hand you the keys to it.
Custom software development is building an application specifically for one organisation's processes, rather than adapting that organisation to a product built for a market average. The output is a system you own outright — source code, data model and infrastructure — instead of a licence you rent.
It's the right choice when the process is your competitive advantage, when no product on the market covers the workflow end to end, or when you're paying for three tools plus the manual work of keeping them in sync. It's the wrong choice when a mature product already does the job, which is a conclusion we'll reach with you honestly before quoting a build.
In practice most builds are one of three things: replacing a spreadsheet that has quietly become critical infrastructure, unifying systems that don't talk to each other, or productising an internal tool customers have started asking for.
The question we work through in the first session — usually before anyone mentions a technology.
| Buy off-the-shelf | Configure a platform | Build custom | |
|---|---|---|---|
| Best when | A mature product already covers 90% of the workflow | The platform fits, but the last mile needs your rules | The process is the differentiator, or nothing fits |
| Upfront cost | Lowest | Low to moderate | Highest |
| Ongoing cost | Per-seat licence, rises with headcount | Licence plus maintenance of customisations | Hosting plus the changes you choose to make |
| Time to value | Days to weeks | Weeks to a couple of months | Two to six months for a first release |
| Fit to your process | You adapt to the product | Close, with configuration limits | Exact, by definition |
| If you outgrow it | Migration project, data export permitting | Customisations usually don't travel | You own it — extend or rehost freely |
We have no financial interest in this answer — we don't resell software licences. If buying wins, we'll say so and help you configure it properly.
Six shapes that cover most of the work that comes to us.
Internal business applications
Operations tools, admin consoles, approval workflows and the systems that run the parts of the business no product was designed for. Usually the highest-return build a company makes.
Customer-facing platforms
Portals, marketplaces, booking systems and self-service accounts — where the software is the product experience and downtime is revenue.
SaaS products
Multi-tenant applications with subscriptions, usage metering and role-based access. We've built and operated our own billing platform, so this isn't theoretical.
Legacy rebuilds
Replacing systems that still work but can't be changed safely. Done incrementally with the old system live, not as a big-bang cutover with a prayer attached.
Integration layers
The middleware that makes your existing systems agree with each other — ERP to storefront, CRM to billing, warehouse to carrier.
Data and reporting backends
The pipelines and APIs feeding dashboards, plus the boring correctness work — reconciliation, idempotency, audit trails — that makes the numbers trustworthy.
Defaults, not dogma. If your team maintains it after handover, your team's stack usually wins.
Backend
- TypeScript / Node.js
- Python
- PostgreSQL
- Redis
- Prisma
- REST & GraphQL
Frontend
- React
- Next.js
- TypeScript
- Tailwind CSS
- React Native
Infrastructure
- Docker
- Kubernetes
- Terraform
- AWS / Azure / GCP
- Cloudflare
- GitHub Actions
Quality
- Vitest / Jest
- Playwright
- ESLint & type checking
- Preview environments
We pick the boring option deliberately. Novelty is a maintenance cost you pay after we've gone.
Four stages with a concrete artefact at the end of each — so you can judge progress on something real, not a percentage.
- 01
Scope
A working session on the problem, the current process, and what success looks like in numbers. We map the workflow, flag the integrations that will hurt, and size the work.
DeliverableWritten scope, approach, and a cost range — free, and yours to keep.
- 02
Design
Data model, architecture and interface design. Clickable prototypes for anything user-facing, so disagreements happen over a screen instead of over finished code.
DeliverablePrototype, schema, and an architecture decision record.
- 03
Build
Two-week iterations. A working demo at the end of every one, on a staging environment you can use from week one. Tests, code review and CI are part of the work.
DeliverableWorking software in staging, every two weeks.
- 04
Launch & run
Production deployment, monitoring, backups and a support window — or a clean handover if you're taking it in-house.
DeliverableLive system, runbooks, credentials, source.
These aren't line items on our estimates. They're what building software properly means.
Automated tests
Unit and integration tests for business logic, end-to-end tests for critical paths. Not 100% coverage theatre — coverage where a regression would actually cost you money.
CI and preview environments
Every change builds, tests and deploys to a preview URL. You review features on a real environment before they merge, not on a screenshot.
Code review
Nothing reaches your main branch without a second engineer reading it. The technical lead reviews anything touching data, money or auth.
Documentation that survives us
Architecture decisions with their reasoning, runbooks for the operational tasks, and a README that works on a fresh machine. Written as we go, not reconstructed at the end.
Representative shapes of work, not client names — we don't publish those without written permission.
Operations console replacing spreadsheets
A distributor running stock, pricing and dispatch across shared sheets. One system with roles, an audit trail and a mobile view for the warehouse.
Customer self-service portal
Cutting inbound support by letting customers do the top five things they call about — check status, download invoices, raise a change, update details, track a delivery.
Billing and reconciliation
Payment collection with automatic reconciliation against orders, compliant invoicing, and a ledger that survives an audit.
Internal tool turned product
Taking a tool built for one company and making it multi-tenant — auth, plans, metering and self-serve signup — so it can be sold.
No day-rate card here, because the honest answer depends on scope. What we can tell you is how the number is built.
- Fixed-scope projects are quoted as a fixed price after the free scoping session — you see the number before you commit to anything paid.
- Dedicated teams are billed monthly per person with 30 days' notice, which suits roadmaps that will change faster than a contract can.
- We bill milestones against working software in staging, not against hours logged or documents produced.
- Change requests are quoted separately and explicitly. Scope creep absorbed silently is how projects quietly become late.
A useful first release is typically two to six months, depending on how many systems it has to integrate with. We deliberately scope a first release that solves the single most expensive problem rather than the whole wish list — it gets value in front of users faster and the rest of the roadmap gets better after real usage.
Start a project
A paragraph about the problem is enough to start. We'll come back with an approach, a rough cost, and an honest view of whether building is even the right answer.
- Reply within one business day
- Free scoping session, no obligation
- You keep the scope document either way