saying no 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're willing to lose revenue over. These are ours.
- 01
start from the thing that keeps breaking
Attendance wasn't a gap in someone's HR suite. It was a register on a desk, a machine nobody wanted to maintain, and an argument at the end of every month about half-days. Meridian wasn't a gap in Git. It was reading a paragraph an agent reworded as a wall of red and green. We build from the argument, not from a feature matrix.
- 02
decide early what the product will never do
AttendFirst won't calculate salaries or run payroll. Meridian won't turn into an editor. Writing that down before the first line of code is what keeps a product understandable two years later. Every yes to an adjacent feature costs the product some of its point.
- 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. Meridian 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
A five-person team gets AttendFirst free, permanently, and not as a trial. Meridian 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
This costs us deals, and that's the point.
Every few weeks someone asks whether AttendFirst can also run payroll, or whether Meridian will add interactive rebase and an editor. The honest answer is no, and it won't. Those people go and buy a suite, which is the right call for them.
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.