Notes
Building small apps around real problems
My process for turning an irritating task into a small useful tool, then improving it by using it myself.
Start with the annoying part
Most of my projects start with something irritating: repetitive work, scattered information, or a tool that takes five steps when two would do. I do not need that problem to sound impressive. I need to be able to describe what gets in the way and what would be different if the tool worked a little better.
That is the thread connecting my work in IT, automation and apps. The output might be a small utility or an Apple-platform app, but the starting point is similar. Something asks for more attention than it should. Before thinking about a feature list, I try to name that specific bit of unnecessary work.
Build the simplest useful version
I prefer a first version with a job I can finish describing in a sentence. Not because everything should stay tiny forever, but because it is easier to tell whether a small tool actually does its job. A long list of possible additions can make progress feel concrete before the central problem has been solved.
Simple does not mean deliberately awkward or incomplete in the middle of a task. The useful part matters. If I remove a step but leave myself guessing what happened, I have only moved the work somewhere else. I want the shortest complete path I can make, with enough explanation to use it without remembering my own implementation decisions.
Use it before expanding it
My preferred next step is to use that version myself. Not as proof that it will suit everyone, but as a way to notice details that were easy to ignore while building. A repeated choice, an unclear label or a piece of information that is hard to find becomes more obvious when I am trying to get something done.
I try to pay attention to the moments when I work around my own tool. If I keep doing something outside it, I want to understand why before adding another screen. Sometimes a better default or a clearer action is more useful than a new feature. Sometimes the original idea needs to become smaller, not larger.
Improve what gets in the way
The loop I like is straightforward: identify the annoying part, build a useful version, use it, notice the remaining obstacles, and improve it. That is a working habit, not a rule that every project has to follow perfectly. It gives me a reason for the next change beyond simply wanting the project to look busy.
SymptomTap puts that thinking into a short interaction: recording a symptom without turning it into a long journal entry. Medication Cabinet starts from another small problem, keeping medication information together and easy to find. Its scope is organization, not treatment or dosage advice. Keeping the purpose specific also helps me keep the boundary specific.
Let the work stay personal
Some ideas belong in experiments rather than a finished product. I want room to try a native interface, automate a repetitive task or build a small utility without pretending each one is a major launch. An experiment can answer a question even when it never becomes a public app with a name and a product page.
Michael Software is where I share the parts of that work that can be public. I want the site to show what I am building and why, without turning a personal process into business advice. Small software is enough when it solves the part that was annoying. That is the kind of progress I want these notes to describe.