A senior architect's judgment, authored once — and on call for every line your team ships.
My kid spilled water on my keyboard halfway through a meeting last week — mid-demo, screen-sharing the thing I'm building, agents running and gates firing, while I typed via remote desktop on my tablet, my keyboard drying on a paper towel. I tell you this because I want to be honest about the conditions under which the work actually happens. It's not a clean room. There's no narrator's voice. There's a kid, and water, and a meeting on Monday, and you keep going.
The meeting was the rebuild kickoff for a company called FieldPulse. I'd been on the ground three weeks. I'm not their CTO — I'm a staff engineer they pulled in because their head of engineering was leaving and the place needed someone who'd done a rebuild before. I've done a few. The reason I was there at all is that Owen brought me in, and I've worked with Owen before. That sentence is the closest I get to a mission statement most weeks. Companies are people who have worked with each other before; the rest is paperwork.
What I want to talk about is what I saw in those three weeks, and why it pushed me to build InventArch full-time. The product is hard to describe in a sentence — which is its own problem — so let me describe the world it lives in first.
FieldPulse, like every company I have ever audited, had drift. Between what the docs said and what the code did. Between what product asked for and what engineering shipped. Between what the founders held in their heads five years ago and what the running system had become. Ryan, one of the engineers, put it cleanly: I wouldn't trust any living documentation anywhere — defer to the code for source of truth. He'd wired up a Slack channel to ping him every time Operator AI threw an exception, because he couldn't find the logs. Not for lack of access. The infrastructure was too convoluted to find them.
The audit turned up ninety modules. Ninety. Every other one touched a customer record, but no module owned the customer record — the flag lived in seven tables with a runtime sync layer to keep them honest. Some "features" began as bugs that got patched until the patch became the feature, undocumented. The reason the system behaves the way it does is buried in a Slack thread from 2022 that nobody can find.
This is not a FieldPulse problem. Drift is real, in every company. The bigger the company, the bigger the drift — until someone writes a check for a rebuild and a person like me shows up.
What I've come to believe — and it's the thesis of everything I'm building now — is that the drift is not an accident. It is what a system outputs when it has no way to remember why it made its decisions. Call it technical debt and you'll reach for the wrong cure. This is about memory. The company has forgotten itself.
When I present a rebuild to a leadership team, I don't lead with architecture. I lead with a house. Everyone in the room — engineering, product, sales, success, the CEO — can hold it and locate themselves in it. The CEO holds the blueprint. Sales wants a library inside it. Engineering wants a walk-in pantry. The architect translates wishes into load-bearing walls and electrical capacity. You don't call the decorator before the framers. You can pour a foundation that holds three stories and build one; you cannot pour one story and add a second without tearing the house down. So the foundation has to hold the house you want in five years, not the one you ship next quarter.
Something happens in the room that a Mermaid diagram never triggers. The sales lead stops fighting for her feature, because she can see the studs aren't up. The product manager stops pushing a strangler-fig migration, because he can see the data structure is the blueprint. The junior engineer relaxes, because she can see the decoration she's been losing sleep over comes at the end. The analogy is doing more than communicating — it is creating a shared frame of ownership.
The rebuild is not engineering's rebuild. It's the company's rebuild.
Everybody has a seat, and everybody is on the hook for what gets built. You don't get to throw it over the wall and complain six months later that it doesn't have your feature. You were in the room. This is the hardest cultural shift in any rebuild, and most companies fail it for the same reason they have drift: there is no system that holds the cross-functional context. You have a Notion, a Jira, a Confluence, a Slack archive, a Figma — and none of them remember why a decision was made. So when something breaks two years on, the company re-derives its own reasoning from scratch, usually by asking the longest-tenured engineer what he remembers. What he remembers is wrong, because no one remembers correctly across that distance.
You have Terraform. You don't have methodology by code. Terraform took the most thankless, drift-prone, tribal-knowledge-bound part of software — infrastructure — and made it declarable. You write the cluster, the policy, the role; you commit it; and the running infrastructure has to match the declaration. If it drifts, you see it.
We have nothing like that for process. We have process by tribal knowledge, by Notion page, by "the way we do things here." When a senior engineer leaves, the methodology leaves with her. When a junior joins, it's downloaded by osmosis over six months and half of it lands wrong. AI makes this worse, not better — a model with no methodology in context will confidently generate something plausible and structurally wrong, and you won't catch it until production.
The bet of InventArch — and I'll be honest, it's the bet of my life right now — is that you can encode methodology the way you encode infrastructure. Write down what a PRD looks like at our company, the non-functional requirements it must carry, who ratifies it, the chain of evidence connecting it to the spec and to the code. Then have a system enforce the declaration the way Terraform enforces a role. If a PRD ships without non-functional requirements, if a change has no traceable spec, if an AI contributor contradicts a prior architectural ratification — you see it.
This is what I mean when I say AI is great at depth and bad at breadth. It cannot know that three weeks ago we chose event-driven over request-response for this domain, that the customer module is the only place customer state may mutate, that a prior architect made a load-bearing decision about integration wrappers. The breadth is invisible. So you either accept AI as a high-variance contributor that occasionally torpedoes you, or you build a system that gives it the breadth — a typed, walkable graph of every decision, PRD, spec, and ratification, so any contributor can climb the chain and make a different decision because it can see the chain.
I want to be careful: InventArch is not zero-effort. Authoring a methodology that captures real expertise takes real expertise. It does not relieve you of a senior engineer in the loop — it makes that engineer durably leverageable across a far larger group, human and AI. Same senior people, plus AI, plus juniors now working against an encoded methodology instead of a Notion page from 2022. That's the leverage thesis.
Another engineer that week — Mykhailo, who runs the Engage platform — showed me a PRD product had written in a few hours. He'd left forty-two comments on it. Forty-two edge cases nobody had considered.
You're fighting the good fight.
That's what I told him, and I meant it. Sitting there alone, in defense of his platform, catching forty-two undefined behaviors that would otherwise have shipped as production bugs — that is the unsung labor of every senior engineer in every company that hasn't put product and engineering into a real symbiotic loop. Product is not the enemy. Engineering is not the enemy. But they have to operate as a pair, and most companies set them up as a handoff: product throws requirements over the wall, engineering builds, throws it back, everyone's unhappy, the cycle compounds.
The usual "fix" is to put product in the engineering dailies. That's backwards. Mykhailo pulled product out of his dailies the week before we met and the team breathed for the first time in a year. The fix is not more synchronous meetings — it's a shared artifact both functions author against: a real schema, non-functional requirements as a first-class concept, ratified, versioned, connected to the spec downstream and to the code itself. Then product works async, engineering works async, and the artifact is the meeting. The PRD is a record. The spec is a record. They are joined by a typed edge — grounded-in. If the spec drifts from the PRD, you see it.
I am suspicious of leaders who walk into a room and announce what everyone needs. The most reliable way I've found to change how a company thinks is not to tell them what to think — it's to put a frame in front of them and let them experience the wrongness of the status quo before I offer the alternative. By the time we discuss the alternative, they've arrived on their own, and I'm just putting language on what they already feel.
It's also why I'm building InventArch the way I am: the product dogfoods the philosophy. The site I showed the FieldPulse leadership — the house analogy, the phase map, the stakeholder ownership — was generated by InventArch from their own audit artifacts. The exploration that becomes the RFC that becomes the spec that becomes the implementation all sits in one graph, grounded back to the manifesto, walkable. When an AI contributor extends the substrate, it reads the prior decisions and respects them, because it can see them. When the drift starts — and drift always starts — the system surfaces it before it compounds.
I'm not here to convince you AI will replace anybody. It won't. I'm here to argue that AI without methodology is a centrifuge for drift, that methodology without code is a centrifuge for drift, and that the cure for both is the same: encode the methodology, connect it to the artifacts, walk the chain.
Most rebuilds fail because the company forgets why it was rebuilding. Most product-engineering wars happen because no one is holding the breadth. Most "the AI shipped junk" stories are stories of an agent working in a context-vacuum we forgot to fill. These are not separate problems. They are one problem in three costumes — companies have no way to remember themselves across people, time, and tools.
If you've read this far, you already know this. You've sat in the forty-two-comment review. You've inherited the ninety-module monorepo. You've watched a junior re-derive a decision three people made in a hallway eighteen months ago. You've felt the drift.
You're fighting the good fight. So am I. We're going to have fun with it. — Thomas