Notes on building software you own
Practical writing on ownership, architecture and automation, from the projects we build and the questions clients ask us.
Start here, ownership
Ownership is not a deliverable
Why handing over source code is only the beginning, and what real ownership requires across five layers most handovers skip.
Ownership
Ownership is not a deliverable
Why handing over source code is only the beginning, and what real ownership requires across five layers most handovers skip.
Ownership
The hidden cost of vendor dependency
Dependency is rarely priced upfront. It accumulates in integration fragility, undocumented decisions, and the slow loss of institutional control.
Architecture
Why architecture decisions outlive projects
The stack fades. The shape of the system persists. How initial architectural choices constrain or liberate every team that follows.
Architecture
Building systems that survive team changes
Teams rotate. Software should not reset every time they do. Structures that keep context in the codebase, not in someone's head.
Engineering
Most software debt starts before development
Poor discovery creates expensive systems, most structural debt is decided before the first commit, not during it.
Automation
Automation should remove friction, not add complexity
The difference between useful automation and automation theatre, when removing friction versus adding hidden complexity.
EngineeringComing soon
The difference between shipping and engineering
Shipping closes a ticket. Engineering builds a system that holds under change. The gap is in tests, boundaries, documentation and operational clarity.
AutomationComing soon
The operational cost of bad automation
Fragile pipelines, opaque agents and brittle integrations create a new category of maintenance work disguised as efficiency.
Business SystemsComing soon
Software should mirror business reality
When systems fight how the business actually operates, workarounds multiply. Good software reflects operational truth, not idealised process diagrams.
Business SystemsComing soon
Why spreadsheets survive bad software
Spreadsheets win when software is rigid, slow to change or owned by a vendor. That survival is a signal about fit, not user preference.
Product ThinkingComing soon
Features rarely solve operational problems
Most operational pain is structural: data silos, manual handoffs, unclear ownership. Adding features to a broken workflow amplifies complexity.
Product ThinkingComing soon
Complexity is usually a design decision
Complexity is rarely accidental. It reflects trade-offs made early, often under pressure, and left undocumented for the next team to inherit.
Have a question we haven't written about?
Ask us directly. If it's useful to others too, it may become the next article.