Every engagement follows the same idea: see first, then build — with AI as the tool that usually turns it into days instead of months — then hand over, always on site and always shaped by what's found with you. If the job is bigger, only the duration changes, not the approach: at the same day rate.
The first day begins with watching, not presenting: shadowing the people who do the work every day. How does an order come in, where does someone update a spreadsheet, which step costs time every single time. That includes what systems exist — an accounting package, a CRM, a planning tool — and what data sits in them.
Mostly it's about where it hurts: tasks done twice, information that never comes together in one place, something everyone agrees "needs sorting out eventually" without anyone finding the time. Those are usually the spots where a small piece of software makes the biggest difference.
By the end of the first day, a concrete picture of what's there is in place, with a first estimate of what's worth building. That is reviewed with you the same day.
Not picking a technology upfront and then looking for a problem to fit it — the choice rests on three things: how much time or how many errors a task costs today, how good the underlying data already is, and whether a solution can genuinely be finished within the time the engagement allows.
Three examples come up most often — not because that's where the limit sits, but as an illustration of how quickly that kind of work usually gets solved.
Reorder points, safety stock and an ABC breakdown calculated from your own order history — no crystal ball, but a timely signal when something is about to run out.
Mainly for anyone who orders today by gut feel or from a loose spreadsheet.
Needs a foundation to build on: roughly a year of order history and known lead times from your suppliers.
Data from supplier invoices and documents is picked up automatically into the system you already use, without manual retyping.
Mainly for anyone retyping the same invoice by hand several times a week.
Follow-up flows inside the CRM or mailbox you already use, so a lead doesn't go cold just because nobody found the time to reply.
Mainly for anyone whose leads sometimes get a reply after days — or never.
If it turns out during the engagement that something else pays off more than what was agreed upfront, that is aligned with you — the goal is that something useful is running, not sticking to the original plan at all costs.
A working prototype convinces faster than a document — people react more honestly to something they can click than to a list of requirements. So the build phase doesn't start by writing a specification, it starts by putting something in front of you and letting you try it. What works stays; what's wrong becomes visible before it's expensive to fix.
Almost every developer uses AI to write code today — that alone isn't a differentiator anymore. "Someone reads everything before it goes live" sounds like the obvious answer, but for software of any real size that stopped being a working safety net long ago, AI-written or not. Safety doesn't come from reading every line. It comes from the system around the code.
That starts with the foundation: who can reach which data, and what someone in a given role can and can't do, gets designed early and on purpose — not decided halfway through and never patched in after the fact. Fixing that later isn't adding a coat of polish, it's rebuilding the foundation. How something looks — colour, layout, style — can still change late and deliberately stays open; how it works and who can do what doesn't.
On top of that, every piece of access gets no more rights than that task needs: if something does go wrong, the damage stays contained to that one piece, not the whole system.
Working isn't the same as safe. Code that runs without errors can still grant access to someone who shouldn't have it — a gap nobody notices until it's exploited. So testing doesn't just check that something does what it should; it separately checks that it refuses what it shouldn't allow. The first doesn't prove the second.
And whatever does go wrong doesn't stay unnoticed and can be undone — see further down for how failures get made visible instead of sitting quietly broken.
That combination — building fast, with permissions and a data model that are deliberately settled early, and one person who knows at every point what the software does, how it runs, what it touches and how it's secured — is what makes this speed safe rather than reckless.
Handover includes an explanation for the people who will use it: where the code or configuration lives, how to change something, and what to do if something breaks. No technical document that only its author understands.
The goal is that your own people — or your existing IT partner, if you have one — can carry it forward without having to call Kufu back in. Want to keep building anyway? That can happen through individual days, without needing a new engagement for it.
Most people who can build fast with AI can't keep the result running in production; most people who can run production don't build fast. Kufu does both: seventeen years as an entrepreneur, and still today building and maintaining Veton's firmware, cloud platform and app. Software that quietly stops working after a few months is worse than no software at all — it still looks like the work is getting done. So what happens after handover isn't an afterthought, it's a fixed part of every engagement.
Failures are loud, not silent. Every piece of software gets a visible signal the moment it stops working or runs into something it can't handle — an email or message to a named person, instead of quietly failing in the background. Software that fails silently is worse than none: at least without it you know the work still needs doing by hand.
It runs on infrastructure you own. Where possible, the software just works inside your mailbox, CRM, ERP system or an automation platform you already pay for.
Where it needs a place of its own to run, it goes into a container — think of it as a self-contained, portable box holding everything it needs — on a small, affordable server you pay for directly (for example a droplet at DigitalOcean, typically tens of euros a month), or on your own server if you already have one. No expensive subscription with a large cloud provider you can't leave, and no dependency on Kufu: because it sits in a container, it can move to another provider, to your own infrastructure, or to whoever takes it over next. You hold the access and the bill.
A small server like that does need occasional upkeep — an operating-system update, a security patch, the odd restart. Your own IT person or partner can handle that: it's deliberately ordinary, everyday technology, nothing kept complicated on purpose. And it's exactly what Individual days are for too: a day at the fixed day rate for when it needs real attention again.
There's a named internal owner. Who that is gets agreed with you before the engagement ends, and the handover document is written for that person: what the software does, what triggers it, what it looks like when it's broken, and the first things to check.
Things drift. A supplier changes an invoice layout, a system a link depends on gets updated, someone who knew the software leaves. That's part of running automation, not a sign of bad work — and it's exactly what Individual days are for.
One fixed point of contact on your side, who helps plan the days and stays reachable for questions during the engagement — not necessarily the owner or management, but someone who knows the work and the systems.
Access to the systems and data that are relevant: a login for the accounting package, an export from the CRM, or simply someone who can walk through how a process runs today.
And time from the people who actually do the work — not the whole day, but enough to answer questions and test the result together before handover.
Not every piece of software needs an AI model — some of the work is just ordinary software, with no data going to a language model at all. Where it does, business data never runs through a personal, consumer-grade account: that always goes through a provider under a data processing agreement. If you're already working with an AI tool where that isn't in place, that is raised explicitly before the engagement builds on it.
Your data is never used to train models, and stays inside the software built for you — not reused for anything else, not even for a different engagement.
Where software processes personal data belonging to your own customers — as with automatic lead and email follow-up, which inevitably involves names, email addresses and message content — Kufu is your processor for that work and you're the controller. Before that work starts, a data processing agreement is put in place: alongside the non-disclosure agreement, not instead of it.
Access to your systems stays minimal and time-limited: only what's needed to carry out the engagement, for no longer than it runs. Signing a non-disclosure agreement is not a problem.
Half an hour is enough to know whether Kufu can do something for you.