The Challenge
At the end of last year, I set a goal to create something meaningful every month for a year.
I call it Ship Monthly Challenge. The name is cleaner than the execution. Some months have produced more than one project. A few planned projects were deferred or dropped. The honest version is that I ship a personal project most months.
The point is not a perfect streak. It is to turn ideas into things that work.
I have never had a shortage of ideas. My problem is that I can spend too long planning them, designing the architecture, or building tools that would make the eventual project easier. All of that feels productive. Sometimes it is. It can also keep the actual product safely out of reach.
The challenge gives the work a deadline and a test: did I make something real?
What Meaningful Means
I did not want twelve demos built only to satisfy the calendar. A project has to solve a problem, teach me something I care about, or create something another person can use.
That leaves room for very different kinds of work. A brewing analytics tool can be meaningful because it helps me understand a hobby I have practiced for years. An open-source life insurance platform can be meaningful because it tests ideas about transparency in an industry I know well. A family cookbook can be meaningful because preserving family recipes matters even if it never has a market.
Meaningful does not have to mean large. That is part of the discipline. A narrow project that works has more value than an ambitious system that exists only as a plan.
What I Have Built
The projects have covered more ground than I expected.
2026
- January — BrewCodex, a brewing dataset and tools for experiments, recipe decisions, and analytics.
- February — This personal site, combining my profile, writing, and projects.
- March — SpikeForge, an executive and professional coaching platform.
- April — OpenLife Platform, an open-source platform for managing life insurance policies, documents, beneficiaries, and claims.
- May — Melopa, a leadership development platform.
- June — iFoundry, a site for a partner build firm that helps teams shape and ship new products, platforms, internal systems, and ventures.
- July — A rebuilt family cookbook; a personal second brain for AI agents; a biographer agent; and a personal data platform and annual report.
The annual report had been on my backlog for years. I wanted to build something inspired by Nicholas Felton's personal annual reports and the quantified-self movement, but the integration work always outweighed the time I could justify. The monthly challenge gave it a slot. AI made the slot usable.
What AI Changed
This pace would not have been practical for me a few years ago.
AI shortens the distance between an idea and a working first version. I use it to research unfamiliar areas, challenge an architecture, write and test code, revise a design, and keep context across many small decisions. That does not remove the work. It changes which work consumes my time.
I can spend more time deciding what the project should do and less time on mechanical implementation. I can also enter domains that would once have required weeks of setup before I could test the first assumption.
There is a risk in that speed. When building gets cheaper, starting gets easier. AI can help finish a project, but it can also help create five new ones before the first has reached anyone. The tool does not supply focus.
The Pattern I Have to Watch
I like architecture. Given a problem, my instinct is often to build a system for solving the whole class of problems.
That instinct has produced useful foundations. It also creates a reliable form of productive procrastination. I can build frameworks, schemas, skills, and platforms while the thing a person would actually use remains unfinished.
The annual-report project exposed this clearly. It began as one report and expanded into a reusable personal data platform. The expansion proved useful when the same data supported a separate Japan travel log, but only after I brought the report itself across the finish line.
That distinction matters. Architecture is not the product. The product is what someone can use, read, or keep.
A Better Measure Than the Calendar
The monthly cadence helps, but completion is not the same as impact. I need a harder check:
Did anything I built get in front of a real user?
Not designed. Not scaffolded. Not described in a repository. Used.
For some projects, I am the user. That still counts when the project solves a real problem and changes how I work. For others, the standard is external: someone visited the site, tried the tool, read the report, or gave feedback that changed the next version.
This keeps the challenge from becoming a portfolio of polished beginnings.
What I Am Learning
The range is deliberate. Brewing, career data, coaching, insurance, personal knowledge, and quantified-self projects force me to learn different domains and forms of delivery. The common thread is not the technology. It is the practice of taking an idea far enough to discover what was wrong about it.
Shipping creates evidence. It shows whether the problem was real, whether the scope was sensible, and whether the architecture helped or merely entertained me. Planning cannot answer those questions.
I am also learning that a monthly goal needs flexibility. A project can fail because an API disappears. A more important idea can arrive halfway through the month. Some projects need another cycle. The schedule should create pressure, not fiction.
So I will keep calling it the Ship Monthly Challenge, and I will keep describing the outcome more carefully: I ship something meaningful most months.
That is enough pressure to move ideas forward and enough honesty to learn from what actually happened.