A Requirement Rather Than a Reality
Oct 29, 2026
Software engineering was named in 1968 as an aspiration, not a description: a discipline the field decided it needed because too much was falling through the cracks. Vibe coding is interesting not because it uses AI, but because it can separate producing code from the human responsibility to understand it, a responsibility that review, testing, traceability and change control all depend on. How much discipline a system needs depends on how long it lives and what it touches. Fintech products sit at the far end of both, and there the discipline is written into the standards. Vibe coding still has a place, at the start, as a way of seeing requirements, but the prototype is not a signed baseline: what is worth freezing is the load-bearing decisions, not every screen. Spec-driven development can hold those decisions, but only if the spec keeps being maintained; a tool is not the discipline itself.
Read
The Hollow Sprint
Oct 9, 2026
Agile was an answer to uncertainty at a time when building software was expensive: plan little, build small, learn from what the customer sees. AI has made build capacity and decision capacity diverge. A team that keeps its old rhythm ends up running hollow sprints: on schedule, every ceremony intact, with more and more unconfirmed decisions inside them. Cheaper building could justify more upfront planning or even more iteration, and both are right, for different kinds of decision. AI moves the last responsible moment in two directions at once. The unit of methodology is no longer the project. It is the decision.
Read
The Evaluation Constraint
Aug 2, 2026
Two engineering organizations with the same headcount, the same budget and the same stack will diverge enormously over five years, and the divergence is not talent or effort. It is which allocation of capacity they found. Superior allocations exist, they are rare, and finding one is a search problem — which means the arm of that search AI just made cheap is not the arm that was ever binding.
Read
The CTO Decision Stack in Startup and Enterprise
Jul 12, 2026
The third post in the CTO Decision Stack series. The seven layers don't change between a ten-person startup and a ten-thousand-person enterprise. What changes is what each layer is optimizing for, given different constraints — capital, reputational exposure, existing assets, and time horizon. A startup shipping a throwaway product to win a deal and an enterprise refusing to is not one of them being undisciplined. Both can be right. The recurring failure isn't a bad decision at either end. It's importing a tradeoff that was correct somewhere else.
Read
AI Across the CTO Decision Stack
Jun 14, 2026
AI is not a layer-seven tool — it's a force that changes the cost structure, failure modes, and governance requirements of all seven layers of the CTO Decision Stack at once. This post walks the stack layer by layer, tracing how a single tooling adoption decision leaves six other layers with open questions nobody asked.
Read
The CTO Decision Stack
Jun 7, 2026
Most technical leadership failures are not failures of the wrong decision. They are failures of the wrong layer — the right question answered at the wrong altitude, by the wrong people, against the wrong criteria. The CTO Decision Stack maps seven distinct layers of decision-making, from corporate strategy to developer productivity, and shows why conflating them is how organizations accumulate consequences they cannot trace back to a cause.
Read
From Project to Product to Company — What the Transition Actually Requires
May 16, 2026
Most final year projects successfully prove something can be built. The harder questions — will someone use this repeatedly, and can it survive when conditions change — are what the next step requires. This post maps the transition from project to product to company: what it takes to find the hidden need, build the feedback loop, understand the landscape, and bring something real to the world.
Read
The Pipeline Is Not the Problem
May 2, 2026
Most SDLC policies don’t fail because they are poorly designed. They fail because they assume the system will sustain itself. Pipelines stay green, audits pass, and metrics look healthy — while the underlying system quietly degrades. The problem isn’t the pipeline. It’s the gap between what the process enforces and what the culture rewards.
Read
Designing for Scale Before Scaling: A Practical Reading of Conway's Law
Mar 15, 2026
A structural perspective on scaling fintech systems using Conway's Law. Exploring how organizational structure, branching strategy, and delivery mechanics must align before growth introduces irreversible complexity.
Read
The Inevitable Cycles: Why Software Houses Keep Returning to Square One
Jan 12, 2026
There and Back Again — from Cloud to On-Prem, Projects to Products. An exploration of why software houses repeatedly cycle through infrastructure, delivery models, processes, roles, and technical debt as they scale.
Read
A Practical Git Branching Strategy for Multi-Version Product Organizations
Jan 2, 2026
A product-centric Git branching strategy that supports multiple customer versions, controlled customization, and scalable delivery without sacrificing engineering velocity.
ReadTECTONICS: Systems, Culture & Scale
Dec 26, 2025
This space is a record of how technology organizations actually move.
Read