focus is most of the work
Any product can be made bigger. Keeping one small enough that a shop owner can set it up between customers, or a developer can drive without reading a manual, takes a set of rules you hold to even when a bigger product would sell more. These are ours.
- 01
start from the thing that keeps breaking
For attendance, the broken thing was a register on a desk, a machine nobody wanted to maintain, and an argument every month-end about half-days. For bookings, it was a phone ringing during an appointment and a diary nobody else could read. For GitMeridian, it was reading a paragraph an agent reworded as a wall of red and green. Each product starts from a problem like that, and a feature matrix comes much later, if at all.
- 02
pick one job and do it completely
AttendFirst covers attendance and leave, from the first check-in to the month-end report. BookingDeskPro covers the appointment, from the booking to the reminder to the reschedule. GitMeridian covers the path from reading a change to committing it. Settling the job before the first line of code is what keeps a product understandable two years later.
- 03
assume they already own the hardware
A product that needs a device mounted at every location has already priced itself out of the businesses we build for. AttendFirst has to work on a five-year-old Android phone on a patchy connection. BookingDeskPro has to work for a customer booking from that same phone. GitMeridian has to open on the Mac that's already on the desk. Nothing else gets bought, mounted or wired in first.
- 04
price it against the thing it replaces
The smallest teams get AttendFirst free, permanently, and not as a trial. A business with one calendar books appointments on BookingDeskPro for nothing. GitMeridian is one payment rather than a subscription that outlives your interest in it. If a product is only worth building for people who can afford enterprise seats, someone else should build it.
- 05
ship it, then live with it
We run what we build. Support goes to the people who wrote the code, which is uncomfortable in exactly the way that improves a product.
the trade-off
A focused product is faster to learn.
Every hour that would go into an adjacent module goes into the one job instead: a faster check-in, a clearer reminder, a diff that reads like the document it changed. Businesses that need a full suite are better served by one, and we tell them so.
What we get in exchange is a product a manager can understand on the first morning, at a price a small business spends on tea, and one a developer can drive on day one without learning it. That trade is the whole business.
sound like the right approach?
We're always interested in the small, annoying, expensive problems that nobody has built a proper tool for.