Build the tool you need yourself, once

In January I built the tool that handles turnover for the short term rentals I run. Cleaning schedules, what each booking owes, which nights are empty, what the month made after the platform takes its cut. A hundred and twenty commits in a month.

It has one user. That turned out to be the most useful constraint I have worked under, and I would now recommend to any engineer that they do this once, deliberately, with a real problem of their own.

Here is what it teaches that a client project cannot.

You cannot sell yourself the demo

Every product I have built for someone else has a gap between what I believe about it and what is true. I close that gap with interviews, feedback and metrics, all of which are indirect. People are polite. Metrics measure what you chose to measure.

Here there is no gap. If the reconciliation is wrong, the numbers do not match the bank. If a screen takes four taps where it should take one, I feel it on a Sunday evening when I want to be doing something else.

It is the only software I have written where I know, without arguing, whether it is any good.

Three things it showed me about everything else I build

I build for the happy path and then live somewhere else. A real month is not a clean sequence of bookings. It is a cancellation after the cleaner was paid, a guest who changes dates twice, a payout that arrives for a stay that has not happened. In client work I would have called those edge cases and scheduled them for later. Here they are Tuesday.

I under build the boring view and over build the clever one. I had a lovely revenue breakdown by property before I had a reliable answer to "is the flat ready for tomorrow". The second question is the one I ask every single day. The first one I have looked at maybe four times.

Setup cost is invisible until you pay it. This thing needs its data kept current, and keeping it current is work. Every product I have shipped assumed someone would happily do the equivalent, and I have no evidence that any of them did.

That third one changed how I scope. The first screen I build now is whatever keeps the data true, not whatever shows it off.

How to pick the problem

It has to be something you do repeatedly and resent. Resentment is the signal, because it means you have been paying the cost long enough to know its shape.

It has to involve money or time that is actually yours. Stakes are what make your judgement honest.

And it has to be small enough to finish in a month. The point is the full loop, building and then living with it, and you only get the second half if you reach it.

What you come out with

Not a business, probably. A list of about six habits you did not know you had, discovered in the one place where nobody was grading you and nobody could be blamed.

I carry that list into every client project now. It is worth more than the tool.