Why I Build This Way

Some ideas do not leave you alone. They keep showing up as problems, workflows, frustrations, and half-built solutions until you finally give them somewhere to live.

Ideas Need Somewhere to Go

I build things because ideas need somewhere to go.

For a long time, I had ideas for publishing systems, record systems, websites, tools, and practical software I wanted to exist. I understood the problems. I understood the workflows. I understood what frustrated me about the tools already out there. What I did not have was the ability to build all of it from scratch by myself.

AI-assisted development changed that.

That does not mean AI builds everything while I sit back and pretend to be a developer. That is not how this works. I bring the problem, the use case, the pressure, the workflow, the testing, the corrections, and the final standard. I break things. I catch what feels wrong. I push for revisions. I decide whether the result is good enough to keep moving.

The process is not magic. It is repetition, correction, testing, frustration, and improvement.

The projects here are part of the same life as the writing. They come from ownership, structure, portability, real-world use, and the belief that better systems should exist. Some are released. Some are still being built. Some may not belong on this page until they are ready. That is fine. The point is to build useful things, test them honestly, and only put them forward when they have enough shape to stand on their own.

What the Projects Have in Common

The projects on this page are not random side quests.

They come from the same standard that runs through the rest of my work. Own your tools. Own your content. Own your systems. Build things that solve real problems. Keep them usable. Keep them portable where possible. Do not trap people inside tools that make their life harder.

That matters to me because I have spent enough time inside systems that did not fit the people using them. I have seen workflows that looked good on paper but failed in real life. I have used platforms that make content easy to publish but hard to own. I have watched useful ideas die because the tool around them was too heavy, too locked down, too complicated, or too dependent on someone else’s rules.

I do not want to build software that only sounds good in a description.

I want to build tools that can be used, tested, broken, improved, and understood. I want them to respect real workflows, ordinary hosting, practical users, and the fact that not everyone wants to live inside bloated systems controlled by someone else.

That is the standard behind the projects here.

Why These Projects Matter

The current released projects are Bonumark Stream and Carceris.

Bonumark Stream is about owning short-form publishing instead of handing every thought to social media. Carceris is about building a serious record and case-note system shaped by correctional work, practical workflows, and real pressure. They look different on the surface, but they both come from the same place: ownership, structure, portability, and usefulness.

As the work grows, this page can grow with it. I would rather show what has real shape than pad the page with ideas that are not ready yet.

That is why these projects belong on this site. They are not separate from the rest of my work. They are another expression of it. Writing is one way to build something useful. Software is another. A framework gives a person structure for thinking and action. A tool gives a person structure for doing and organizing. Both matter.

The format changes. The standard does not.

Built With AI, Directed By Real Use

I use AI heavily in the development process, and I am direct about that.

There is a difference between lazy AI output and directed AI-assisted development. I am not asking a machine to randomly create software and blindly trusting whatever comes back. I bring the problem, the use case, the pressure, the corrections, the testing, the real-world judgment, and the final standard.

Every project takes revision. Every project gets tested. Every project exposes something that has to be fixed. That is the work.

AI can help generate code, suggest structure, identify issues, and speed up parts of the process, but it does not replace judgment. It does not know whether a workflow feels right to someone who has actually done the job. It does not know whether an interface respects the pressure of a real shift, the habits of a real writer, or the needs of someone trying to organize real human information.

That responsibility stays with me.

If I put my name on something, I have to be willing to test it, correct it, own it, and keep improving it. AI does not remove that responsibility. It increases it.

Where This Is Going

These projects are still growing.

Some may become public GitHub releases. Some may become tools I use personally. Some may become part of future businesses, services, or support offerings. Some may change direction as the work gets clearer.

That is fine.

The point right now is to build useful things, test them honestly, and keep improving.

I have spent a lot of my life talking about standards, structure, proof, and ownership. These projects are another way of living that out. They are not just ideas sitting in a notebook anymore. They are becoming files, interfaces, releases, bugs, fixes, documentation, and systems that can be tested in the real world.

That matters to me.

Build the thing. Test the thing. Fix the thing. Make it useful. Keep going.

The Line These Projects Hold

I am not building these projects to look busy.

I am building them because I want better tools, cleaner systems, and more ownership over the work I create and the problems I care about.

Some of these tools may help other people. Some may only help a smaller group. Some may become bigger than I expect. Some may stay simple. The outcome will become clearer as the work continues.

But the standard is already clear.

  • Build useful things.
  • Own the process.
  • Test honestly.
  • Fix what breaks.
  • Keep the work practical.
  • Do not confuse motion with progress.
  • Do not confuse AI output with finished work.
  • Do not put your name on anything you are not willing to own.

That is the line.


Read Next:


Get the Work
Articles on discipline, recovery, identity, and ownership. Delivered when published.