Projects · Built & running in production

Systems that had to work
on Monday morning.

Every project below is software that runs a real operation — not a prototype and not a portfolio piece. Client names and operational details are withheld under confidentiality. The engineering decisions are described exactly as they were made.

Integration & data movement

Getting systems that were never meant to talk to each other to agree, on a schedule, without a person in the middle.

Integration · Inbound logistics

Knowing where the freight actually is

Inbound shipments were tracked by opening carrier websites one tab at a time. We replaced the tabs with live carrier integrations and a workflow that routes exceptions to the person who can fix them.

Automation · Warehouse systems

Automating a system that has no API

The warehouse platform offered no write interface, so every transaction went in by hand. We automated the screens themselves — carefully enough to trust with live inventory.

Planning · Outbound fulfilment

Turning a flat order backlog into a plan the floor can pick

A daily backlog feed said what had been ordered — not what could be built, released or picked. We built the pipeline that turns it into a wave plan, a queued pick order, and a screen that says where each one got to.

Reconciliation · B2B trading partners

Variances that only close when they're actually gone

Two systems held different quantities for the same parts, and the disagreement arrived as a spreadsheet attached to a recurring email. We turned it into a register that remembers — and that nobody is allowed to close by hand.

Documents · Returns processing

Return paperwork the receiving system accepts first time

Returns had to be announced to the warehouse system by hand-filling a hundred-column vendor template. We build the document from the check-in itself, check every line against the customer's item master, and track each upload through to accepted or failed.

Operations platforms

Whole systems that replaced spreadsheets, inboxes and the knowledge that lived in one person's head.

Why these read the way they do

Case studies usually lead with a number. These lead with the problem, because the numbers belong to the clients who paid for the work.

What we can't tell you

Client names, site locations, system names, volumes and dollar figures are all covered by confidentiality obligations we intend to keep. If a competitor's case study names a client, either they got written permission or they shouldn't have.

We'd rather show you the reasoning than borrow credibility from a logo. On a call we can go considerably deeper on approach, architecture and what we'd do differently — without crossing that line.

The same rule governs the numbers. Every figure on these pages is a property of the software itself — route counts, retry limits, poll intervals — because those are ours to publish. What the software did to a client's cost or headcount is theirs, and it stays with them.

Production, not proof-of-concept

Everything here ran daily, under load, with people depending on it during their shift.

The failure modes are the story

Anyone can describe the happy path. What matters is what the system does at 3am when a dependency is down.

No rip-and-replace

Almost none of this involved replacing a system. It involved making the systems already in place work together.

Recognize your operation in any of these?

A free assessment gives you a clear picture and a prioritized plan — no commitment.

Book a free assessment