The process that
lives in a spreadsheet
With a permission model, an audit trail, and validation, so that two people cannot quietly disagree about the same number.
Typical result: one version of the truth
Build
Software Development
Internal tools, integrations and back-office systems. The unglamorous software a business actually runs on, usually replacing a spreadsheet, an email thread and one person who knows how it really works.
Typical build
6 to 14 weeks
Replaces
Spreadsheets and email
Integrations
Whatever you run
Hosting
Yours
Handover
Your IT can maintain it
How it works
Four systems, and a person in the middle.
Almost every internal software project starts the same way: several systems that do not talk, and somebody whose job has quietly become moving data between them by hand.
What we build
Three things this usually turns out to be.
The process that
The handoff
somebody does by hand
Your CRM talking to your accounting system without a human copying rows between them every Friday afternoon.
Typical result: a job nobody has to remember
The number that
changes depending who asks
Defined views on a read replica, with the definitions written down, so the monthly argument stops happening.
Typical result: the same answer twice
The stack
What we reach for, and why.
Deliberately boring technology, because your own team maintains this after we leave. Novel choices are a cost you pay later.
Back end
Node.jsPythonLaravel.NETJava
Front end
ReactVueServer-rendered
Data
PostgreSQLSQL ServerMySQLMigrations
Integration
RESTWebhooksQueuesScheduled jobs
Delivery
DockerSelf-hostedCI/CDDocumentation
How to buy it
The work is the same. The shape of the deal is not.
Internal software is bought under any of the three engagements. Which one depends on how well understood the process already is.
Forward Deployed EngineerOne senior engineer owns it end to end. Best when the solution is not obvious yet.Read more →
Staff AugmentationYou own the plan, we supply the hands. Best when your spec is ready.Read more →
Dedicated TeamsA standing squad with QA and DevOps. Best for a programme of work.Read more →
Honestly
The software is never the hard part.
Come to us when
Good fit
- A process runs on a spreadsheet nobody is allowed to break.
- Two systems that should talk are joined by a person.
- Reporting takes a day a month and still produces arguments.
- The person who understands the process is about to leave.
Go elsewhere when
Poor fit
- You want off-the-shelf. If a product already does this, buy it.
- The process itself is broken and nobody will change it.
- You need a consumer product rather than internal tooling.
Questions
Before you book the call.
That is the point, and it drives the technology choice. Ordinary stack, documented, deployed the way you already deploy things. If your team is a Microsoft shop we build .NET, not Go, however much we might enjoy Go.
It does. Every internal process has exceptions that exist for real reasons and appear in no document, and finding them is most of the first fortnight. That is exactly the work the standard delivery chain skips, which is why those projects break on day one.
Yes, and we will be honest about which ones are painful. A modern API is a day. A system with no API and a nightly CSV export is a different conversation, and you should have it before the budget is set.
No. Plenty of this work runs perfectly well on a server you already own. We will not bundle a cloud migration into a project that did not ask for one.
Next step
Describe the spreadsheet. We will tell you what it really is.
Thirty minutes on the process rather than the software. Half the time the answer is smaller than people expect.