Software Development

Process mapping, data modelling, and an application delivered in increments you can put into real use, on a stack chosen for how easy it is to hire for rather than how modern it looks. Roles enforced on the server, integrations to the systems you already run, and documentation written for a developer who has never met us. Discovery is fixed price and the specification it produces is yours either way.

Most businesses do not need software written. They need a spreadsheet to stop being load bearing. There is usually one file that four people edit, that nobody dares restructure, and that quietly runs a part of the company nobody has documented.

That is the honest starting point for custom software: a process that already works but does not scale, where the cost of the current method has become visible. Building before that point produces expensive tools that go unused because they solved a problem nobody had yet.

We build on deliberately boring technology. Widely documented, widely hired for, still maintained in five years. The interesting choice is fun for the first month and a liability every month after, particularly if your own team ever has to take it over.

Fewer spreadsheets
One source of truth
Handover documentation

(Included)

06 items

Process mapping

How the work is done now, including the workarounds. Software that automates a process nobody described accurately automates the wrong thing.

Data model

The entities and relationships underneath, designed before any screen. Most software that becomes unmaintainable got this part wrong early.

The application

Built in increments you can use, on a stack chosen for how easy it is to hire for rather than for how modern it looks.

Integrations

Connections to the accounting, CRM or inventory systems you already run, with failure and retry handled rather than assumed away.

Roles and permissions

Who can see and do what, enforced on the server. Hiding a button is a user interface decision, not a security one.

Documentation and handover

Written so a developer who has never met us can run, deploy and extend it. If your team cannot take it over, it is not finished.

(How it runs)

01Watch the work happen
Time spent with the people doing the job. The gap between how a process is described and how it runs is where every requirement error starts.
02Model the data
Entities, relationships and constraints first. Interfaces are cheap to change later. A wrong data model is not.
03Ship the smallest useful version
One workflow, in real use, early. Feedback from actual use beats feedback from a demo by a wide margin.
04Extend, document, hand over
Remaining workflows added in increments, with documentation kept current rather than written in a rush at the end.

(Is this the right thing to buy)

Who it suits: Businesses where a process already works but does not scale, and the cost of the current method has become visible. The clearest signal is a spreadsheet several people edit that nobody dares restructure. That file is a specification for software somebody should have written a year ago.
When it is the wrong call: If an off-the-shelf product covers eighty percent of what you need, buy it. It is cheaper, available immediately and maintained by someone else. Custom software earns its cost when the process encodes something that makes you competitive, or when licence fees for a tool you half use have overtaken the cost of building.
What it costs: Fixed-price discovery first, producing a specification and an estimate you own regardless of whether you continue with us. Build is then quoted in phases against that specification, so you can stop between phases with something working rather than being committed to the whole thing at the outset. Integrations with existing systems are the single largest cost driver, usually more than feature count.

(Questions we get asked)

Should we build or buy?

Buy, unless the process is genuinely specific to how you compete. Off the shelf software is cheaper, maintained by someone else and available on Monday. Custom work is worth it when the tool encodes something that makes you different, or when the licence cost of a product you half use has passed the cost of building.

What technology will you use?

Usually TypeScript with a well-supported framework and PostgreSQL, because those are widely documented and widely hired for. If your team already runs something else and runs it well, we will work in that rather than introduce a second stack for you to maintain.

What happens if we want to change developers later?

You can, and the build is made so that is not a crisis. You own the code and the infrastructure accounts, the stack is mainstream, and the documentation is written for someone who has never spoken to us. Lock-in is a business model, not an engineering outcome.

What is included in Software Development