In late July, I rebuilt my personal website several times in a few days.
The first version was static HTML and CSS. Then I changed the layout, changed the visual direction, changed the colours, adjusted the calls to action, and eventually converted the whole thing to Hugo. A week later I moved my old technology blog into it, renamed the writing section to Blog, added search, and started removing most of what I had just migrated.
From the outside, that sequence probably looks inefficient.
It was.
It was also one of the more accurate summaries of my year so far: build something, put it in front of reality, notice what it is actually saying, and decide whether to improve it, keep it, or let it go.
The visible result is a website. The more important result is that I am clearer about the kind of work I want attached to my name.
The thing that made the year real
The largest thing I shipped this year was Magpie Inventory & Stock, a native iOS inventory platform for small businesses.
I conceived it, designed it, built it in SwiftUI with Core Data and CloudKit, created the brand, prepared the App Store presence, launched it, and continue to own the support and roadmap. There was no hand-off between the product idea, the database, the interface, the release, and the person answering questions after it went live.
That is the part I wanted.
I have spent most of my career building substantial systems with teams: public-sector applications, pricing software, mobile field tools, cloud platforms, and regulated gaming products. I still do that work. It has taught me how much care production software deserves and how expensive vague ownership becomes.
Magpie gave me a different test. Could I still take one useful idea from a blank page to the App Store while owning every decision in between?
Shipping it was a success. Not because launching an app settles whether the product will become a business. It does not. A live product still needs customers, support, positioning, maintenance, and many small decisions that are less satisfying than writing the first version.
The success was closing the entire loop. The thing moved from an idea in my head to software another person can download and use. After twenty years, that still feels like the most honest measure of whether I built something.
The other things did not disappear
Magpie was not the only product competing for attention.
Bookend grew from production-management and networking problems in theatre, film, and live entertainment. CleanCheck is still an in-development attempt to make recurring cleaning, inspection, and maintenance work easier to see and verify. spec.social is a small, browser-based utility for previewing how images and video will be cropped across social platforms. Bunker41 is where I take on independent software and product work for other people.
These projects are different sizes and at different stages. Putting them together on the new site forced me to describe each one as it actually is instead of presenting every build as if it had reached the same destination.
That distinction matters. Working software is not automatically a finished product. A finished product is not automatically a viable business. A useful experiment does not become a failure because it stays small.
I have been guilty of treating every idea as though enough engineering could turn it into the thing I first imagined. Engineering can make an idea real. It cannot make people need it, find it, understand it, or pay for it.
This year has made me more willing to separate those questions.
I had more articles than I had a point of view
The blog was a similar correction.
I had years of posts under Jay’s Tech Bites: tutorials, framework opinions, predictions, explainers, and the kind of articles that make sense when the goal is to publish consistently. There was a lot of material. There was much less I wanted to carry forward unchanged.
So I moved the archive into my personal site and then unpublished most of it.
I kept the pieces that came from work I had actually done or opinions I could still defend. I rewrote others around the consequences behind the technical advice. I used The delete that didn’t happen—a story about nearly erasing twelve thousand records in my first year—as the standard for the voice going forward.
That article works because it belongs to me. The incident happened. My reaction was not polished. The rule I took from it changed over time. Somebody else could write about soft deletion, but they could not write that piece.
The failure was not that the older articles were all bad. Some were useful. The failure was assuming that publishing more often would eventually produce a clearer body of work on its own.
It did not. Curation did.
The blog is smaller now. It is also much closer to what I believe good technical writing should be: specific, earned, willing to admit where the first rule stops working, and written by a person rather than a content schedule.
AI made the judgment more visible
I used AI-assisted workflows throughout this work: while developing and iterating on Magpie, rebuilding the site, moving content into Hugo, shaping the search experience, creating article imagery, and revising drafts.
It made many parts faster. It did not make the important decisions disappear.
In fact, speed made them harder to avoid.
When a tool can produce five plausible directions quickly, the limiting factor is no longer whether I can make something. It is whether I can tell which version is honest, useful, maintainable, and worth keeping. A weak idea can now become polished software or fluent prose before it has earned either.
That is why I built a writing process around a canonical article and an explicit voice guide. The machinery can help me draft, compare, revise, package, and publish. It cannot decide what happened to me, which opinions are mine, or what I am prepared to put my name on.
The same boundary applies to software. AI can accelerate implementation, but the person shipping the product still owns the architecture, the failure modes, the privacy decisions, the support burden, and what happens when the generated answer is confidently wrong.
The growth for me has not been learning how to produce more with AI. It has been becoming more deliberate about what I let production speed hide.
The failures were mostly ordinary
Nothing in this story failed spectacularly.
The website did not go down in flames. It simply took several versions before it said what I meant. The old blog was not worthless. It was too large and too generic to represent where my thinking had moved. The unfinished products did not prove I should stop building. They proved that code is only one part of bringing a product into the world.
These are ordinary failures, which makes them easy to miss. They look like completed work. The cost is time spent polishing the wrong version, maintaining something without a clear reason, or confusing activity with progress.
I am better at noticing that now, although I am not cured of it. I still like making things. A blank project, a difficult workflow, or an awkward interface can pull me in before the business case has finished its sentence.
The difference is that I am more willing to ask what the build is for—and more willing to stop when the answer is not good enough.
Why I continue
I continue to build because software is still the best way I know to turn judgment into something testable.
It is easy to have opinions about simplicity, product design, maintainability, or what users need. A working product exposes whether those opinions survive contact with a real screen, real data, an App Store review, a support question, and the months after launch.
I also still want to hold the whole problem.
I want to understand the database and the interface, the architecture and the wording, the release process and the reason the feature exists. That does not mean every product should be built by one person. It means I do my best work when I can see how the decisions connect and stay close enough to the outcome to learn when I was wrong.
So far, 2026 has given me a live iOS product, several other projects in honest stages, a rebuilt home for my work, a smaller blog, and a better filter for what belongs in all of them.
That is not a clean story of success. I would trust it less if it were.
It is a year of shipping, revising, removing, and continuing. After twenty years, I am still opening the blank page. I am just more careful now about what deserves to remain on it.