Build Things That Last

There is a particular kind of software that looks sophisticated but is actually just complicated. It has many moving parts, requires institutional knowledge to operate, and breaks in ways that are hard to diagnose. It creates stress for the people who depend on it. That kind of software is not a success — it is a liability dressed as a product. The goal of good software engineering is to solve hard problems simply. Not to use the minimum number of technologies, but to use the right ones in ways that can be understood, operated, and extended by people who were not in the original design meetings. Calm systems are boring in the best sense: they do what they are supposed to do, they fail in predictable ways, and they tell you when something is wrong. In practice, this means preferring managed services over self-managed infrastructure where the operational difference is small. It means favoring explicit configuration over convention-based magic. It means writing code that reads like a description of what it does. It means building in observability from the start so that production behavior is never a mystery. These choices do not make projects faster to build. They make systems less expensive to operate and less catastrophic to maintain.

Security added at the end of a project is security that did not make it into the design. By the time a penetration test or compliance audit happens, the data model is fixed, the access control boundaries are set, the logging infrastructure is — or is not — in place. Finding a gap at that stage means expensive rework, not a quick patch. Secure-by-design means that the questions security teams ask are answered during architecture, not afterward. Who can read this data? Who can write it? What gets logged when a user accesses a record? How are secrets managed across environments? What happens when a session token is compromised? These are not security questions — they are design questions with security implications. Treating them that way changes when they get answered and how much fixing a mistake costs. This is especially true in regulated environments. HIPAA's technical safeguards are not a list of things to add before an audit — they are a description of how a system that handles PHI should be built. SOC 2 trust service criteria are not documentation requirements — they are engineering requirements for access control, availability, and incident response. Meeting these standards through design rather than remediation is both more reliable and less expensive.

There is a meaningful difference between AI that makes a system faster and AI that makes a system autonomous. In regulated industries, that difference matters legally and practically. A system that surfaces relevant case law is useful. A system that makes legal determinations without a licensed attorney reviewing them is a liability. A system that flags potential coding errors in a claim is useful. A system that auto-adjudicates claims based on a model's output without human review is a risk management problem. I build AI into workflows where it creates leverage without removing accountability. That means retrieval-augmented systems that cite their sources so a human can verify the response. It means guardrails that constrain model output to the domain the system is designed for. It means audit trails that record not just what the AI returned but what the human did with it. It means fallback paths for when the model's confidence is low or the query falls outside its intended scope. This is not a philosophical position against AI autonomy in the abstract. It is a practical position about what regulated environments require. An AI system that a compliance team cannot audit is not a compliant AI system, regardless of how accurate it is.

Most software engagements follow a recognizable pattern: requirements gathering, build phase, launch, handoff. The relationship ends when the code is delivered. The people who built the system move on, the institutional knowledge goes with them, and the client is left with a codebase they partially understand and a support contract with someone who was not on the original project. That model produces software that calcifies. The original design decisions cannot be revisited because no one remembers why they were made. The system grows harder to change over time. Technical debt accumulates without anyone who can distinguish debt that matters from debt that does not. Long-term stewardship looks different. It means being present when a compliance officer asks a question about data retention. It means evaluating a new integration request in the context of the existing architecture, not in isolation. It means having an honest conversation about when the right answer is to rebuild something rather than extend it. That kind of continuity is not a service tier — it is a different model for how software should be built and maintained.

Every architectural decision involves a tradeoff. A serverless architecture reduces operational overhead but adds cold start latency and vendor lock-in. A relational database gives you referential integrity but requires careful schema migration management. A monolith is easier to reason about than microservices but harder to scale independently. None of these choices is universally correct — the right answer depends on your constraints, your team, and what you are optimizing for. What I try to provide is the information needed to make those decisions with open eyes. If I recommend DynamoDB for a particular use case, I will also explain what it makes difficult: ad-hoc queries, complex joins, schema evolution. If I recommend a managed identity provider over building your own, I will explain the coupling that creates and what migration would look like if you need to move. This matters most when a client has strong opinions about a technology choice. My job in those situations is not to capitulate or to override — it is to lay out the implications clearly enough that the decision is made deliberately. Sometimes the client's instinct is right. Sometimes there is a constraint they were not aware of that changes the calculus. Either way, the conversation should happen before the code is written.