When your existing software doesn't handle the workflow.

Your ERP, your CRM and your spreadsheets each do their job. The manual steps holding them together are where the hours go. We build the missing layer — around the systems you already run, not instead of them.

Fixed scope · No ERP replacement

Work doesn't arrive in functions.

Software is bought to handle a function: an ERP for transactions, a CRM for customers, a spreadsheet for everything neither of them covers. Each does its job.

But work arrives as a process that crosses all three, and the crossings are manual. Someone copies. Someone re-keys. Someone checks that the copy matched.

These steps are invisible in every system because no system owns them, and invisible in every budget because they are somebody’s afternoon rather than a line item. They are also, almost always, the cheapest thing in the business to fix.

Why it never gets fixed

Too small, too specific, nobody's project.

Too small to justify an ERP customisation. Too specific for an off-the-shelf product. Too unglamorous to be anyone’s initiative. So it stays manual and the cost stays uncounted.

This is precisely the category where a small, focused system pays for itself in months rather than years — which is the only category we work in.

What we build

Five kinds of problem.

Each one described as a problem, an approach and an outcome — because a list of technologies would tell you nothing about whether we can help.

Workflow automation

Problem
A repetitive manual process runs every day and depends on someone remembering to do it.
Approach
Map what actually happens, count the volume, then automate only the mechanical steps and route the judgement calls to a person.
Outcome
The routine path runs on its own. Exceptions are queued with enough context to be resolved quickly.

Document workflows

Problem
Supplier invoices, purchase orders, packing lists and price lists arrive as PDFs and email, and are read by a person and typed into a system.
Approach
Extract the fields that matter, validate them against what you already hold, and surface only what does not reconcile.
Outcome
Documents become structured records. A reviewer sees the exceptions instead of every line.

Internal tools

Problem
A specific operational bottleneck has no software around it, because it is too small for an ERP customisation and too specific for an off-the-shelf product.
Approach
Build a small application that does one job for the people who do that job, rather than a general platform.
Outcome
The step that lived in a spreadsheet has a system, with a record of who did what.

Data workflows

Problem
The number in the ERP, the number in the spreadsheet and the number in the meeting are three different numbers, and someone reconciles them monthly.
Approach
Move, transform and reconcile the data on a schedule, with the reconciliation logic written down instead of remembered.
Outcome
One number, produced the same way every time, with the differences explained rather than argued about.

Integrations

Problem
Work crosses four systems and every crossing is manual, because no single system owns the process.
Approach
Connect them by whatever route exists — an API where there is one, a database view, a scheduled export, an inbox.
Outcome
The handoffs happen without a person copying between windows.

RFQ and quotation handling is the one we have worked on most. See how we approach RFQ automation →

Fit

Who this is for.

Likely a fit

  • You have real systems in place and a team still doing data entry.
  • A process crosses several tools and every crossing is manual.
  • Somebody can tell us how often it happens and roughly how long it takes.
  • The process is stable enough that it will look the same in six months.

Probably not yet

  • You do not yet have a system of record — that is a different first problem.
  • The process changes every month and has not settled.
  • Nobody can say how often it happens, even approximately.
  • What you actually need is an ERP implementation or a migration.
How we start

A process walkthrough comes first.

One week, fixed fee. We establish what the problem costs before anyone discusses building anything.

  1. 01WalkthroughWe sit with the two or three people who actually do the work and map what happens today, including the parts that are not in any documentation.
  2. 02Count itHow often, how long it takes, and how often it goes wrong. If nobody can tell us, that is the first finding.
  3. 03Size itWhat the current process costs at that frequency, and what a system would realistically save.
  4. 04DecideIf the saving does not clearly exceed the build cost, we say so. You have a written process map either way.
  5. 05BuildOne workflow at a time, fixed scope, fixed price, around the systems you already run.
  6. 06Hand overCode, documentation and credentials. No hosting lock-in and no dependency on us to keep it running.

What we don't do

Websites, marketing sites and e-commerce storefronts. Mobile apps. ERP implementations and migrations. Staff augmentation by the month. Anything scoped as “and then we’ll see.”

If we cannot estimate what the current process costs, we are not the right people for it — and we would rather say that at the start than discover it in month two.

What we don't claim

We do not build systems that make commercial decisions on their own. Automation handles the mechanical part; pricing, approval and anything a customer sees stays with a person.

Where a system is uncertain, it should say so and ask. It should not guess quietly.

Questions

Common questions.

Do you replace our ERP?

No, and we will not propose it. We read from and write to the systems you already run. Replacing a working system of record is expensive, risky and almost never the cheapest way to fix a workflow problem.

How do you price this?

Fixed scope, fixed price, quoted after a written scope. We do not quote against a conversation, and we do not bill by the month. If we have misjudged the effort, that is our cost, not yours.

How small is too small?

If the process takes less than a couple of hours a week and is not error-prone, automating it rarely pays for itself. We will tell you that rather than build it.

What if we do not know what the current process costs?

That is what the walkthrough establishes. If it turns out the cost cannot be estimated even after mapping it, we are not the right people for that project — we do not take on work where the value is a matter of opinion.

Do you use AI in these systems?

Where it is the right tool — reading unstructured documents, matching messy descriptions — and not where it is not. Business rules, validation and arithmetic are better served by code that behaves the same way every time. Anything a model produces is checked against rules you define, and judgement calls go to a person.

Walk us through the process.

No data export needed to start. Describe how the work runs today, roughly how often, and which systems are involved.

20-minute conversation · Fixed scope, fixed price