Built to fit

The tool you cannot buy off a shelf.

There is usually one process holding your business together that no product sells: the way you quote, the way you schedule, the thing your customers keep asking to see. It is currently a spreadsheet, three tabs and one person’s memory, and it is the single most expensive thing you own.

Nothing gets built before there is a scope in writing that says what it will not do. “Book a call” opens an email — send us a time that suits and we will confirm it.
ALG / SCOPE DOCUMENT WHAT COMES BEFORE ANY CODE
CUSTOM SOFTWARE · ONE BUILD Written down before any code What it does, what it deliberately does not do, who uses it, what happens when it breaks, and what you own at the end.
SECTIONS01 / 04
STATUSREADY TO BUILD
SCOPEBUILDRUN
01The section that says what it will NOT do is the one that saves the money.THE CODE IS YOURS
01Scoped in writingIncluding the limits. You read it, change it, and only then does anything get built.
02Built in piecesSomething working early, so you are never waiting on a reveal at the end.
03Run afterwardsSoftware is not finished when it launches. Somebody has to keep it alive.
Where the shelf ends

Off-the-shelf is right until it very suddenly is not.

You should buy software wherever buying works — it is cheaper and somebody else maintains it. These are the three places where it stops working, and where a build starts paying for itself.

01

The spreadsheet holding it together

It works, one person understands it, and it breaks the week they are away. It cannot be used by two people at once, there is no history of who changed what, and the version everyone is looking at is not always the same version.

02

Paying per seat for one feature

A large package bought for one thing it does, then a licence for every person who needs to touch it, forever. You are renting ninety features to get the one, and the one is not even quite right.

03

The process the software will not bend to

The tool insists on a step you do not do, or cannot do a step you must. So people work around it — in a notebook, in a group chat, in a second spreadsheet — and now the real process is invisible.

The delivery path

Watch → Scope → Ship → Hand over.

One verb a step, four steps, and you can stop after any of them. Nothing here needs you to commit to the whole thing up front: the first two are worth having on their own, and the document from the second is yours either way.

01

Watch the real week

How the work actually moves, who touches it, where it stalls, and what everybody is already working around. Written from watching rather than from a description, because the described process and the real one are never the same.

02

Scope it, limits included

What it does, who uses it, what it will deliberately not do, roughly how long it takes and what it costs. In writing, so you can take it to anyone — including somebody else to build it.

03

Ship something working, early

Built in pieces you can open and use, so you find out in week two that a screen is wrong rather than in month three. You can say stop the moment it stops being worth it.

04

Hand it over, then support it

The code, the accounts, the database and the documentation are yours. Then monthly support for the things software always needs afterwards — changes, fixes, and the day a tool it talks to changes underneath it.

What we build with

The tools behind it, named.

You are entitled to know what your software is made of before you commission it, so here it is, with what each piece actually does.

01

Python

The voice agent itself, and the language handling around it.

02

Node.js

The sites, the build tools, and the checks that run before anything ships.

03

PostgreSQL

One database under leads, calls, bookings and customers.

04

Git

Every change to your site or your system recorded, and reversible.

05

Playwright

A real browser drives every page and every screen before you see it.

06

Google Calendar API

Real availability read before a time is offered; the booking written back.

07

Stripe

Subscriptions, invoices and receipts, when taking money is part of the build.

08

Hand-written HTML, CSS and JavaScript

No page builder and no theme, so nothing you own needs a plugin licence.

These are named because we use them, not because any of them is a partner of ours or endorses us. If a job needs something that is not on this list, we will say so on the call rather than bend the job to fit the list.
What we can show you

The only software we can show you is our own.

We are not going to put a portfolio of somebody else’s work on this page, or write a case study for a project we did not do. So here is the honest version of what exists.

We built the platform we run, and we run it.

A voice agent that answers live calls, a chatbot that answers in writing, a dashboard where every call and chat is written up, and the flow that sets a new line up from scratch. All of it built here, and all of it running.That is ours, not a customer’s. It is offered as evidence that we can build and operate software, and as nothing more than that — there is no client project behind it and this page will not pretend otherwise.
OURS, NOT A CUSTOMER’SRUNNING DAILYBUILT HERE
  • The source code is yours from the first day, not at the end.
  • Accounts, hosting and the database are in your name.
  • Written down as it is built, so somebody else could pick it up.
  • Driven in a real browser before you see it — tested, not hoped.
  • Every change recorded and reversible.
  • Monthly support afterwards, no contract, and you can stop.
  • If something on the shelf would do it, we tell you to buy that instead.
  • If we do not know how long a thing will take, we say so rather than guess.
  • No portfolio of client work, because there is none we can show you.
The last three lines are the ones that cost us work. We would rather lose a job we should not have taken than write a scope we cannot hold.
How we define progress

What gets counted, and what you end up holding.

A build is the easiest thing on this site to report on dishonestly, because “eighty per cent done” is a number nobody can check. So progress here is something you opened and used, and a scope you can hold us to.

What gets counted
  • Pieces delivered. Each one a thing you can open and use — that is what counts as progress, not a percentage on a plan.
  • What is still deliberately out of scope. The list of what it will not do, kept current as the build goes, so the line cannot quietly move.
  • Every change, recorded and reversible. What changed, when, and how to put it back.
  • What was checked before you saw it. Driven in a real browser — tested, not hoped.
  • What we could not estimate. Anything we do not know the length of is written down as unknown rather than given a number that sounds better.
What you end up holding
  • The scope document. What it does, who uses it, what it deliberately does not do and roughly how long — yours whether or not we build it, and you can take it to somebody else.
  • The source code. Yours from the first day, not at the end.
  • The accounts, the hosting and the database. In your name.
  • The documentation. Written as it was built, so somebody else could pick it up without ringing us.
There is no delivery percentage in that first column and no client project behind this page — the only software we can show you is our own, which the section above says outright. What you can hold us to is the scope, and the part of it worth reading twice is the part that says what it will not do.

Bring us the spreadsheet everything depends on.