When nothing off the shelf fits, we build the software that does the job

Last resort, not first

Most recurring work in a 50 to 500 person business can be removed with software that already exists, set up properly inside the accounting package, CRM or helpdesk your team uses. That is what Workflow Automation is for, and it is where we start. This programme is for the job that survives that test: nothing you can buy does it, the volume is real, and the work is specific enough to your business that a bespoke build might pay for itself.

A custom build is the most expensive thing we sell and the easiest to regret. So it is gated on arithmetic, not on enthusiasm.

We run this kind of software ourselves

Two of our own ventures, postoracle.com and wallmag.io, run day to day on software of this kind. The founders’ jobs became a task board and a review queue. We mention this not as proof it will work for you but because it means we know where these builds break, what they cost to keep running, and how much review a person still ends up carrying. That experience is why we say no as often as we do.

The maths comes first, and it is the gate

Discovery takes one to two weeks. We watch the job being done, count the systems involved, and confirm nothing off the shelf already does most of it. Then you get one document: what it would cost to build, what it would cost to run each month, what it replaces in hours and money, and the payback period that falls out of those figures.

You see every input. If you think our minutes-per-item is wrong, change it and the payback moves. If the payback period is longer than you would accept, the programme ends there, and the document is yours. We would rather lose the build than have you carry software that does not earn its keep.

Built in your accounts

If the maths works, we build in your accounts, under your logins, connected to your systems. Nothing routes through us. Your people own it from day one, which means the day we stop being involved, nothing stops working. Testing runs on your real historical items, and the person who does the job today checks the results against their own before anything goes live.

When it stops and asks a person

Every build comes with written rules for the moments it must stop and pass the item to a named person: an amount above a limit you set, a document it cannot read clearly, a customer reply that is not a plain yes. Those rules are agreed before go-live and they are yours to tighten or loosen. The person named in them still does the judging. The software does the rest.

The ways custom builds go wrong

They go wrong when the payback was never calculated, so nobody notices it never arrives. They go wrong when the build lives in the builder’s accounts and the business is one contract dispute away from losing it. They go wrong when the rules for stopping are in someone’s head rather than on paper, so the first surprising case becomes an incident.

Each of those has a matching line above: the maths first, your accounts, written rules.

How it ends

Handover takes one to two weeks and includes how to change the rules and what to check each month. For the first two months after go-live we review what stopped and asked a person, and adjust alongside your team. After that, nothing usually follows. Custom software is the end of the sequence, not the start of one. What your people keep doing is the judging: the items the rules send to them, and the monthly check that the rules are still right.