Turn Your Business Knowledge
Into Software
Your edge isn't in your CRM. It's in your head, and in three other heads, and you can't quite write it down. We get it out, write it down for you and build it into software your team and your AI can both use.
Tacit
TO EXPLICIT TO CODE
Days
NOT YEARS
Yours
KNOWHOW, CODE AND DATA
Your edge is your knowhow. Get it out of people's heads.
Michael Polanyi called it tacit knowledge in 1966: "we can know more than we can tell". MIT's David Autor used Polanyi's paradox to explain why tasks needing flexibility, judgement and common sense are hard to automate. Your senior estimator, your head of underwriting, your bookings manager. They all run on it.
The old way to capture that knowhow was slow: interview people, write a manual, hope the business didn't change before anyone used it.
LLMs are very good at the bit that was always the bottleneck: interviewing a person until you have the rule out of them, then writing it down properly.
WHERE IT LIVES NOW
- In your head
- In three veterans' heads
- In a Word doc from 2019
- In a 47-tab pricing spreadsheet
- Walks out the door at retirement
WHERE IT BELONGS
- Named rules in one place
- Software your team runs through
- Context your AI can read
- Training material for new hires
- A clear artefact for diligence
Bus-factor of one.
The UK had 5.5 million private sector businesses at the start of 2024, and SMEs accounted for 99.8% of them (DBT Business Population Estimates, 2024). A lot of those businesses still depend on one or two people knowing what to do next.
When the founder retires, sells, or just takes the wrong holiday, the rules they ran the business by go with them. Diligence asks for evidence. "Ask Dave" isn't evidence.
The oil and gas industry has a phrase for experienced people ageing out at once: the "great crew change". The same risk is easy to recognise in British engineering firms, accountants, surveyors and family businesses.
SCENARIO ONE
Your best estimator quotes a job in twenty minutes and wins it. The new estimator takes two days and prices it wrong. Nobody can explain the gap.
SCENARIO TWO
You bought an AI assistant. It cheerfully gets things wrong, because it doesn't know what your business considers a good answer. There's nowhere to point it.
SCENARIO THREE
You're planning to sell. The buyer's diligence team asks how decisions get made. The honest answer is "ask Dave". Dave is 64.
SCENARIO FOUR
You've written process docs three times. They're already out of date. Nobody opens them. The actual rules live in Slack threads and a few people's instincts.
SCENARIO FIVE
You're scaling. Hire ten people, quality drops. The ten don't know what the original four knew, and the original four don't have time to teach them.
Two things that didn't work before, now do.
LLMs help with the interview.
Edward Feigenbaum, the Stanford computer scientist behind early expert systems, called knowledge acquisition "the critical bottleneck problem in Artificial Intelligence" in 1982. It needed a human knowledge engineer, and the expert you were interviewing usually couldn't explain what they did anyway.
An LLM is useful in the room because it tracks the cases, spots the "it depends" answers, and keeps asking until you've named what it depends on. Your expert and our knowledge engineer still approve the rule.
Bespoke software is cheaper to start.
McKinsey's 2023 software engineering study found generative AI cut task completion time by 45 to 50% for code documentation, 35 to 45% for code generation, and 20 to 30% for refactoring. The GitHub Copilot trial reported developers finishing one JavaScript task 55.8% faster than the control group.
The economics moved. For the right internal tool, a first version is measured in days, not quarters. The hard bit is knowing which rules to encode first.
The useful work lands in five buckets.
Different industries, same buckets every time. Pick the one that costs you most when it's wrong. That's the one we encode first.
Qualifying
Who's a good fit, who isn't, what to ask on the first call, when to walk away. The reason your best salesperson closes and the new one doesn't.
Pricing & estimating
Square-metre rates, risk uplifts, sequencing assumptions, "this one's awkward" gut-feels. The rules that live in the senior estimator's head.
Risk & scoring
Underwriting heuristics, credit calls, supplier scoring, recruitment fit. The "I wouldn't touch that one" instinct, named and weighted.
Triage & routing
What goes to whom, what's urgent, what's been seen before. NHS Pathways uses a clinical decision support system for 111 and 999 triage. Your support queue has the same kind of routing problem, without the medical stakes.
Sequencing & playbooks
What you do, in what order, when X happens. Onboarding, escalation, month-end, the choreography of the business when nobody's watching.
Where we come in.
Four steps. Recruitment, engineering, financial advice, manufacturing. Different domain, same arc every time.
No year-long consulting engagement. A focused elicitation phase, then working software the team starts using. You own everything we write down and everything we build.
BOOK AN ADVISORY CALLPick the bucket
Half a day with you. We pick the one area where getting the rules out of people's heads pays for the whole engagement. Usually pricing, qualifying, or whichever decision someone is still ringing the founder about at 8pm.
Elicit it properly
A short series of sessions with the people who actually know. We bring an LLM into the room as a structured interviewer and a human knowledge engineer to push back. You leave with the rules written down for the first time. Nonaka called the move from tacit to explicit knowledge externalisation.
Build it into software
A working tool your team uses. A quoting app, a scoring screen, a triage queue, an onboarding flow. The rules are the source of truth. The software is just what runs them. The AI in your stack gets the same rules as context, so it has something concrete to read.
Keep it alive
Rules drift. Every override your team enters becomes a candidate change. We give you a light review rhythm so the knowledge stays current instead of going stale the way the 2019 process doc did. Add the next bucket when you're ready.
Encoding expert judgement isn't new.
Expert systems were doing useful commercial work in the 1980s. The lesson worth keeping is maintenance, ownership and trust.
XCON configured VAX orders.
Carnegie Mellon and DEC encoded configuration knowhow into about 2,500 rules. By 1986 it had processed 80,000 orders at 95 to 98% accuracy. DEC estimated $25m a year saved. The maintenance lesson is the bit that matters now.
NHS Pathways triages 111.
NHS Pathways is a clinical decision support system for remote assessment in NHS 111, 999 and urgent care. Its clinical authoring team are registered practitioners. Same pattern as your triage queue: questions, routing and review.
Underwriting starts with judgement.
Before you have a prediction model, you still have criteria, thresholds and exceptions. Those rules are worth writing down before the business pretends a spreadsheet is governance.
Sources: Polanyi (1966), Autor (2014), Nonaka & Takeuchi (1995), McDermott on XCON (CMU), NHS England Digital, DBT Business Population Estimates 2024, GitHub Copilot productivity research, McKinsey on developer productivity (2023).
The ones we get asked first.
Isn't this just process documentation with extra steps?
No, because the output is software your team has to run through, not a PDF on a shared drive nobody opens. The rules get used because the work goes through them. That's the difference between knowledge that's written down and knowledge that's actually applied.
My experts can't explain what they do. They just "know".
That's Polanyi's paradox, and it's the normal starting point. We don't ask "what's the rule?". We walk through real cases. The expert reacts, we ask what changed their mind, and we keep going until the rule survives counterexamples.
Will the AI just hallucinate our rules?
The LLM doesn't write your rules. It interviews, paraphrases, and structures. Your expert and our knowledge engineer approve every rule before it goes in. The software then runs them deterministically, the same way every time, so you can audit any decision later.
What happens when the business changes?
One old expert-system failure mode was rule maintenance. We set up a short monthly review where overrides your team has entered get triaged into rule changes. The knowledge stays current because changing it is cheap and the people closest to the work do it.
My senior people will think this is about replacing them.
In practice it does the opposite. They stop being the bottleneck on every small decision and get their time back for the genuinely hard cases the software flags up to them. The good ones quite enjoy seeing their knowhow written down properly. The ones who don't, you needed to know about anyway.
How is this different from your spreadsheet replacement service?
Spreadsheet work starts from something that exists. This starts from something that doesn't, because it's in heads. The two often end up adjacent: we encode the rules, then the next project is the system the rules run inside. Sometimes that's a sheet replacement, sometimes it's a new tool.
Who owns the rules and the code?
You do. The rule documents, the code, the data. Hand-over to your team or your next agency is part of the deal. No lock-in. If it ever needs to read as an asset in a sale, it's structured so it does.
How much, how long?
First bucket: elicitation in days, first working version of the software not long after, priced per phase, fixed before we start. Second bucket is cheaper because the pattern carries over.
Get the knowhow out of the heads.
Pick the area of your business that depends most on one or two people knowing what to do. Tell us about it for half an hour. You'll come away with a clear answer on what it would take to get those rules out and what we'd build first.