I do not have a grand theory of software.

I mostly have scars, preferences, and a growing list of patterns I trust more than others.

This page is the closest thing to a map of how I think about systems.

The demo is not the system

A demo shows the happy path. The real system starts after that.

It starts when the source file changes without warning. When the business rule has an exception. When the person who understood the logic leaves. When the AI gives a confident answer that is almost right. When the dashboard number does not match finance. When the retry creates duplicates. When the router randomly drops. When the SD card dies. When the “temporary fix” becomes architecture.

That is where most of the actual engineering lives.

I am more interested in that layer than the demo.

Keep the core deterministic

AI is useful. Very useful.

But I do not want important systems to become vibes all the way down.

For most real workflows, I prefer this split:

AI can read, summarize, classify, compare, suggest, explain, and draft. The system should still validate, check, execute, log, reject, and recover through deterministic rules.

That does not make the system less intelligent. It makes it safer.

The best AI systems are not the ones where the model does everything. They are the ones where the model is placed carefully inside a workflow that knows how to contain it.

Small tools should stay small

Not every tool needs to become a platform.

A lot of useful software should do one painful thing well, accept files, produce outputs, explain what changed, and get out of the way.

The moment a tool becomes stateful, long-running, multi-user, and networked, it enters a different world. Now you need accounts. Permissions. Billing. Audit logs. Admin screens. Notifications. Support. Data retention. Security reviews.

Sometimes that is necessary. But it is not free.

This is one of my favorite tests for product bloat:

Is this still a tool, or is it becoming a platform wearing a feature costume?

That question saves a lot of time.

Boring infrastructure is underrated

Everyone likes the exciting parts: AI, dashboards, orchestration, shiny interfaces, smart agents.

But the boring parts decide whether the system can be trusted. Control tables. Watermarks. Run IDs. Idempotency. Schema checks. Audit columns. Reconciliation queries. Backfill strategy. Clear naming. Rollback paths.

These things are not glamorous, but they are the difference between a pipeline and a recurring incident.

The same pattern shows up outside data too. Backups matter. Network layout matters. Power matters. Storage choices matter. Firmware matters. Export paths matter.

Good systems are usually boring in the right places.

Business logic is not less technical

A lot of data work fails because people treat business rules as soft requirements and code as the real system.

That is backwards. The business rule is often the hardest part.

What counts as valid record? Who is the end user? Which date matters? When should a row be excluded? Which source wins when two systems disagree?

These questions are not side notes. They are the system.

The code is just where the ambiguity eventually becomes executable.

Prefer field notes over thought leadership

I do not want this site to sound like a conference keynote.

I am more interested in specific observations:

• This broke because the grain was wrong.
• This AI workflow looked good until validation.
• This Fabric pattern worked, but only after changing the control layer.
• This product idea sounded promising, then died under operational cost.
• This local AI setup was useful, but unreliable in this specific way.
• This router firmware worked fine until one feature made it unstable.
• This “simple” hardware project became a software debugging session.

That kind of writing is less polished, but more useful.

The internet has enough confident generalizations. I would rather write down what actually happened.

Local-first does not mean anti-cloud

I like local tools, local AI, self-hosting, and personal infrastructure.

Not because cloud is bad. Cloud is often the right answer.

But local-first thinking forces better questions:

Can the user export their data? Can this work without locking everything inside a vendor? Can the file remain useful outside the app? Can the system fail gracefully? Can the user understand what is happening? Can I still use this thing if the company changes its pricing or API limits?

Even when the final product runs in the cloud, those questions improve the design.

Hardware makes software less abstract

A lot of software thinking becomes cleaner when you occasionally touch hardware.

A Raspberry Pi that refuses to boot teaches something about assumptions. A flaky LTE module teaches something about reliability. A 3D print that fails after four hours teaches something about feedback loops. A storage box with bad planning teaches something about migration pain. A camera workflow teaches something about file management better than any productivity app.

These are not separate from software. They are reminders that systems live in the real world.

Software should respect future confusion

A system is not only built for today’s user.

It is also built for the future person who has to debug it. That person may be someone else. Often, it is you six months later.

Good systems leave clues. They explain their decisions. They name things honestly. They keep history where it matters. They make recovery possible. They avoid cleverness unless the cleverness is truly worth it.

A system that cannot be understood later is not finished. It is just temporarily working.

The goal is not minimalism

I do not believe in making everything tiny for the sake of it.

Some problems are genuinely complex. Some workflows need state. Some products need collaboration, permissions, integrations, and long-running processes.

The goal is not minimalism. The goal is proportionality.

The system should be only as complex as the problem has proven itself to be. Not as complex as our imagination can make it.

My default bias

Start with the smallest version that teaches the truth.

Then add structure where the pain is real.

Not before.

How this site is written

I write with AI in the loop — to think through ideas, fact-check specifics, and tidy the prose — then rewrite in my own voice. The arguments, the judgment, and the mistakes are mine. Many of these posts are field notes from real work; where that touches someone else’s business, I change the identifying details and keep the shape of what actually happened.