Software That Survives Contact With Business Reality

Most software conversations are too clean.

Architecture diagrams have tidy boxes. Product demos follow the happy path. AI prototypes answer confidently in a browser tab, and compliance tools promise control and visibility like it’s the easiest thing in the world. SaaS landing pages make it sound like the hard part is just picking the right platform.

Then the system meets the actual business, and things get messier fast. Someone uploads the wrong document. A required approval turns out to depend on a person who left the company six months ago. The database somehow has three different meanings for the same customer. An integration works fine — until a vendor quietly renames a field. Sales needs an exception, the auditor asks for evidence nobody thought to keep, and the AI assistant gives a confident answer with nothing real behind it.

That’s usually where things get interesting, honestly.

This blog lives in that gap — between software as it’s imagined, and software as it actually has to survive inside a real, running business.

I build and think about systems that sit close to day-to-day operations: internal tools, SaaS products, document workflows, compliance-heavy processes, integrations, dashboards, APIs, and AI features that need to actually do something, not just look clever in a demo. In my experience, these systems rarely fail because someone picked the wrong pattern out of a textbook. They fail because the real constraints got treated as minor details along the way.

More often than not, the details are the product.

Who owns this data, and who’s allowed to change it? What happens when the input is incomplete, or the decision trail disappears somewhere in the middle? Could someone non-technical actually follow what happened here? Would the system survive a partial failure — and could anyone explain it, six months from now, without archaeology?

None of that sounds glamorous. But it’s usually what decides whether software becomes a real asset, or a slow leak of time, trust, and money.

A lot of modern software work gets pulled between two bad instincts, and I’ve been guilty of both.

One is overengineering — every problem becomes an excuse for a framework, an abstraction, a platform, a service mesh, or a diagram with more arrows than actual facts. It can feel professional, because it creates motion and vocabulary. It can also bury a fairly simple business process under machinery nobody actually wants to maintain two years later.

The other is demo-driven development: move fast, wire up a few APIs, get something shiny working, and hope structure can be bolted on afterward. Sometimes that’s genuinely the right way to test an idea. But if the experiment quietly turns into production — and it usually does — the bill shows up eventually, in the form of brittle workflows, unclear ownership, missing audit trails, and features nobody really trusts.

Good software tends to live somewhere less dramatic than either of those extremes.

It starts with the actual job the system has to do — not the pitch version, but the uncomfortable one. Messy data, bored users, edge cases, tight budgets, regulatory pressure, and business processes that evolved over a decade of patches, meetings, and “just for now” decisions that never quite went away.

That doesn’t mean everything needs to be heavy, though. If anything, it’s the opposite — the more real the constraints, the more carefully you should avoid piling on complexity that doesn’t earn its keep. A small, boring, well-understood system that handles the actual workflow is usually worth more than a sophisticated platform aimed at the wrong problem.

This is especially true with AI.

I use AI. I build with it. It genuinely speeds up writing, coding, research, classification, extraction, support workflows, document processing — a lot of things. In compliance and operations specifically, it can help people spot signals buried in piles of text that would otherwise just sit there, unread.

But AI doesn’t remove the need for structure. If anything, it makes structure matter more.

If an AI feature can’t show where its answer came from, the user is stuck trusting a black box. If it can’t express uncertainty, it’ll sound just as confident when it’s right as when it’s making things up. If nobody’s defined the review loop, the whole thing becomes either a toy or a liability. And if the UX hides the failure modes, people will use it wrong — and then blame the tool, often fairly.

So the real question isn’t “can we add AI here?” Usually, we can — that part’s easy.

The harder, more useful question is where AI actually fits into a workflow where humans still need accountability, traceability, and control. Less fashionable question. Better one.

The same logic applies to compliance software, by the way. It’s often sold as a dashboard problem. In reality, it’s a workflow and evidence problem. Policies need owners. Controls need proof. Documents need history. Reviews need reminders. Exceptions need context. People need to know what’s missing before the audit — not while it’s happening.

A beautiful compliance dashboard with nothing solid underneath is mostly theater. A plain, unglamorous workflow that helps a company consistently collect, review, and explain its evidence is far less exciting to look at — and far more likely to actually survive contact with an auditor.

This blog is going to be a place for thinking through that kind of thing, out loud.

I’ll write about architecture — not architecture as ceremony, but as the set of decisions that make software easier or harder to change once reality shifts under it. I’ll write about product work, not as a pile of growth slogans, but as the discipline of figuring out what actually matters, what can wait, and what probably shouldn’t get built at all. I’ll write about AI without pretending it’s magic — a powerful, unreliable, genuinely useful component that needs evaluation, boundaries, and honest UX around it. And I’ll write about compliance workflows, document-heavy systems, internal tools, integrations, and the quiet engineering decisions that end up deciding whether a product feels solid or fragile a year in.

Some posts will be technical. Some will be more strategic. A few will probably be notes to my future self, written right after watching some small, boring problem quietly turn expensive — because nobody wanted to ask the obvious question early enough.

The thread running through all of it is business reality.

Software isn’t finished the moment it runs locally, survives a demo, or gets a nod in a planning meeting. It earns its place later — once people actually depend on it, misunderstand it, stretch it past what it was built for, misuse it a little, and still need it to produce something clear at the end.

That’s the bar I care about. Not perfect software, not fashionable software, not software that looks impressive for ten minutes on a call.

Software that holds up.