AI development services. Built for one job.

Assistants that answer from your own material, intake tools that ask the right questions and hand over a complete file, workflow builds that connect systems that do not talk, and reports assembled out of what you already record.

AI development services cover exactly that gap: the thing your existing tools leave a person doing by hand.

None of it is a product. Each one is built around how a particular business already works, which is the reason for building rather than buying. Where something on the shelf does eighty per cent of it, buying that is the answer, and that gets said.

What gets built most often

• An assistant that answers from your own material.

  Your documents, your prices, your policies. It answers from those or it hands the question to a person.

• An intake tool that finishes the job.

  It asks the right questions in the right order, checks what came back, and hands over a file nobody has to chase.

• A connection between systems that do not talk.

  Two tools you already pay for, and a person who copies between them every day. That person stops.

• A report built out of what you already record.

  The monthly numbers assembled from the systems that hold them, sent to whoever needs them.

The common thread is that every one of them replaces a person moving information between screens. That is the job worth building around, and it is nearly always the one nobody had thought of as a job.

Nearly always, where something exists that does most of it. A product has years of other people's problems already solved inside it, and a build starts from nothing.

This is the opposite of what a development business usually says, and it is still true. Most of what a business wants has been built already, and the version you can buy is cheaper, better tested and somebody else's job to keep working.

Building earns its place in one situation: the way you work is genuinely different from everybody else, and that difference is why customers use you. Where the gap is only habit, a product plus a change of habit does it.

When building is the right answer

• The way you work is why customers choose you.

  Not a preference and not history. Something a competitor cannot copy without doing what you do.

• Nothing on the shelf gets close.

  Not eighty per cent with an awkward workaround. Genuinely absent.

• The job runs across systems nobody joins.

  The gap between two products is where most real builds actually live.

• The volume justifies it.

  A job done twice a month does not, whatever it costs each time.

Where none of those hold, the answer is to buy something and change how the work happens. That answer is free and it gets given.

The code, the data and the accounts it runs in. Software you cannot take to another developer is rented, whatever the invoice happens to call it.

This is the question that decides everything else, and it is the one most people ask last. A build that lives inside somebody else's platform stops on the day the paying stops, and everything you put into it goes with it.

What has to be in your name

• The code itself.

  Handed over, in a repository you control, in a form another developer can pick up.

• The data.

  Yours, exportable, and not sitting in a format only one supplier can read.

• The accounts it runs on.

  The server, the model access, the connections. All in the business's name from the start.

• A way to take a copy.

  Whenever you want, with no fee attached to the request.

Agree all four in writing before any money changes hands. Afterwards is when it becomes a negotiation, and by then the thing being negotiated over is already running your business.

It will not make a judgement call you would want to stand behind, and it will not know anything your business does not already record somewhere.

A build is only ever as good as what it can see. Where a step needs a fact nobody writes down, that fact has to start being recorded before anything can use it, and that is a change to how the business works rather than a feature.

Where it stops, deliberately

• Anything that is a judgement call.

  It routes the case to a person rather than guessing. A wrong answer sent in your name is the risk.

• Anything not recorded anywhere.

  If the business does not have the fact, neither does the software.

• A process nobody wrote down.

  It cannot infer how you work. Where the process is not settled, settling it is the work.

Where a step needs judgement rather than a rule, that step calls a language model, which is the software behind tools like ChatGPT. It drafts, and the business decides whether a draft sends on its own.

The process gets written down, what already exists on the market gets checked, and the smallest useful version gets built and put in front of real work early.

Projects that go badly are nearly always the ones that tried to do everything before anybody used any of it. The smallest useful version is not a compromise, it is the thing that stops that happening.

1. The process gets written down

End to end, including what happens when something unusual turns up. This takes longer than anybody expects and it is what the build is measured against.

2. What already exists gets checked

Properly, and with the intention of not building. Where a product does most of it, that is the recommendation and the work stops there.

3. The smallest useful version gets built

The part that carries the value, and nothing else. It is in front of real work inside weeks rather than months.

4. Real work goes through it early

With the people who will use it, on live jobs. That is when you find out what the written process left out.

5. It runs watched before it runs alone

For a fortnight, with a person checking what it does. Anything failing part way stops and waits rather than half finishing.

6. The rest gets built in the order use decides

What gets added next comes from what people actually reach for, rather than from the list written before anybody had used it.

Longer than a website and shorter than the first estimate, where the smallest useful version goes first. Writing the process down is the slow half, every time.

The order it happens in

• The process gets written down.

  The slow half, and the part that decides whether the rest works.

• Then the smallest useful version.

  In front of real work in weeks, not months, because that is where the real requirements turn up.

• Then it grows in the order use decides.

  What people actually reach for, rather than the list written before anybody had used it.

The projects that overrun are the ones that skipped the first step. The ones that finish early are the ones where somebody used a rough version in week three and said what was missing.

Ask whether you should build this at all, who holds the code, what a change costs afterwards, and what happens if the developer stops working. The first question is the one that saves the most money.

These are worth asking of anybody, including this one, so the answers given here sit under each question.

• Should I build this at all?

  Usually not. Anybody who never answers that is selling builds rather than solving problems.

• Who holds the code?

  You do, in a repository you control, in a form another developer can pick up.

• What does a change cost afterwards?

  A rate and a rough time. This is the cost that arrives quietly in the second year of owning software.

• What happens if you stop working?

  Everything runs on accounts in your name and the code is already yours, so the answer should be that it keeps running.

• Am I locked into a contract?

  Not here, it runs month to month. Any arrangement you cannot leave at the end of a month is worth a second look.

All of this can also be built in house, and plenty of businesses do it well. The six steps above are the same either way.