Internal platforms
Admin consoles, approval flows and back-office tooling that replace shared spreadsheets and manual reconciliation. Built for the twenty people who use them eight hours a day.
We build the software your customers never see.
Admin consoles, data pipelines, internal APIs and the integrations that hold them together. The systems a company runs on once spreadsheets and manual handoffs stop scaling.
About the company
Engineering software that works inside real businesses.
What we are
We build software ourselves. No subcontractors, no handoffs between sales and delivery teams. The engineers who scope the work stay with the project through implementation and handover.
Who we work with
Operations, finance and logistics teams in companies of 50 to 500 people, usually at the point where an internal tool built years ago has become the constraint on the business.
How we start
With a two-week discovery: we read the existing code, sit with the people who use it daily, and write down what actually happens. That document is yours whether or not you continue with us.
What we leave behind
Documented, tested code in your repositories, running on your infrastructure, with a handover session recorded. No proprietary runtime, no dependency on us to keep the lights on.
Practice
Six things we are asked for most.
If the work you have in mind is not on this list, it is still worth an email — the boundaries are practical, not doctrinal.
Data pipelines
Moving records between systems on a schedule you can trust, with failures that surface loudly instead of silently dropping rows. Includes the reconciliation reports nobody wants to write.
Integration work
Connecting an ERP, a CRM and three vendor APIs that were never designed to speak to each other. Idempotency, retries and an audit trail of every call.
Legacy migration
Taking a system that still works but nobody can safely change, and moving it forward in stages while it stays in production. Strangler pattern, not a rewrite gamble.
Mobile clients
Field and warehouse applications for staff rather than consumers: offline-first, barcode input, tolerant of poor connectivity and cheap devices.
Platform and delivery
Containerised deployments, environments that match, and a pipeline that runs the tests before anything reaches production. Handed over with runbooks your team can read.
Process
Four stages, in this order, every time.
STAGE 01
Discovery
Two weeks. We read the code, interview the people using it, and produce a written scope with an estimate range and the risks we found.
STAGE 02
Build
Two-week increments against the agreed scope. Working software at the end of each one, deployed to an environment you can open.
STAGE 03
Handover
Repositories, infrastructure definitions, runbooks and a recorded walkthrough with your engineers. Access transfers to you, not to us.
STAGE 04
Support
An agreed support window with a named engineer, or a clean exit. Both are normal endings, and we say which one we recommend.
Stack
What we keep in production.
Chosen because we maintain them for years, not because they were new this quarter. We work in the client’s stack when there is a good reason to.
Runtime
- TypeScript / Node.js
- Python
- Go
- Kotlin
Data
- PostgreSQL
- ClickHouse
- Redis
- Kafka
Infrastructure
- AWS
- Docker
- Kubernetes
- Terraform
Interfaces
- React
- Vue
- Swift
- React Native
Terms of work
Four things we put in writing.
You own everything
Source code, infrastructure definitions and documentation are assigned to you on payment. Repositories live in your organisation from the first commit.
Estimates come with a range
Every scope states a low and a high figure and the assumptions behind both. When an assumption breaks, you hear about it in that week’s update, not at the end.
One named engineer
Contracts name the lead engineer on your account. If that person changes, we tell you before the change, not after it.
Thirty days’ notice, either way
Retained engagements end on thirty days’ written notice from either side, with handover included in the final period at no additional cost.
Contact
Tell us what is not working.
Write to us with a paragraph about the system and the problem. We reply within two working days, and the first call is a scoping conversation with an engineer — not a sales stage.