← Design × Code

I designed my house the way I run production systems

Design × Code

I trained as an architect before I spent my career in software and DevOps — a teardown I chose while I was still good at the first one — so when I designed my own house I expected the architecture education to do the heavy lifting. The decisions that shaped the house — the ones I’d defend hardest — came from production systems instead: reduce the components that can fail, make dangerous states unreachable, contain the blast radius, design for the load you’ll have later, and protect the parts you can’t replace.

It produced an unusually boring house rather than an unusual-looking one, boring in the way a good production system is boring: very little can go wrong, and what can go wrong is contained. I’ve come to think the crossing works in both directions — where generative design is actually heading is the other one — but this is the systems half. Here’s the reasoning, decision by decision.

One energy source, because every component is a liability

The house runs everything on solar electricity — heating, cooling, cooking, water heating, all of it. No gas line, no diesel generator, no wood.

The obvious reading is an environmental one, and fine, but the reasoning was operational. Every energy system a house carries is a full stack of its own: supply, storage, distribution, combustion or conversion, maintenance schedule, failure modes, and a set of skills you need on call when it breaks. A house running gas and electricity and wood is running three stacks in parallel and inheriting the failure surface of all three — chimneys to sweep, tanks to fill and inspect, a combustion system aging in the wall.

In systems work we have a name for the alternative: consolidating on one well-understood platform. One energy stack means one set of failure modes and one skill set to maintain it. When something misbehaves, there’s no ambiguity about which subsystem to debug. The house got simpler to own, and ownership is where houses, like systems, actually cost you.

The fireplace I deleted, and why that’s the whole philosophy

Early sketches had a fireplace. Everyone’s do — it’s the emotional centre of a certain idea of home. I removed it, and the reason is the most software-shaped decision in the building.

A fireplace is an open flame whose safety depends on a human remembering things: to bank it properly, to never leave it unattended long enough. Under normal conditions everyone remembers. But a house, like a production system, operates under all conditions: the distracted night, the holiday rush out the door. Give a failure mode enough evenings and it will eventually find the one where the human layer fails. Every operations person has watched this movie; the incident report always contains the word “forgot”.

The fix we’ve learned in software is to remove the state. A wrong state that’s unreachable doesn’t need procedures or vigilance. So the house simply cannot have an unattended open flame, because it has no flame. Not “be careful with the fireplace” — no fireplace.

I notice non-engineers sometimes hear this as joyless. I’d put it the other way: nothing in the house demands ongoing carefulness, which is exactly what makes it restful.

Utility rooms outside the residence: blast radius as a floor plan

The mechanical, electrical, and tools rooms are separated out of the residential volume entirely — and they’re three separate small rooms rather than one shared utility block.

The first decision is blast-radius containment, in the most literal sense the term will ever get. Inverters, batteries, pumps, compressors, stored fuel for tools — these are the components most likely to fail energetically, by fire or by leaking. If one does, the failure should spend itself in a small masonry room outside the living space rather than inside it. It’s the same reasoning as isolating risky services away from the core of a system: you can’t make failure impossible, but you can decide in advance where it’s allowed to happen.

The second decision — three rooms rather than one — is about environments. Batteries want one temperature range, tools and their dust want ventilation on demand, electrical gear wants dry and cool. A single shared room forces one compromise climate onto all three, and couples their failures: the dust from the tools ends up in the electronics, the heat from one system stresses another. Three small rooms mean three small, controllable environments, each ventilated and tempered for what it actually holds, and small scopes are cheaper to condition for rooms exactly as they are for services.

Floor-to-ceiling windows are a migration path

Every room’s windows, including the kitchen’s, run floor to ceiling.

The aesthetic case makes itself. The operational case is the one I care about: it keeps future states reachable. A room whose full wall opens to the outside can become a furnished balcony area — a covered outdoor room — without structural work. The kitchen can become a kitchen that’s effectively outdoors in good weather. Rooms can swap purposes as the household changes, because no room’s window layout locks it into being a bedroom forever — the household-scale version of asking whether cheap personalization should reopen the social housing question.

In software terms: I don’t know the future requirements, so I kept the interfaces wide. A house is a forty-year guess about how you’ll live, and the cheapest flexibility is the kind you pour into the concrete on day one, because it’s unbuyable at any price on day two.

Solar sized for the load I don’t have yet — as two systems, not one big one

The power design is two independent solar systems in parallel — each with its own eight panels, its own inverter, and one or more batteries — rather than one large system with a single inverter.

Anyone who has run infrastructure will recognise the shape immediately. A single big inverter is a single point of failure for the entire house: it dies, everything is dark until a replacement arrives. Two parallel systems mean an inverter failure degrades the house to half capacity instead of zero — an annoyance rather than an outage. Failures in a redundant pair are events; failures in a singleton are incidents.

The second property is scale. Adding capacity means adding panels or batteries to either system, or standing up a third alongside — horizontal scaling, no rip-and-replace of the core. That headroom isn’t hypothetical: if the residence later grows a workshop, the power design already accommodates it. Sizing for the current load and planning the expansion path is exactly how you’d provision anything; it still surprises me how rarely buildings are designed with a capacity roadmap at all.

Protecting the components you can’t redeploy

The last one is invisible, and it’s my favourite. The floor slabs extend 30 centimetres beyond the edges of the reinforced-concrete columns, and the columns are wrapped in hollow-block masonry right to the slab edge.

Reinforced concrete is the house’s irreplaceable layer. Everything else — finishes, windows, systems, even the roof covering — can be repaired or swapped over the building’s life. The structural frame cannot, not meaningfully. And its enemy is exposure: weather cycling and moisture reaching the concrete, eventually corroding the reinforcement inside. Structure that sits at the building’s outer edge takes that weathering for decades.

Pushing the slab perimeter out past the columns and wrapping the columns in a sacrificial masonry jacket means the weather spends itself on cladding — a replaceable layer — while the frame sits shielded behind it, effectively indoors for its entire life. That substantially extends the life of the one subsystem with no upgrade path, which is the oldest rule in operations cast in concrete: nothing else’s job is allowed to become the irreplaceable component’s problem. Building the thing taught me a rule about tolerance I did not have when I drew it, and it cost me money before I noticed: choose forgiving components everywhere except the foundation.

Learn how systems fail and you have already learned how houses fail; only the material changes.

Which failure mode in the thing you’re building now still depends on someone remembering?

Hsein Bitar is a product developer, DevOps and backend engineer. He owns infrastructure, CI/CD and backend architecture in production at NSquared. Who this is, and what he ships.

Read more notes