A fortnight's work, done in under an hour

We recently connected a client's order management system to DPD, the courier service, so they could push shipping labels and tracking codes straight to the printer without anyone keying them in by hand. A few years ago, that job would have meant a couple of weeks of work: reading through API documentation, writing the repetitive plumbing code, then testing and re-testing until it held under real conditions. This time, we had a working first version in under an hour.

I want to walk you through how, because it's more interesting than the headline, and it explains what is actually changing in the work we do for clients.

The editor sees the whole picture

Most of our work happens in a code editor, the software we use to write and manage code. This quarter, the team has been working almost entirely in Cursor, an AI-native editor built on the same foundations as Visual Studio Code, the tool that a large share of developers already use every day. The familiar base matters more than it sounds. Nobody had to down tools and relearn their craft.

What sets Cursor apart is what it can see. A standard coding assistant looks at the single file open in front of it and little else. Cursor reads the whole project at once: how the front end talks to the back end, where the data lives, how each part depends on the others. That awareness of the full context is what makes it genuinely useful rather than just fast. When we built the DPD connection, the tool was not guessing in the dark. It already understood the system it was plugging into, so the first draft it produced was close to the mark, instead of a generic starting point we would have to unpick.

Where the human stays put

Here is the part I am careful to be straight about, because it is easy to oversell. The AI did not run off and build the integration on its own. Our team set the context, defined the problem, reviewed every output it gave us, and tested the result properly before it went anywhere near the client's live system. AI finds the problems. We still decide how to fix them.

That distinction is close to the whole job now. The speed is real, but speed with no judgement behind it is just a faster way to ship a bug. A tool that writes plausible code in seconds is only an asset in the hands of people who can tell good code from code that merely looks right. In practice, the time we save on the first draft gets spent where it counts, on the review. We read what the tool produces, run it against real data, and try to break it before a customer ever could. That courier job went through the same wringer. The hour bought us the scaffold. The rest of the day went into making sure it would not fall over on a busy Monday.

What the speed actually buys clients

The same approach has changed our website builds. Projects that used to take weeks are now shipping in under two days. This is not a quiet way of charging the same for less work. It is the opposite. When the build itself stops eating the timeline, that time does not disappear from an invoice. It goes back into the parts that decide whether a site is any good: harder testing across real devices and edge cases, and the polish that usually gets squeezed out when a deadline looms. Our clients get a better result, sooner, inside the retainer they already have.

We are also building small internal tools to smooth out our own workflows, the repetitive steps that used to quietly slow a project down. Those gains do not stay on our side of the fence. They turn into faster turnarounds and quicker changes on an account, week to week.

A quick word on reliability, because it is the question I would ask in your shoes. Faster does not mean flakier. If anything, the speed lets us spend more of the timeline on the unglamorous safety work: the error handling, the what-happens-when-the-courier-system-is-down cases, the load testing that decides whether an integration is a quiet convenience or an out-of-hours phone call. Those are exactly the parts that used to get rushed when the clock was against us, and they are where a good chunk of the reclaimed hours now go.

The maths on what is worth doing has changed

We have barely scratched the surface of what this enables. The tooling is moving quickly, and we are testing constantly to work out where it earns its place and, just as importantly, where it does not belong. It goes without saying, we would rather find the limits ourselves than discover them on a client project.

For clients on retainer, the speed and scalability are already working in their favour. A change that once meant a quoted scope and a fortnight's wait can now be a short conversation and a quick turnaround. An integration that would have been hard to justify on cost a year ago might be a sensible afternoon's work today.

So here is my one practical suggestion. If there is something you have parked, an integration you decided was too fiddly, or a rebuild that felt too slow to be worth the disruption, raise it with us. The reasons it sat on the shelf may no longer hold. The work has not become less careful. It has just become a great deal faster, and that quietly opens up things that were not on the table before.