Five stages, and nothing skips one.
It is a slow way to fill a register. It is also the reason the one product on ours can be signed in a kitchen without anybody arguing about it.
- Stage 01 · Complaint
- A specification starts as a problem somebody in one of our venues will not stop having. Nothing starts from a competitor's feature list. The first requirement document is usually a conversation in a corridor, and the first user is the person who was complaining.
- Stage 02 · Prototype
- Something clickable within weeks, in the hands of the person who complained, deliberately unfinished. Most of what gets drawn here is thrown away, and this is the cheapest place in the whole process to throw anything away. A prototype everyone likes and nobody uses has failed cheaply.
- Stage 03 · Pilot
- One real operator, real jobs, real invoices, no marketing and no price list. The pilot runs until it has been through a full month-end, because that is the week when software that looked fine on a Tuesday turns out to be missing a column. If it does not survive, it goes back to stage two rather than forward to a launch date.
- Stage 04 · Production
- EU hosting, backups, monitoring, versioned releases, and every platform standard applied without exception. Only at this point does the product get a price, a trial and a site of its own. A row on the register moves to Live here, and not one day earlier.
- Stage 05 · Kept
- Shipping does not end at launch. Products keep changing every month, and versioning is what stops those changes from rewriting anything a customer has already signed. A product we would not commit to maintaining for years is a product we should not have started.
How the work actually runs.
We are a small house, and being small only works if the discipline is real. These are the working rules.
One platform team, several products
Offline sync, signatures, exports, roles and document versioning are built once and shared. Product teams work on the part of the problem that is genuinely their own.
Small releases, often
Changes go out in versioned releases with a record of what changed. Big-bang launches hide their mistakes until the worst possible week.
Nothing ships untested against real data
A staging environment with realistic data stands between a change and a customer's month-end. Demo data does not find the bugs that a year of real records finds.
The people who build it answer the phone
Support is not a separate department reading a script. It is the fastest feedback loop we have, and we are not giving it away.
Reviewed in the venue
Screens are reviewed where they will be used — in a kitchen, on a phone, with wet hands and bad light — before they are reviewed on a designer's monitor.
We say no to the roadmap often
Every product on the register could be twice the size. Most requests are answered with a reason rather than a ticket, and the register moves slowly on purpose.
What we will not do.
These are the things we turn down, and they are the reason some enquiries end with us recommending somebody else.
- Bespoke projects. We build products with many customers, not one-off systems for one. A feature has to make sense for the tenth operator, not just the first.
- Continuous staff tracking. Location is stamped at the start and end of a job. Watching people all day is a different product and a different company.
- Selling data. Customer and guest data belongs to the customer. It is not aggregated, resold or turned into a benchmark product.
- Launch dates for things that are not built. A date on an unbuilt product is a promise made with somebody else's money.
Have a problem worth stage one?
The most useful thing an operator can send us is a description of the afternoon that keeps going wrong. That is where every row on the register came from.