Custom software

When custom is the right call

Vendors rarely admit this, but off-the-shelf software is often the sensible choice. Custom earns its keep at a specific point: when a packaged product forces your business to work in a way that costs money, slows people down, or blocks something your competitors can already do. Usually that means a workflow no SaaS tool models well, an integration nobody else needs, or logic that is genuinely your edge. We help you draw that line before you spend anything on a build.

• A core workflow no packaged tool fits without heavy workarounds
• Spreadsheets and manual steps quietly holding a critical process together
• Per-seat licensing that scales painfully as you grow
• A capability worth owning outright because it is your advantage

What we build

Customer portals, internal tools that retire a tangle of spreadsheets, platforms that tie several systems together - the software your team relies on daily and your customers judge you by. Whatever the shape, the standard is the same: fast, secure, tested, and maintainable long after we have stepped away.

• Customer-facing web applications and self-service portals
• Internal tools and admin systems that replace manual processes
• Workflow software shaped to how your business runs
• Integrations with the systems and third parties you already depend on

How the work runs

You work with senior engineers from the first conversation, and the people you meet at the start lead the work through to release. We ship in small, reviewable increments - no disappearing for three months and returning with a launch. You see working software weekly, use it, and change our priorities while changing them is still cheap. Every change is reviewed by a second engineer, covered by automated tests, and released through a pipeline that makes rolling back quick.

A small, senior team - on purpose

A build here is staffed with a handful of senior engineers rather than a pyramid of roles, and that is a considered position, not a budget one. We once rebuilt a customer portal that arrived staffed the traditional way - external project manager, product owner, design studio, QA house - where a one-screen change took a fortnight, nine days of it spent waiting in queues between specialists. Four seniors with serious agentic tooling took over the whole loop, research through release, and the fortnight became a day. Every hand-off is a queue; we remove them rather than manage them.

The four phases, roughly

Discovery, design, build, handover - though the edges blur on purpose. Discovery never fully stops, and usable software ships well before the end. We would rather retire risk continuously than bet everything on a launch date.

• Discovery - map the workflow, the constraints and what success means, then agree scope in writing
• Design - build the critical flows plainly, test them with real users, then style what holds
• Build - ship weekly, demo weekly, adjust as we learn
• Handover - transfer the code, the infrastructure and the knowledge

Quality is part of delivery, not a phase at the end

Testing, observability and security go in from the first increment, so problems surface while they are small and releases stay uneventful. Before anything reaches your customers it has run the automated suite, passed review, and been exercised against realistic load.

• Unit, integration and end-to-end tests in CI on every change
• Logging, monitoring and alerting from the first release
• Access control and security reviewed as part of delivery
• Performance checked against realistic load before launch

Integrations: the half nobody scopes

Custom software rarely lives alone - it reads from the CRM, posts to the accounts package, listens to the till, calls the courier’s API. In our experience the integrations are where estimates go to die, because they depend on systems nobody fully controls. So we scope them as first-class work: each connection mapped early, the flaky third party wrapped in retries and monitoring, and a plan for what happens when the other side changes without telling anyone. It is unglamorous, and it is the difference between software that works in the demo and software that works on a Tuesday.

What it costs, and how the spend is staged

Fixed-scope builds start from £8,000, with scope and milestones agreed in writing before work begins; ongoing product work runs as a dedicated team from £4,500 a month per engineer. More important than the headline number is the shape of the spend: we agree the smallest useful release first and grow from there, so the cheque you write is always for the next demonstrated increment, never for a distant promise. If priorities change mid-build - they usually do - the weekly demo is where we re-cut the plan together.

Rescues and inheritances

Not every engagement starts from an empty repository. We regularly take over codebases mid-flight - a stalled build, a departed supplier, an internal tool that outgrew its author. The approach is the same as for our legacy work: read it before judging it, get tests around the parts that matter, and improve incrementally rather than pitching the rewrite that flatters us and costs you. A surprising amount of “failing” software turns out to be two or three fixable problems wearing a bad reputation.

What is yours at the end

Everything. The source code, the intellectual property, the infrastructure - version-controlled, documented and handed over with runbooks and real knowledge transfer. We measure success partly by how little you need us afterwards, so there is no proprietary tooling and no dependency engineered in. Stay for ongoing work if it suits you; leave cleanly if it does not.