01Frame
Outcome, users, constraints and the definition of a useful first release.
You getA scoped v1 with a fixed price and a date.Build & Run
Build it when the alternative is bending the business to fit the software.
Most requirements are better served by a product you can buy. Custom development earns its cost in the minority of cases where the process is yours, and that is the only case in which we will recommend it.
First release8–14 weeks for a working v1
RhythmReviewable software every two weeks, from week two
StackChosen for what you can hire and operate
TeamNamed engineers, not a rotating pool
OwnershipYour repositories, your cloud, from day one
After launchSupport retainer or handover, your choice
The question before the project
Buy it if you can. Build it when you cannot.
A custom system is a permanent commitment. Someone maintains it, patches it, and eventually modernises it. That is worth taking on when the process it encodes is a real part of how you compete, and a poor trade when you are rebuilding something a product already does well.
We start most conversations by asking what you have already evaluated and why it did not fit. If the honest answer is that nobody has looked properly, that is the cheaper first step and we will say so.
Where building is right, the failure modes are well known: a specification written far ahead of any working software, a first release too large to be useful, and a launch that is the first time real users see it.
We work the other way round. Something narrow and genuinely usable goes live early, real usage informs the next slice, and the scope that turns out not to matter never gets built at all.
How a build runs
01FrameThe outcome, the constraints, and who it is for.
02SliceThe smallest release that is useful.
03BuildTwo-week cycles, reviewable software each time.
04ReleaseLive with real users, early and deliberately.
05LearnUsage decides what is built next, not the plan.
06Hand overDocumentation, tooling and knowledge transferred.
What we build
Six kinds of system that justify being custom.
The common thread is that each encodes something specific to the organisation, a process, a rule set, or a data relationship no product anticipated.
01
Core operational platforms
The system the business runs on, orders, cases, claims, jobs, whatever your operation processes all day.
Usually replaces several spreadsheets
02
Integration and middleware
The layer that makes existing systems work as one, replacing overnight files and manual re-keying.
APIs · events · synchronisation
03
Internal tools and back office
Interfaces for the teams doing the work, built around their actual process rather than a generic CRUD screen.
Admin · workflow · reporting
04
Customer and partner portals
Self-service that removes work from your team rather than adding another channel to monitor.
Accounts · documents · transactions
05
IoT and connected systems
Device data collected, interpreted and acted on; telemetry, monitoring and field operations.
Ingestion · alerting · dashboards
06
Regulated and audited systems
Where the record of who did what and when is as important as the transaction itself.
Audit trail · approvals · retentionMVP development
MVP means the smallest useful thing, not the cheapest broken thing.
The term has been damaged by projects that shipped something unusable and called it a minimum viable product. A genuine MVP is narrow in scope and complete in quality: it does one job properly, and a real user can do that job without a workaround.
The point is to learn. Every requirement in a specification is a hypothesis about what people need, and a surprising share of them are wrong. Shipping early converts those guesses into evidence before you have paid to build all of them.
- Scope to one job, the single workflow that delivers value, done end to end.
- Production quality from the start, authentication, backups and monitoring are not phase two.
- Real users in weeks, usage from a small group beats another round of stakeholder opinion.
- Measured, not assumed; instrumentation from the first release, so the next decision has evidence.
- Built to extend, an MVP that has to be thrown away to grow was not an MVP, it was a prototype.
- An honest stop condition, if the evidence says the idea does not work, stopping is a successful outcome.
Technology
The stack, chosen for you, not for us.
We deliver across all of the below. That is what makes the recommendation worth something, there is no platform we need you to pick.
Frontend
Interfaces people use all day, built to be accessible and maintainable.
Backend
Services and APIs on the platform your team can operate at 3am.
Data
The model that will outlive the application above it.
Cloud & DevOps
Reproducible infrastructure and pipelines you can trust.
Mobile
Native and cross-platform, chosen on how much device access you need.
AI & ML
Added where it changes the outcome, not as a garnish.
How we deliver
Working software from week two, not a document.
02Foundations
Environments, pipeline, authentication and the data model, all as code.
You getA deployable skeleton in your cloud, from week two.03Build
Two-week cycles, each ending in software you can use instead of a status report.
You getReviewable working software every fortnight.04Release
Live with a real user group, instrumented, with support arrangements in place.
You getA production system and the runbook to operate it.05Evolve
Iterate on evidence from usage, or hand over cleanly to your own team.
You getEither a support retainer or a documented handover.Questions worth asking
Before you commission a build.
The three below are the ones this page does not already answer. Anything more specific, put it to us directly.
Can you give us a fixed price for the whole thing?
For the first release, usually yes, and we prefer to. For a multi-year platform, a single fixed price is a fiction that both sides end up managing, not delivering; the scope will change, and a contract that punishes change turns every improvement into a negotiation. What we do is fix the price of a discovery phase, then fix the price of a defined v1 once we know what we are building. After that, most clients move to a dedicated team at a known monthly cost, which gives them a predictable budget and the freedom to redirect scope as they learn.
What happens if we want to take it in-house?
You can, at any point, and the arrangement is built so that is not a disruptive event. The code is in your repositories from the first commit, the infrastructure is in your cloud accounts, and the pipelines are defined as code alongside it. We document as we go rather than as a closing exercise, and we expect your engineers in pull requests throughout. A handover is then a few working sessions rather than an archaeology project. Several clients run systems we built entirely themselves now and come back only for new work.
How do you keep a long project from drifting?
By making the software itself the progress report. Every two weeks there is something running that you can use, which is a far harder thing to be vague about than a percentage complete. Alongside that, scope changes are priced when they are requested, not absorbed silently and surfaced later. The pattern that causes drift is a long gap between commitment and working software, and the fix is structural instead of a matter of better reporting.
Related capabilities