A Developer Used AI to Build a Custom Sleep Disruption Tracker

The project is a practical case study in AI-assisted tool building: one person, one problem, no pre-existing codebase, and an LLM doing the bulk of the implementation work.

The author identified a concrete personal problem — unexplained sleep disruptions — and used it as a vehicle to test how far an AI coding assistant could carry a real project from prompt to working software. The result is a custom tool that logs and correlates potential disturbance sources, likely pulling from environmental inputs or manual logging, to help identify patterns over time.

What matters here is not the sleep problem. It is the workflow. The author treated the AI as the primary implementer, not a code-completion assistant. That distinction is increasingly relevant for solo founders and small teams deciding how to scope what they can build without hiring.

The approach reflects a pattern that has become more viable as context windows have grown and code-generation quality has improved. A developer with domain knowledge of their own problem and enough skill to evaluate output — but limited time — can now ship functional internal tooling faster than the traditional build-or-buy calculation suggests.

There are real limits here. AI-built tooling tends to accumulate structural debt quickly when the human is not closely reviewing architecture decisions. For a personal diagnostic tool with low stakes, that tradeoff is acceptable. For anything touching production systems or user data, the same workflow needs tighter review loops.

The broader implication for builders: the bar for building a custom tool versus adopting an off-the-shelf solution has shifted. Niche personal or internal tools that would previously have taken a weekend or more to build now take hours. That changes what is worth building from scratch versus what gets handed to a vendor.

The original write-up at martin.sh documents the process in detail for those evaluating similar workflows.

Source