KIMA: from an AI-built dead end to adding features again

Where they started

An investor had a consultant build KIMA with Claude, then brought Mykola in to build it properly.

What Mykola found was deployed and serving nobody. One CRM was hardwired into it. Half the credentials, the passwords and keys it uses to reach other systems, sat in the code. About half the features worked, and nobody, the AI included, could say which half or why.

That last part matters most. A product that is half broken can be fixed if you know where the break is. A product where nobody can tell what works is harder. Every change is a guess, and any guess can undo something that worked the day before.

Why it was stuck

The obvious reading was that the code was bad. That was not the real problem. The problem was the shape.

KIMA’s business rules lived in spreadsheets. Each feature had been built on its own spreadsheet. The live system read those sheets, then worked out what had happened by reading a log, a raw running record of activity, and guessing from it.

In a setup like that, there is no single path every feature follows and no clear edge around any one of them. At KIMA, the result was half a product and no map of which half.

More features would not fix it. Neither would asking the AI to try harder. The product needed a shape in which a new feature could be added without touching anything else.

What we built

Over the ten weeks, a handful of changes did the work. The sections below describe them in the order that makes them easiest to follow, not the order they were built in.

Two queues and adapters. We replaced the spreadsheet-and-log arrangement with two queues and a set of adapters. A queue is a line that messages wait in, to be handled in order. CRM events come in through an adapter, and actions go back out through an adapter, all through the same two queues. Between them sits a rules engine: the part that decides what should happen next.

An adapter does one job for one CRM. Coming in, it turns that CRM’s events into the one shape the rules engine understands. Going out, it turns KIMA’s actions back into calls that CRM accepts. The rules engine never knows which CRM it is talking to.

Rules out of the spreadsheets. The business rules became data the rules engine reads. Every event and every action is labelled with the customer it belongs to. Each customer’s rules are that customer’s own data, not something written into the code.

Credentials out of the code. The credentials came out of the code. None are left in it.

Adapters built from what a CRM really does. Every CRM has an API: the way other software talks to it. In German real estate, a CRM’s API often does not behave the way its documentation says. KIMA’s adapters are written against what each CRM was seen to do, not what its documents claim, and each one is tested on its own. A bad API cannot reach the rules engine, so KIMA keeps running when a CRM misbehaves.

Customers set up their own process. Because rules are held as each customer’s data, a customer can register and define their own process, without anyone changing the code for them.

The second CRM. KIMA started with one CRM, hardwired. It finished with two. The second went in as one adapter, contained and tested on its own. Each new CRM is one small piece to add, instead of a rewrite.

What changed for their users

Before, KIMA was deployed and served nobody. Now any customer can sign up, set up their own process and plug in their own CRM. Two CRMs are connected, and the next one is one adapter. When a CRM’s API does not match its own documentation, KIMA keeps running.

For the people building KIMA, the change is that their AI tool is useful again. Every feature now goes through the same two queues, the one shape where an AI tool can add a feature without touching anything else. A new feature now touches one place, so it does not break the others.

What changed is not the tool. It is the shape the code sits in.

How many weeks it took

Ten. In the way we work, each week of building is one version, so KIMA’s rebuild was ten versions.

This is how the weeks run. Every week there is a call with Mykola, our senior architect, who has 25 years of building software behind him. A demo video of the week’s version arrives 24 hours before each call. The code goes into the client’s own GitHub, and the system runs in the client’s own cloud account. Every version we ship has sign-in and roles set up properly, each customer’s data kept apart, secrets out of the code, and backups and monitoring switched on.

KIMA stopped after week 10. The code and the accounts were already theirs. That is how it is meant to work: you pay a week at a time, and you can stop any week.

A version is one week of building: $5,600CAD $7,900£4,200€4,900 a version.

If you are where KIMA was

If your product was built with AI tools, is live or nearly live, and nobody can say which parts work, more prompting will not get you out. Throwing the code away may not be the answer either. In KIMA’s case the code was not the problem. The shape it sat in was. Once the shape was right, the same kind of tool that got them stuck became the way they add features.

The signs to look for are the ones KIMA had. Rules kept somewhere outside the product, such as a spreadsheet. One outside system wired straight in, so that swapping or adding another means rework. Passwords in the code. Features that half work, with nobody sure which half or why. If two or three of those sound familiar, the shape is the place to start, not the next feature.

This way of working is not for every team. It suits founders who are happy to work in their own time, watch a demo, and make decisions on a weekly call. It does not suit teams who want daily standups or to direct every line.

If that sounds like you, start with free scoping. We look at what you have, agree the scope with you, and you approve it before paying anything. Then you pay a week at a time, and you can stop any week.