Reinvent the workflow.
We look at how the work should run before we automate any of it.
Focus
We put AI to work inside businesses that already run, on the systems they already have. We pick one workflow, build the missing piece with the people who do the work, and leave it running.
We look at how the work should run before we automate any of it.
We write the software ourselves, on the systems you already use.
Plain code for the predictable parts. AI for the messy ones.
Who
Operators and the people who run a business: a CEO, a CFO, a head of operations, a controller, usually at a mid-sized company. Some of those companies are backed by private equity. Others are not.
The work goes better when we can get time with three people: the one who can decide, the one who does the job every day, and the one who can open the systems.
Today
The ERP is in place, and people still keep a spreadsheet next to it because the everyday task takes too long in the system.
Invoices and reports arrive as PDFs and spreadsheets in a dozen layouts, and someone retypes them.
The monthly numbers come from files that do not share a chart of accounts.
A chat tool can answer a question. The work itself still waits on a person.
The next project starts from scratch, because the last one lived in someone's head.
The work
A CFO or a head of operations should be able to find their own work here.
Files arrive in different shapes. We map them onto one chart of accounts, and every number keeps a link back to the file it came from so a person can check it.
The repeat work that passes between teams, where someone still has to remember the next step.
A lot of this still moves by phone, photo, and spreadsheet. That is usually where the day goes.
We work beside the ERP. What we leave should be something the team can run, with a written way to roll a change back.
A plain view of how the work is going, drawn from the company's own operating numbers, using the access the company already has.
These run in the background on the systems you already use, and anything unusual goes to your team.
Building
We sit with the team and watch the work. We write down the steps, the files, and the exceptions people handle without thinking about it. Then we build on the tools they already open.
Where the input is messy, a model takes a first pass and proposes an answer. Before that answer touches the books or a customer, a person reviews it and says yes or no. Where a number has to match, a script does the math, and a person checks the result.
We run the workflow on cases the company has already closed, and we compare the answers. Those cases stay as a test set, so a later change gets the same check.
Definitions, decisions, test cases, and what was accepted go into a written record. The next workflow starts from that record.
A project
One company, one workflow, with the person who owns it.
You leave with a one-page description of the work, who does it, and what done means.
That includes the exceptions that show up every month.
You leave with a map of the steps, the files, the systems, and the odd cases.
A model where the input is messy, a script where a number has to match, and a person approving the changes that matter.
You leave with a version the team can try on real work.
We run it on work the company has already finished, and we compare.
You leave with the test cases and the comparison, in writing.
We show the people who will use it, hand over the record, and note what the next project can reuse.
You leave with the workflow in daily use, the code, the documentation, and a named owner on your side.
Most first projects stay small. How long one takes depends on access, the state of the data, and how costly a mistake would be. We agree the schedule before we start.
Example
This is an illustration. It is not a client.
A distributor gets supplier invoices by email. They arrive as PDFs, and the layouts rarely match. Two people key them into the ERP and match them to purchase orders.
We read the invoice and propose the vendor, the lines, and the amounts. A script checks that proposal against the purchase order and flags a line that does not match. The clerk sees the proposal beside the original PDF, fixes what is wrong or approves it, and the invoice posts only after that. Approved invoices stay in the test set, so the next change is checked against cases the company has already accepted.
Control
A change to the numbers goes through a script, with a check a person can review.
When the workflow touches personal or financial data, it can run privately for your company. Access stays with the people who need it.
Every suggestion, approval, and change is logged.
You own what we build. You can take our access away and export the full record.
Fit
A product you can already buy does the job at a fair price. We will say so.
No one can own the workflow, and no one can open the systems.
The aim is a demo or a chatbot, and the daily work can stay as it is.
A mistake would be serious, and a person cannot review the result before it takes effect.
Questions
One workflow in one company, small enough that we can finish it and check it properly.
Time with the person who does the work, someone who can approve a change, access to the systems, and a handful of finished examples.
We build on what you run today. If a move to a new ERP is already underway, we can help with that move.
You do. The code, the notes, the test cases, and the record of what was decided.
Whichever one fits the task and your rules for the data.
It depends on the workflow and the systems involved. We agree it before any work starts.
Tell us one workflow that's eating your team's time.