A project, from first call to launch.
Three worked examples of how we run a project, and what AI and our engineers each do at every step.
Please note: these are illustrative examples with fictional clients, not real case studies. They show how we work and the kinds of problems we solve.
From a dispatch spreadsheet to a planning tool.
A fictional family-run distribution business with 40 staff. Every morning someone planned the day's deliveries in one shared Excel file, and double-bookings were common.
- Starting point
- A shared spreadsheet, edited by three people at once
- What we built
- A web tool for planning the day, with logins and printable driver sheets
- First call to launch
- About four weeks
-
We listen first
We visited the depot and watched the dispatcher plan a full day. We collected three weeks of real spreadsheets and wrote down the rules nobody had written down: van sizes, driver hours and customers' delivery windows.
Done by: our engineers
-
We set out the options
A short written plan with three choices: tidy up the spreadsheet with automation, build a small planning tool, or buy off-the-shelf routing software. We explained the pros and cons of each honestly, including where the off-the-shelf product would have done the job. They chose the planning tool.
Done by: our engineers, with the client
-
We agree the price before we start
A fixed price and timescale in writing, with a list of exactly what was and was not included. Nothing was built until they were happy.
Done by: the client and us, together
-
A working draft in days, then we make it right
On day 7 the client could click through a working first version that AI had drafted: enter orders, assign drivers, see the day. They found four things wrong in the first ten minutes, which is the point of showing it early. Our engineers then built in the driver-hours rules, replayed the three weeks of real days through the tool and fixed a van being double-booked on six of fifteen test days, then added logins, a change history, backups and a security review.
Done by: AI wrote the first draft, our engineers checked, corrected and secured it
-
Launch, then we stay
The tool ran alongside the old spreadsheet for a week. We trained the team, switched over, and included a month of support for the small tweaks that always come up.
Done by: our engineers
Taking an AI-built customer portal live.
A fictional training company that built a booking and invoicing portal with an AI tool. It worked on screen, but they were nervous about letting real customers use it.
- Starting point
- A working prototype built by the owner with an AI tool
- What we did
- App health check, then fixed and finished the essentials
- First call to launch
- About three weeks
-
We listen first
A call and a walk-through of the prototype. We asked who would use it, what data it held, and what would worry them most if it went wrong.
Done by: our engineers
-
We run an app health check and set out the options
A fixed-price review with a plain-English report. It found that anyone with a booking link could see a customer's details without logging in, and that some invoice totals were wrong. We offered three options: fix the essentials, fix everything, or leave it. They chose to fix the essentials first.
Done by: our engineers
-
We agree the price before we start
A fixed price for the essentials, in writing, with a date. The report was theirs to keep either way.
Done by: the client and us, together
-
We fix and finish it
AI helped draft repetitive code and tests for the fixes, and an engineer reviewed all of it. Engineers made the server check logins on every customer record, moved a secret key out of the code, put the pricing rules in one place, and tested invoices against 50 of the client's real ones. They also set up backups and error alerts.
Done by: AI drafted routine parts, our engineers did the security, rules and testing
-
Launch, then we stay
A soft launch with ten friendly customers while we watched for problems, then everyone else. We handed over plain-English documentation and offered a small support plan.
Done by: our engineers
Connecting a shop, stock and accounts.
A fictional online retailer where each order was re-typed between their shop, a stock spreadsheet and their accounts package, so mistakes crept in.
- Starting point
- Three systems that did not talk to each other
- What we built
- An integration that moves each order through once, with alerts when something needs a person
- First call to launch
- About three weeks
-
We listen first
We followed one order from checkout to accounts and counted how many times someone typed it in. The answer was four. We also gathered the awkward cases: refunds, split deliveries and bundled products.
Done by: our engineers
-
We set out the options
Use an off-the-shelf connector app, build a custom link, or combine the two. We were honest that the connector would cover most orders but not their bundles. They chose the combination.
Done by: our engineers, with the client
-
We agree the price before we start
A fixed price for the custom part, the connector's monthly cost set out separately, and a written list of the order types it would handle.
Done by: the client and us, together
-
A working draft in days, then we make it right
AI drafted the first version of the link and a simple dashboard within two days. Our engineers then handled the real-world cases: refunds, split deliveries, bundles, failed connections that retry on their own, and alerts when an order needs attention. We tested it against 200 past orders in a safe copy before it touched anything live.
Done by: AI wrote the first draft, our engineers made it dependable
-
Launch, then we stay
We switched on one product category first, watched it for a week, then everything. A monthly check-in catches anything new, such as a change on the shop's side.
Done by: our engineers
Have a project in mind?
Tell us what you are trying to do, or ask for an app health check if you have already built something with AI.