Ways to start

Pilot builds

A small first project at a fixed price, so you can find out whether an automation works for you before committing to a full build. We agree what success looks like in writing before starting, including the result that would make us tell you to stop.

A pilot that cannot fail is not a pilot, it is a first instalment. Putting the number in the proposal is what makes the difference.

How it works

Why agree the number first

Because otherwise every pilot succeeds. Without a number agreed in advance, the result is always interpreted favourably by the people who built it. That is not dishonesty, it is how anyone reads their own work.

Agreeing it first also forces a better conversation at the outset. Deciding what "good enough" means for your task is genuinely the hardest question in the project, and doing it before the build is far cheaper than after.

What happens if it fails

We tell you, and we recommend stopping. You keep the code, the test examples and the documentation, and you have spent a small fixed amount to find out something true. That is a good outcome, and it is considerably cheaper than the alternative, which is discovering it after a full build.

Where it fails for a fixable reason (the data was not there, the task was scoped too broadly) you get that reasoning too, and can decide whether closing the gap is worth it.

What happens if it works

The pilot is production code, not a prototype to throw away. It runs on your accounts from day one. Extending it is a normal fixed-price build, and the measurement from the pilot becomes the baseline for ongoing monitoring.