solution-design

Why the i26g Control Plane does not take its foundation on trust: you give it a bounded environment and boot one VM, and from there it verifies its preconditions and manages everything inside — VMs, networks, and the platform itself — while your infrastructure stays yours.

Why my laptop owns the infrastructure but not the workloads: it bootstraps the foundation, hands day-to-day operations to a Git-driven Application Control Plane, and connects to remote VMs that keep working when the lid is closed.

Comparing isolation and hosting options for development, choosing server-hosted VMs, and defining what each environment can access.

A change-management hypothesis for data and analytics: realistic experimentation in isolated, production-derived environments, validation alongside the latest accepted changes, and a controlled path to production.

A file-first architecture for market analysis: Parquet as the authoritative data layer, DuckDB for SQL queries, and versioned JSON and YAML for application state — plus the consistency boundaries that determine when a catalog like DuckLake becomes worthwhile.

A principle from I Took Self-Hosting Too Far turns out to generalize well beyond infrastructure: own what needs to be durable, control what needs to be portable, rent what is genuinely replaceable. The useful question is not build versus buy or self-hosted versus SaaS, but what relationship a capability actually needs — and since each of the three relationships carries an ongoing cost that only changes shape rather than disappearing, the goal is deliberate sovereignty rather than maximum sovereignty. None of these classifications are permanent either.

A follow-up to Self-Hosting My Repositories and Sites: the repositories and pipelines stay self-hosted, but serving the static output myself added a server to maintain without a matching sovereignty benefit. Wrangler narrows the Cloudflare dependency to a deployment target instead of a development platform.

After building documentation for the Digital Solution Lifecycle Model on Astro Starlight, I realized I wanted to own the presentation layer rather than configure around a theme. Revisiting that decision: keeping Astro as the framework, replacing Starlight with custom CSS, custom Astro components, and selected shadcn primitives where they are the right tool.

Garrul's maintainer corrected three things in my comment system evaluation — a feature I marked as missing that was there all along, a gap since closed, and an operating cost I overstated. It came second, so the corrections land on the closest call in the post.

The follow-up to choosing a host: what it actually takes to run Forgejo per area, wire it to Cloudflare through Wrangler, and serve self-hosted sites behind a CDN using the RAD Stack's ingress layer.

Where should the public parts of my work live — on Codeberg, on GitHub, or on my own infrastructure? Codeberg's new terms exclude projects built with heavy LLM use, which is the honest description of how I work. Taking that objection seriously points at self-hosted Forgejo, and at paying for the load I generate.

A structured look at how releases get numbered — SemVer, CalVer, ZeroVer, rolling integers, marketing names, and commit hashes — what each one actually promises its reader, and why my pre-1.0 ventures are moving to date-based releases with SemVer held back for 1.0.

I rebuilt this site's Makefile in Task to judge the two properly. The trap is stacking the deck against a rotten Makefile — so I brought mine to its best first, then weighed Make against Task, round by round.

Why I added comments, what I evaluated, and why I went with Hyvor Talk — on a static Astro site, DevOps overhead and vendor tracking are both non-starters.

The opinionated stack I've formalized after building the same kind of application too many times ad-hoc — the philosophy, principles, technology choices, the roads not taken, and why. A formalized hypothesis: individual pieces tested in practice, the combination still proving itself.

A structured evaluation of ten documentation platforms — Docusaurus, VitePress, Starlight, Doks, Material for MkDocs, Antora, and more — against requirements for versioned, long-running documentation projects. Covers performance, versioning, search, and ecosystem viability, with scoring tables, a progressive elimination process, and an incremental implementation plan built around Starlight. Starting from the needs of the Digital Solution Lifecycle Model and its companion tooling, but intended as a reusable approach for future projects.

Each of the Ten Views of a digital solution has a natural diagram type and a tool that produces it well. This post maps them one view at a time — using PlantUML, Mermaid, BPMN.io, and DBML, with a consistent running example of a small online bookshop and source included for every diagram. A cross-reference matrix summarises the full mapping at the end.

Most digital solutions are documented partially — the technical parts get captured, the rest is assumed. The Ten Views provide a framework for what complete solution documentation looks like: Current State, Domain, Requirements, Customer, Information, Organizational, Process, System, Interaction, and Operational.

Picture this: You're in a product planning meeting, and someone reads out a user story: 'As a user, I want to receive email notifications so that I stay informed about updates.' Everyone nods. It sounds reasonable. But here's the problem—who actually wants this feature, and why? As an IT architect, I've seen teams build perfectly functional systems that nobody uses because they solved the stated problem instead of the real problem. This is where stakeholder stories become transformative, forcing teams to ask the right question: What outcome are we trying to achieve, and which stakeholders actually care about it?

This strategic guide helps technology leaders navigate the complex landscape of web rendering approaches—from CSR to SSR, SSG, and ISR—with a decision framework that aligns technical choices with business requirements, performance metrics, and SEO considerations to optimize both user experience and operational efficiency.

Enterprises function as systems where intentional design of operating models, interfaces, and feedback loops can dramatically reduce coordination overhead, accelerate decision-making, and create sustainable competitive advantage.