The system your team works in all day, built or replaced in slices
ERP and back-office systems, apps for staff out in the field, internal tools that retire the shared inbox, integration between systems that each hold part of the truth, and automation of the manual steps that quietly eat a week. Your current system stays live until the new one has earned the switch.
- Companies delivered for
- 20+
- Median to first production-grade artefact
- 6 weeks
- Software a real user can open
- By week 3
- Team on a build
- Pod of three
- Published case study for this pillar
- None yet
Signs the problem is a missing system, not a missing report
Operations leaders rarely arrive asking for software, they arrive describing a week that keeps getting eaten.
The same order is typed into two systems by two people
Nobody planned this. The two systems were bought four years apart and joining them was always next quarter's problem. The re-keying is now a job description.
The real process lives in a shared sheet that nobody owns
The system of record says one thing, the sheet says another, and the team works from the sheet because it is right. A sheet doing the work of an application is a symptom, not a case for a better sheet.
Field staff write on paper and type it up at the end of the day
The operation is always a shift behind itself, and every dispute about what happened on site is settled by memory.
Month end is late because three systems disagree about the same number
Somebody spends the first week of every month reconciling by hand, and the answer they produce is not reproducible by anyone else.
A person exists mainly to move data between two screens
Ask what they would do with that time back. If the answer is work you actually need done, the automation pays for itself before the argument about it finishes.
Your current vendor has stopped changing the system
Support continues, the roadmap does not. Every new requirement becomes a workaround, and the workarounds are now the process.
What we have actually delivered
We have not published a named application case yet, so these are firm-wide delivery figures and we will say on the call which of them came from work like yours.
Document work, done by the system
The routine cases stop reaching a desk and only the exceptions get routed to a person.
From the symptom you describe to the build it turns into
Nobody arrives asking for integration or a field app, they arrive describing one of the symptoms on the left.
- The same order typed into two systemsIntegration
- The real process lives in a shared sheetInternal tools
- Field staff write on paper, type it up laterField and mobile
- Month end is late, three systems disagreeIntegration
- A person exists to move data between screensAutomation
- The vendor has stopped changing the systemModernisation
Six kinds of build, one delivery method
Different problems, the same shape of engagement.
ERP-type applications built to fit the operation
Order to cash, procurement, stock, service jobs, claims handling. We build where configuring a packaged product would cost more than writing the thing, and we replace module by module where a product already sits in the middle of the operation.
Read more →Internal tools02Line-of-business tools that retire the shared inbox
Approvals, exceptions, queues, case files, back-office consoles. Work that currently happens across email, a tracker and somebody's memory gets a screen, a defined set of states and an audit trail of who did what.
Read more →Field and mobile03Apps for people who are not at a desk
Route lists, job cards, inspections, proof of delivery, stock counts. Built offline first, because the signal drops in the basement of the store and the work still has to be recorded correctly.
Read more →Modernisation04Replacing an ageing system while it keeps running
No freeze, no weekend cutover, no two-year rewrite. One process at a time moves across, runs alongside the old path, gets compared, then takes over.
Read more →Integration05Joining systems that each hold part of the truth
One order lives in three places with three different statuses. We decide which system owns which field, build the flow between them, and make disagreement visible instead of silent.
Read more →Automation06Removing the manual steps that consume a week
Re-keying, reconciling, chasing, exporting, formatting, uploading. We automate the steps that are rule-shaped and leave judgement with the people who should be exercising it.
Read more →What lets a small pod ship a working system in weeks
Application work used to be mostly typing, and much of that typing is now a first pass a person reviews.
- Already built
Patterns that have shipped before
Auth, roles, audit logging, integration adapters, background jobs and the admin surfaces every business application needs. Proven in production, adapted rather than rebuilt.
- AI first pass
Scaffolding and integration glue
Claude drafts the boring, high-volume layers: data access, forms, mappings between systems, and the tests around them. Reviewed by the engineer who owns the module, never merged unread.
- AI first pass
Reading the system you are replacing
Legacy code and undocumented behaviour get read and summarised into the rules the new system has to honour. Modernising in slices needs that inventory, and building it by hand is what usually kills the appetite for the project.
- Human call
How the process should actually work
The design of the workflow, what gets automated and what deliberately stays manual, and where a person must stay in the loop. That is the consulting, and it is not something to hand to a model.
The engagement, and the week that decides it
A fixed-fee audit week, a pod of three building, then quarterly reviews and on-call governance once it is live.
What the first six weeks look like on a build
Three phases, always, and the interesting part is what has to be true by week three.
- Week 1
The audit, fixed fee
Two calls, and one real transaction followed end to end from the screen where it starts to the ledger where it lands. You get a one-pager, yours whether or not we go further.
- Week 2
The first slice is chosen
A pod of three starts on the slice that carries real transactions and has the fewest dependencies, not the screen that demos best. The demo-friendly screen teaches you nothing about whether the system will hold.
- Week 3
Something works
There is software a real user can open and do real work in, not a click-through prototype. This is the week the wrong assumptions surface, which is exactly why it is not week eight.
- Weeks 4 to 6
It goes into use
The slice runs alongside the current way of working, then replaces it. Across our engagements the median time to a first production-grade artefact is six weeks.
- Week 7 onwards
Operate
Quarterly reviews and on-call governance. Someone answers when the system misbehaves at seven in the morning, and the fix goes back into the build rather than into a workaround.
What you commit to, and where you can stop
The numbers that decide whether this is worth starting are all in week one.
Which manual steps are worth automating, and which are not
Automating the wrong step is worse than leaving it alone, because it hides the problem behind a green tick.
Automate: a copy from one screen to another
If a person reads a field in one system and types it into another, that is a message between two systems, not a job for a human. It should be a message.
Automate: the same decision taken the same way every time
Approvals under a threshold, allocations by a fixed rule, reminders on a schedule. Write the rule down, then let software follow it exactly, every time, with a record.
Automate: chasing
Most chasing is a query plus a message. It is also the work people quietly hate and quietly skip, which is why the exceptions pile up where nobody can see them.
Leave alone: the step where judgement happens
If two experienced people would answer differently and both answers would be defensible, automating it does not remove the argument. It moves the argument into a support ticket a fortnight later.
Leave alone: rules nobody has written down
If we cannot get the rule onto one page during the audit week, it is not a rule yet. We build the tool that makes the exception visible, watch it for a quarter, then revisit automation with evidence.
Leave alone: the low-volume step that is somebody's only look at the process
Removing it saves an hour a month and costs you the one person who notices when something has started going wrong.
Replacing a live system without a big-bang cutover
The two-year rewrite with a single go-live date is the standard way these projects fail, so we use this instead on every modernisation.
- Step 1
Put a boundary around the old system
Nothing is rewritten yet. We place an interface in front of the parts we intend to replace, so the old implementation and the new one sit behind the same door and callers cannot tell which is answering.
- Step 2
Take one slice, the one carrying real money
A single process end to end, not a technical layer. Usually the one where the workarounds are worst, because that is where the payback shows up first and where the team will notice the difference.
- Step 3
Run both, compare, then switch
The new slice processes the same transactions as the old one, and the outputs are compared before anyone depends on the result. Switching is then a configuration change, not a weekend and a war room.
- Step 4
Delete the path you replaced
The old code path is removed, not left dormant behind a flag. Dormant paths come back on at the worst possible moment, usually during a peak week.
- Step 5
Repeat until the old system is a shell
The final release is usually the smallest one. By then the operation has been running on the new system for months and nobody needs to be told the date.
We have not published a case study for this work yet
There is no named client story on this page, and that is worth explaining rather than papering over.
Firm-level figures, not an application result
Woodfrog has delivered for 20+ companies. The median time to a first production-grade artefact is six weeks, and the median verified recovery or saving is $240k, signed off by the customer's own Finance team.
Borrow a result from another discipline
Our published case studies belong to analytics, data engineering and AI evaluation. A dashboard consolidation result on a page about replacing your order system would tell you nothing useful, so we have left it out.
Questions that actually test us
Ask how we would cut your first slice, which of your systems we would let own which field, and what we would refuse to automate. Then judge us on the week one one-pager.
The bar it has to clear
A named applications and automation case will appear here once a customer agrees to be named and the numbers have been through their Finance team. That is the bar every other number on this site cleared.
Deciding which system owns which field
Most integration work is not plumbing, it is agreeing once who is allowed to be right about each field.
- Sales CRMOrder status
- ERPOrder status
- Warehouse systemStock on hand
- Courier portalDelivery promise
- Finance ledgerCustomer balance
- Team tracker sheetStock on handCustomer balance
When there is a model in it, whose it is
A good deal of what we build in this practice has no model in it anywhere, and where one earns its place we build directly on Claude with no reseller layer.
Objections we hear from operations leaders
The questions that come up on almost every first call.
Is AI writing our system, then?
No. AI does first passes and we review every one. The mapping decisions, the thresholds and the rules a regulator would ask about are made by the people whose names are on the work. What AI removes is the transcription.
We already pay for an ERP. Why would we build anything?
Usually you should not. The real question is what the product does not cover and how many hours a week your team spends covering it by hand. If the gap is configuration rather than software, you will know after week one.
Our last replacement project ran for two years and got cancelled.
That is the normal outcome of a full rewrite with one cutover date. We work in slices, both systems run alongside each other, and something is in real use by week three. You can stop after six weeks.
Who owns the code, and can our own team maintain it?
You own it from the first commit, in your repositories. We build with a stack your team can hire for, and hand over with documentation and an on-call runbook. Week seven onwards is because you want it, not because you are stuck with us.
You have no case study for this. Why should we believe you?
Because we told you, rather than showing you a result from a different discipline and hoping you did not check. What we offer instead is week one: two calls, one real transaction traced end to end, and a one-pager you keep either way.
Our data is a mess. Should we fix that first?
Not always. A missing system is often why the data is a mess, because the process is held together by re-keying and a sheet. Week one tells you which order is correct, including when this is not an applications problem at all.
Half our staff are not at a desk. Can they actually use it?
That is a design constraint from day one, not something added later. Field applications are built offline first, and the test is whether someone can finish a job on a phone with no signal and have it recorded correctly back in coverage.
Where does AI fit into this, if at all?
Only where it earns its place. A good deal of what we build in this practice has no model in it anywhere, and that is the right answer more often than the market currently suggests.
And when there is a model, whose is it?
We are in the Anthropic Claude Partner Network and build directly on Claude with no reseller layer, using Sonnet for production reasoning, Opus for the hard analyses and Haiku for the cost-sensitive long tail.
The rest of the practice
These are genuinely different jobs with different ways of failing. Most engagements start in one of them.
- Data engineeringJobs that finish, migrations that reconcile, and storage that stops paying for cold data.
- Data integration and governanceOne set of records the finance team and the operations team both accept.
- Data platforms and modernisationOff the platform you outgrew, without a twelve-month freeze on new reporting.
- Apache SupersetSuperset built and run by people who commit to the project, including embedding and Kubernetes.
- Command centresThe one screen an operations floor runs the day from, not another dashboard.
- AI audit and roadmapOne week, and you know which two or three AI initiatives are worth building.
- AI evaluationA graded eval set, because an AI system cannot simply pass or fail a test suite.
- AI governanceGovernance you can defend in a board meeting and audit on demand.
- AI agentsOne reasoning agent on Claude, on your live data, with evidence and a kill switch.
- Data agentsAgents that watch the data, flag what moved, and explain what is driving it.
- AI use case, guaranteedOne production agent in eight weeks, or you do not pay for the build.
- Application modernisationThe system nobody wants to touch, replaced a slice at a time rather than rewritten.
- System integrationSystems that stop disagreeing about the same customer, order and item.
- Process digitisationThe process that still runs on paper, WhatsApp and one shared spreadsheet.
Start with the Week 1 audit
Two calls, a fixed fee, and one real transaction followed end to end from the screen where it starts to the ledger where it lands. The one-pager is yours whether or not we build anything. NDA-friendly, fixed scope. hello@woodfrog.tech, Pune.