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 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. 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. 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 the phone is the only hardware
A product that needs a device mounted at every location has already priced itself out of the businesses we build for. Whatever we ship has to work on a five-year-old Android phone on a patchy connection.
- 04
price it so the smallest user pays nothing
A five-person team gets AttendFirst free, permanently. Not a trial. If the product is only worth building for companies that 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. The honest answer is no, and it won't. Those companies go and buy a suite, which is the right call for them.
What we get in exchange is a product that a manager can understand on the first morning and that costs a small business roughly what it spends on tea. 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.