Four months had it almost working.
Two days had it running.
AJAK Fuel Axis is the platform a UK fuel haulage operator runs the fleet on — depot to delivery, compartment by compartment, invoice to Xero. The build came to us through a UK agency that had spent four months on a generative platform and still didn’t have something the operator could work on.
The build the agency couldn’t close
AJAK Fuel Axis wasn’t a speculative brief. The UK agency commissioning it had scoped the requirements properly, the four user roles mapped out, the integrations listed, and an operator on the other side waiting to run the fleet on it. They had chosen a generative build platform, and they had spent four months pushing the build toward something the operator could actually work on. At month four it was still almost working.
Almost working in this build looked like a specific loop. A fix to the compartment volume flow landed clean on a Tuesday; by the following Monday a change to the rebate invoice path had silently broken the trailer inventory updates. A POD template lined up under one customer’s branding and drifted under another. The UI quality kept regressing. Work was moving; the product wasn’t arriving.
When the requirements document reached us, DeepBuild shipped the platform in two days. Seven days later, the fuel operation was live on it.
Why a tanker is the wrong problem for a generative tool
Fuel logistics isn’t the shape generative platforms ship well. It isn’t a dashboard. It’s a state machine with physical constraints on every click.
A single tanker has multiple compartments. Each compartment holds exactly one fuel type at a time — Diesel, Derv, Kerosene, Gas Oil, Petrol, Aviation Jet A1, Heating Oil, AdBlue, HVO, Marine Gas Oil, plus six more — at a specific volume. A driver’s day stacks a collection at one terminal into three compartments, a delivery at one customer site that empties two of them, and another delivery that draws half the third. The platform has to know, at every point on that route, which compartment holds what fuel at what volume, and it has to update that state the moment each stop closes.
Stack the rest on top. ADR transport documents generated off the products actually loaded — UN numbers, hazard classes, packing groups, tunnel codes. Driver certifications that expire (ADR, PDP, HGV licence, terminal induction). Trailer certifications that expire (MOT, SLP, ADR). Volume variance rules that refuse to close the stop if actual differs from planned beyond threshold without a driver note. Two POD templates chosen per customer. Rebate jobs that recompute Purchase Order and Transport Invoice against actual volumes collected, not the planned ones.
Generative platforms close the first sixty percent of this fast. The last forty — where every element has to stay consistent with every other as the day’s jobs move — is where four months disappears.
What the platform actually does
The job engine is the spine. Office staff create a job — delivery, collection, or site work — with any number of collection and delivery stops, a customer, products per stop, and a pricing shape assembled from per-litre, fixed, day rate, mileage, and tolls in any combination the customer contract specifies. Jobs are stamped AJAK-YYMMDD-XXXXXX and drop onto a live dispatch board the moment they land.
The driver PWA works the job stop by stop. At a collection, the driver enters compartment volumes, photographs the Bill of Lading, enters the BOL number, photographs the meters before and after, and captures the collection signature — or toggles unmanned if the terminal runs that way. At a delivery, compartment volumes drawn down, tank gauge photos before and after, the ullage pre-pumping declaration, the delivery signature, and GPS at completion. Everything the office needs to invoice is on the stop before the truck pulls away.
Trailer state updates in real time. Each compartment’s current fuel type, volume, and source location move as stops close. A compartment filled at the depot and three-quarters delivered at stop one leaves the remaining quarter — of that specific fuel type — visible to the next job that could draw from it. There is no end-of-day reconciliation, because the state is always current.
ADR transport documents generate automatically off the compartment configuration the instant collections complete. UN number, class, packing group, tunnel code — pulled from the fuel product table, attached to the job, ready to travel with the load.
Proof of delivery composes the moment the delivery signature goes down. The stop’s photos, signatures, and actual volumes flow into the customer’s template — AJAK or Nirva — and the PDF emails through Resend to the customer’s POD address before the driver has left the site.
Rebate jobs — where the customer is paid for fuel being collected — generate a Purchase Order PDF for the fuel and a Transport Invoice PDF for the haulage, separately, both recomputed against actual volumes. What invoices is what moved.
Invoicing runs off completion. One calculator composes per-litre × actual volume, day rate × days, mileage × miles, tolls, and rebate maths, and lays the breakdown out line by line. Invoice numbers stamp INV-YYYY-XXXX; the payload lands in Xero and fires a Zapier webhook in the same call.
Compliance tracking sits under assignment, not after it. A driver whose PDP expires this month is flagged before they’re assigned. A trailer whose ADR expires this week is excluded. Terminal inductions are tracked per driver per terminal. The gap is closed at dispatch, not at audit.
The customer portal is a scoped read-only view per company — their jobs, their invoices, and the supporting evidence on every one of them: POD, BOL photos, meter photos, signatures. Disputes route to the sales rep. The paperwork calls the office used to field all day stopped.
How change lands on it
The thing the agency had lost four months to wasn’t any one feature. It was iteration. Each new rule — a new compartment behaviour, a new pricing wrinkle, a new report — compounded against a codebase nobody had full grip on.
On Creatr, a change that touches data or backend goes through a plan before code. DeepBuild describes what will move — tables, flows, boundaries — and the change is approved against that plan, not against a guess. Once the code lands, end-to-end tests run across the functionality already in production. Nothing merges that regresses a working flow.
Two days shipped the platform. The five days between the build and production weren’t spent chasing regressions; they were spent shaping.
On the road
The operation is running fuel on it. Dispatchers build routes. Drivers close stops on the PWA. Tankers keep their own books compartment by compartment. PODs leave the platform as the fuel arrives. Invoices close the day the fuel moved and land in Xero the same afternoon. The paperwork the office used to chase isn’t there to chase.
You deliver what you say you're going to deliver — we've confirmed that. The flexibility, transparency, and quality of the work make Creatr a great partner. For complex projects going forward, why wouldn't we just start with Creatr?
The agency’s second choice
Agencies that ship serious software for clients have two things at risk on every build: the calendar and the reputation. This one burned four months defending the second. They brought the same requirements to us, and the second build shipped.
Back to real products built