Map it before building it
Every engagement opens by watching the work as it actually happens, not as the brief describes it. We would rather find the six steps worth deleting than add a seventh.
About Ackho
Most business software is built by people who never have to live with it.
Ackho is a software and digital transformation consultancy in Singapore. We build the systems businesses actually run on, to the standard we learned in places where software failing was not an option.
Almost every business runs on one system that matters more than the rest: the one that takes the orders, tracks the stock, or works out what to invoice. It is usually the least loved software in the building.
It got built fast, by whoever was cheapest, against a brief nobody had time to get right. It shipped, it was handed over, and it was left alone. Eighteen months later there is a spreadsheet holding two parts of it together, a step that exists only to correct the step before it, and a process nobody can explain except to say it has always been done that way.
Nobody set out to build it badly. It was built by people who were never going to have to live with it.
We learned to work somewhere the opposite was true. In banking and government, a system that cannot survive an audit does not go out, a bad migration is a regulatory event, and whoever made the call in week two is still there in year three living with it. That is a slow way to learn and a hard habit to lose.
What changed, and the reason to start this now, is the arithmetic. Fitting software to a business used to take a floor of people and the better part of a year, so the honest advice was to bend the business around whatever was on the shelf. That overhead has dropped far enough that fit is affordable again. The judgement is still slow, human work: knowing which steps can be deleted, what the data has to survive, where the boundaries sit. What got cheap is everything around the judgement, and that is enough to change the answer.
So we work front-loaded. The first two weeks are spent watching how the work actually happens, including the parts no brief mentions, and then we put a plan in writing: milestones, a fixed fee against each one, and an explicit list of what we are not doing. You read that before you commit to anything. If the answer is less software rather than more, that is in there too.
We care more about the problem than its size. An internal tool that gives a team back an afternoon a week is worth building. So is the system that runs the whole operation, or the migration everyone has been avoiding because it looks frightening. We want the awkward ones, because awkward usually means nobody has looked at it properly yet.
What this is for is simple: a business that runs better than it did, people who spend less of the day working around their own tools, and a system still doing its job long after we have stopped touching it. The software is the instrument. The point is the business it gets handed to.
What we are for
The things we will not trade away.
Every firm has a list like this. Ours is short because each line has cost us something to keep.
Write down what is excluded
Every plan carries a list of what we are not doing. It is the least comfortable page in the document and the one that prevents the argument in month three.
Any size, any awkwardness
A small internal tool and a full transformation get the same attention. The interesting projects are usually the ones described as too awkward to be worth doing.
Less software, when that is the answer
Sometimes the right result is an integration nobody thought of, a process change, or leaving a system alone. We say so, even when the bigger build would have been ours.
Where we learned this
Built inside the places that could not afford to get it wrong.
We have shipped inside big tech and government, in places where a system that cannot survive an audit does not go out, and whoever made the call is still there to live with it three years later. That posture does not change with the size of the engagement.
Where we have worked
- ByteDance
- Shopee
- GovTech
- OCBC
- UOB
- Sembcorp
- EDB
Recent writing
How we scope, price and argue about this work.
StrategyWhat AI actually changed about build versus buyThe case for off-the-shelf software was never that it fit. It was that building something that fit cost too much. That arithmetic has moved.5 min readMethodMap the workflow before you scope the buildTwo weeks watching how the work actually happens changes what gets built more than any requirements document we have ever been handed.4 min readHow we workWhat a fixed-price milestone plan looks like from the insideFixed price is usually a sales position. It only works as a promise if the exclusions list is as specific as the deliverables.3 min readStrategyConfiguration is a build with a worse debuggerChoosing the platform and configuring it to fit is not the alternative to building. It is building, on someone else’s assumptions, with none of the tools.3 min read
Tell us the partthat is costing you.
One call. We tell you what we would build, what we would not, and what it costs, before either of us commits.