Operating principles
Ten rules that decide what we build, what we refuse and how we write about it.
- 01
Build for one industry at a time
A system shaped around a specific industry beats a general tool that has to be configured into shape. We would rather serve one industry properly than four badly.
- 02
Ship products, not promises
A vertical only becomes a product when it works, has a demo, has pricing and can be supported. Until then it is research, and we say so.
- 03
Say what is not included
Scope boundaries are written down before work starts. Excluded work is stated as plainly as included work.
- 04
Own the operation, not just the software
Deploying software is the easy half. We take responsibility for the system continuing to work after activation.
- 05
One source of truth
Prices, plan contents and terms live in one place and are referenced everywhere else. Two versions of the same fact is a defect.
- 06
No claims we cannot support
No invented statistics, no fabricated case studies, no client logos we do not have. If we cannot evidence it, we do not print it.
- 07
Make the commercial model legible
What you pay, what varies with usage and what is scoped separately should be understandable before you commit.
- 08
Refuse bad fits
A business we cannot serve well is not a customer worth signing. Turning work away is cheaper than failing at it.
- 09
Design for the person on shift
The daily user is usually not the buyer. If the system is annoying at 9am on a busy day, it will not be used properly.
- 10
Improve the product, not the exception
When something is wrong for one customer, we ask whether it is wrong for all of them. Fixes go into the product wherever they can.
These principles are visible in the product
The clearest test is the system that is live today.