Built, shipped, running.
Two systems in production, and the one you are reading. Below is what each actually does — the mechanisms, not the adjectives. There are no percentages on this page, because none of them has run long enough to produce a number we could defend if you asked how we got it.
01Own product
ShotBot
A ball machine is hardware. The business around it is software.
The problem
A padel ball machine hired by the hour at a club in Corsham. The machine was the easy part. Taking a booking for a specific hour, taking the money up front, making sure two people cannot book the same hour, and telling the customer the six things they need to do that the booking alone does not arrange — that is the actual product.
What was built
Booking engine, built from scratch
Availability worked out live, hour by hour, with the bookable window calculated properly rather than assumed — including the awkward parts most systems get wrong, like which hours are genuinely still open once today has started.
Double-booking made impossible, not unlikely
A partial unique index on the active slot key means the database itself rejects the second booking. It is not a check that runs before the write and hopes — it is a constraint the write cannot get past. A cancelled booking releases its slot, which sounds obvious and was a real bug, found and fixed on 31 August 2026.
A test that runs the real migrations
The slot-availability test applies every migration in order against a scratch database and then asserts the behaviour. It encodes the cancellation bug so it cannot come back. Most booking widgets get this wrong and you find out when two customers turn up at once.
Payment at the point of booking
Payment captured through Stripe, so card data never touches the application and there is nothing there to leak — customers hand their card details to the same processor they already trust on far bigger sites. Taking the money at the point of booking removes the no-show problem before it starts.
Confirmations that are not allowed to fail quietly
Transactional email, with the owner notification and the customer confirmation on separate delivery paths so a failure in one cannot silently swallow the other. The trade-off is deliberate: a rare duplicate beats a silent miss, because a customer who hears nothing has no way of knowing where to collect the machine.
Terms enforced server-side, and recorded per booking
Consent validated server-side in the checkout route, not merely ticked in the browser, with the accepted terms version persisted against the booking. Cancellation policy written against the actual regulations, with the exemption cited rather than implied.
Every step counted, on our own product first
The whole journey is measured — how many people arrived, how many opened the booking page, how many started, how many paid, and exactly where the rest gave up. We did not build this for a client and then try it on ourselves.
What this is in another trade
Strip out the padel and this is any business selling a slot: a garage booking MOT bays, a studio booking rooms, a hire firm booking kit that can only be in one place at a time. The hard parts — availability, taking the money up front, and two people never getting the same slot — are identical.
Where it stands
Live and taking bookings. Volumes are small and honest reporting of them is a few months away, so there are no percentages on this page.
02Client build
Easy Bite Nutrition
They did not lose customers on the food. They lost them on everything around it.
The problem
Orders over WhatsApp. Dietary requirements on a whiteboard. Prep sheets rewritten by hand every week. Customer details in a phone. It works while you are small and it breaks the week you get busy, which is the week you can least afford it to.
What was built
Ordering, subscriptions and one-off weeks
Weekly menu with full macros and allergens on every dish. Two plan sizes. A meal picker that enforces the right count so an order cannot arrive short.
A prep sheet the kitchen actually uses
Generated automatically: cook counts per dish, the delivery run sorted by postcode, allergy flags in red, print-friendly. No transcription, no rewriting, no misread handwriting.
Allergen data treated as health data
The fourteen FSA allergens held per dish, per customer, access controlled, and accurate at the point the food is made. Get this wrong and it is not a paperwork problem, it is a hospital problem and a legal one.
Customer self-service, with no login
A signed link lets a subscriber skip a week, change plan, change meals or cancel. No password to forget, no DM for the owner to answer at ten at night.
Live delivery-area check
An out-of-area postcode is offered collection instead of failing silently, so the order is kept rather than lost at the last step.
QR codes on the product
A container becomes a touchpoint after the sale, which is exactly when most food businesses go quiet.
The owner’s dashboard
Orders, portions to cook, revenue, active subscribers, deliveries. Customer list with lifetime spend and weekly recurring revenue. Prices, cutoff and delivery area editable without a developer.
The week runs itself
Scheduled jobs lock the week at cutoff, bill the subscribers and email the kitchen its prep list, then open the next menu the following morning.
What this is in another trade
Strip out the food and this is any business with a back office: job cards for a garage, treatment notes for a clinic, run sheets for an installer. The pattern is the same everywhere — the thing you cannot afford to get wrong is on a whiteboard, and the sheet your team works from gets rewritten by hand every week.
Where it stands
Built and deployed. Payments and outbound email are switched off by design until the client is ready to trade on it — orders record, confirm and reach the prep sheet regardless.
03This site
Archline Digital Systems
The site you are reading is the argument.
The problem
An agency that sells measurement while running none of its own is asking to be taken on trust. Everything claimed on these pages is either demonstrated by the page itself or it is not claimed. That constraint decided most of the technical choices below.
What was built
No third-party scripts, so no consent banner
The site sets no cookies and loads no trackers, which is why it needs no cookie notice and no privacy theatre. It is a deliberate demonstration: most sites carry a banner because of decisions nobody revisited, not because the law forced one.
A honeypot instead of a CAPTCHA
Bots fill a field a person never sees, and are shown the success page rather than an error — tell a bot it failed and it simply retries. It costs nothing, it sends no data about the visitor to anyone, and it does not make real people prove they are human.
Attribution applied to its own links
Campaign tags are captured at the point of enquiry rather than on arrival, so there is no first-touch cookie and therefore no banner. If the pitch is that you should know which post produced the booking, the site has to be able to say which post produced you.
Launch conditions enforced in code, not in a checklist
Two commercial preconditions — an employment-contract question, and a client’s written permission to be named — were wired as flags that physically prevented publication and anonymised a case study until they were cleared. A note in a document gets forgotten. A refusal does not.
Content readable with JavaScript disabled
Scroll reveals are applied only once the browser confirms it can deliver them, with timed sweeps as a fallback. An earlier version hid content by default and rendered a blank page whenever the observer failed to fire — on a page whose only job is to be read, invisible content is the worst available bug.
One file holds every price and claim
A price rise is a single edit, and every assertion on the site can be checked against one list rather than hunted through markup. Three claims in the original copy did not survive being checked against the code they described, and were corrected before launch rather than after a client asked.
Server-rendered, no framework, no build step
Pages arrive as finished HTML. Nothing to hydrate, nothing to wait for, and nothing that stops working in eighteen months because a dependency moved on.
What this is in another trade
This is the Foundation build with the enquiry capture and measurement turned on, which is exactly what most businesses need before they need anything bigger. If you want to know what that tier feels like, you are looking at it.
Where it stands
Built, tested and ready to deploy. Not yet live — the domain is registered and the site published as the last step, so this entry describes running code rather than a plan.
→Start
Tell me what breaks when you get busy.
The first step is a £450 Diagnostic: half a day walking your process end to end, and a written recommendation with a fixed quote attached — whether or not you build anything with us. It is credited in full against a build if you go ahead within thirty days.