We have tried building internal tools three times. The first two died before anyone used them. The third one shipped and is still running, which qualifies it as a success by our standards.
The difference was not motivation or technical difficulty. It was a change in how we treated the project's relationship to client work — which we had previously been getting wrong in a consistent way.
How the first two died
The pattern was the same each time. We had an idea for something useful — a small tool for tracking project scope changes, a template system for proposals — and we started building it in the spaces between client deadlines. Evenings, slow Fridays, the occasional Saturday morning.
What happened is predictable: a client project needed more time, the internal tool sessions got cancelled, and three weeks later neither of us could remember exactly where we had left it. Restarting required re-reading code and reconnecting with what we had been thinking, which takes longer than it sounds when the context has fully evaporated. By the second restart, the thing felt like a burden rather than an opportunity. We stopped.
The change that worked
For the third attempt — a lightweight brief-to-scope calculator we actually use now — we made two decisions that were different from before.
The first was time-boxing with a hard constraint. We allocated Friday afternoons, 90 minutes, protected from client work by treating them on the calendar as equivalent to a client commitment. Not "if there is time" — actually blocked. The 90-minute limit mattered more than we expected. Knowing the session would end made it easier to start without feeling like we were opening a bottomless task.
The second was writing the README before any code. Not a full specification — just a short paragraph describing what the tool does, who uses it, and what success looks like. We did this in the first session and did not touch it again. But having it meant that after a week away from the project, we could read three sentences and be back in context within two minutes instead of twenty.
What time-boxing actually changes
The useful thing about a hard time limit is that it forces scoping decisions that would otherwise drift. When you only have 90 minutes, you cannot spend 45 of them discussing whether the thing should also do something else. The constraint makes the current feature feel more important and the future features feel less urgent.
We found ourselves shipping smaller, more functional increments than we had planned. The tool has fewer features than the original idea suggested. It also exists and works, which the original idea does not.
One rule that helped
At the end of each session, one of us wrote a single sentence describing where the project stood and what the next concrete step was. Not in a task tracker — just appended to the README. This took about two minutes and was the single highest-return habit we established around the project. When we came back the following week, the last sentence told us where to start without any of the overhead of reconstructing what we had been thinking.
The README at the end of the project was about 400 words of context that we had added in 20 weekly two-minute increments. It is the most useful internal documentation we have written.