Skip to content
Home For whom What I offer
The Scan The Sprint The Connector The Build Fractional AI Architect
Platforms & CMS Lab Writing About Contact
NL EN
Situation · AI has to take a role in your product

Everyone wants AI in the product. Nobody wants to say what it may decide.

There is a feature idea, maybe already a prototype. Technology is not the problem. The conversation stalls on what comes after: what role does AI take in your user’s experience, what may it do on its own, and where does your team stay accountable when it goes wrong?

01

Our competitor already has it. We have a demo and a discussion.

02

Product wants to let it run, engineering wants a human in between.

03

We do not know what we can promise our customers about reliability.

Two people at a small table, with a tablet showing a red switch and a small robot between them.

01 · A design question, not a technical one

Where does it stall?

Building a feature is manageable. Deciding what that feature may decide, and who explains it when it is wrong, is not. That is why it is stuck between product and engineering. Three questions that need to be in writing before you put months into it.

Question 01

What may it do on its own?

A large rotary dial with a red pointer.

And where a user should keep the final word. Per step in the experience, not as a general principle.

Question 02

What do we promise our customers?

A red wax seal with two blue ribbons.

Reliability, explainability, and what happens when it goes wrong. You need to be able to say that before you sell it.

Question 03

How does it fit what is already there?

A hand places a red jigsaw piece in the last gap of a small board.

Your existing data, permissions, API and release rhythm. A feature detached from those never reaches production.

When this does and does not fit.

Works well when
  • There is a feature idea or a prototype, and the conversation is about what it may decide.
  • Product and engineering disagree on how much may happen without a human.
  • You soon have to promise customers something about reliability and explainability.
This is not
  • It is not an AI strategy for the whole company; if the question is still broad, the Scan is the first step.
  • It is not a build order for a feature that is already worked out, because then a Build begins.
  • It is not about a chatbot on the website, but about AI in the work your product does.

02 · Roles first, then the feature

How do you approach it?

The division of roles first, then the feature. Before you put months into this, you want three things in writing, and those three are the outcome of a ten-day Sprint.

A drafting compass with a red point on a folded drawing.
Outcome 01

The division of roles

What AI carries out, what it proposes and what a human decides. Per step in the user experience, not as a general principle.

A small gearbox on a test block, with a lit red lamp.
Outcome 02

Proof on the hardest part

Working code on the part the rest depends on, on your data. So the conversation is about what happens instead of what might happen.

A Y-shaped pipe with one branch shut off by a red valve.
Outcome 03

A decision with a path

Build or no-build, and if it is build: what it costs in time, people and money, and in what order.

Is there a feature idea like that on your side?

A half-hour call costs nothing. If it turns out the question is still too broad for a Sprint, I will say so.

Book a call

03 · What is running

What can you check?

What is below runs, and it is public or live to see before we talk money.

A round gauge on a stand, with one red needle.

Cranely proves the other side

A scorecard tool where judgement deliberately stays with people. Not everything should be delegated, and establishing that is the work of a Sprint.

To check · cranely.app

A conveyor belt with three boxes, the red one just rolling off.

I run my own delivery pipeline

Agents pick up tasks from my backlog, open their own branch and deliver the work as a pull request. I specify, review and merge. An agent cannot skip or talk its way past the quality gates: test suite, code style, front-end build and a separate review round.

How the pipeline works

To check · This site was built that way. An agent never merges by itself.

A red hard hat.

I know what production demands

Building software since 1999, fifteen of them independent, through Progress Software in enterprise environments for organisations including WHO and Van Lanschot. That is what you need at the moment a demo has to become a business-critical system.

About Daniel

To check · The full career is on the About page.

04 · Three products, from small to large

Which step fits?

Which step it becomes depends on how sharp the question already is. Prices and scope are on the page of the product itself.

A small device under a glass bell jar, with a red tag on a thread.
The Sprint

Is the question sharp?

Then the Sprint proves in ten working days whether AI can do this work: the division of roles, working code on the critical part and a build-or-no-build decision.

See The Sprint
A spotting scope on a wooden tripod, with a red band around the scope.
The Scan

Is the question still broad?

Then it starts with a two-day Scan: a map of the work, one trial on your own material and a proposal with a price.

See the Scan
A scaffold of blue tubes with one red plank on the top level.
The Build

Already know what should be built?

Then we skip the Sprint and a Build begins: a fixed scope, a fixed price per phase, and after every phase you can stop.

See The Build

05 · What people want to know

Any questions?

The questions that always come, with short answers. If yours is not among them, a half-hour call is the fastest route.

Do we need a prototype already?

No. A clear feature idea is enough. If a prototype exists, that is the starting point and the critical part becomes clear sooner.

What if the outcome is no-build?

Then for a fixed price you have avoided an expensive mistake, plus a division of roles and working code you can reuse later if circumstances change.

Can our own developers take part?

Gladly. I work out the division of roles and the critical part together with them, so the knowledge stays with you and the build afterwards needs no handover.

Which models and vendors do you use?

Whatever fits the question, including locally running models when data cannot leave the country. I build so you are not locked into one vendor.

Portrait of Daniel Plomp. A small device under a glass bell jar, with a red tag on a thread.
Who designs this

Knows what AI in a product should and should not do.

I have seen too many AI features hang between product and engineering: one side wants to let it run, the other wants a human in between. You do not settle that with a better demo, but with a division of roles on paper and working code on the part where it gets tense. Then the conversation is about what happens, not about what might happen.

Daniel Plomp · AI Architect & Builder

Where does it stall for you?

Describe in two sentences what AI should do in your product. You will hear whether a Sprint is the right tool, and if it is not, I will say that too.

Usually a reply within one working day