I’ve built three systems in the past two years. A modular web framework that runs three websites. A lighting system that gives my home a daily rhythm. And a wooden cube that lets a four-year-old who can’t read choose his own bedtime story.

They look nothing alike. One is TypeScript, one is YAML, one is a Zigbee sensor and a sticker. But they run on the same idea.

States. Sensors. Responses.

A website detects that a folder exists and adapts its navigation. A home detects motion and adapts its lighting. A cube detects which face is up and adapts what plays in the room. The pattern is identical. The material is different.

Code is leaving the screen and entering the room. The people who will do well in that shift aren’t the ones who know one language or one platform — they’re the ones who recognize the pattern underneath and can apply it to whatever material the problem happens to be made of.

The Same Architecture, Three Times

On the Web — Standard

Nothing lists the modules. Adding the folder is the input; the site reconfiguring itself is the output.

In the Home — Mood Controller

The house moves through Morning, Day, Evening, Unwind, Night. A room can diverge — someone’s watching a film — and rejoin the rhythm afterward without being told what time it is.

In the Children’s Room — the Stories Cube

This one is my favourite, and it’s the one that most clearly stops being a metaphor. There’s no screen anywhere in the interaction. The input is an object you hold. The feedback is the colour of the room.

And a greenhouse will be the fourth, once it’s built — growth phases instead of moods, soil moisture instead of motion, a vent instead of a lamp.

The Interface Disappears as the Constraint Tightens

Something happens as you move down that list, and I didn’t design for it — I noticed it afterward.

The web framework has a config file. The house has switches and an app. The cube has neither. It has a shape, a colour, and a place it belongs on a shelf.

The constraint that produced that was my son. He can’t read. He can’t be taught a gesture vocabulary. He has no patience for a system that requires understanding before it gives you anything. Every affordance had to be one he already had: put the thing on the other thing.

Designing for someone with no manual, no vocabulary and no patience is the strictest usability constraint there is. There’s no “the user will figure it out.” It works immediately or it doesn’t exist.

I’ve started applying that test to software I build for adults, and it’s uncomfortable how often it fails.

What This Actually Requires

The honest version of the generalist argument.

A pure software developer can’t design an enclosure that survives humidity. A pure hardware engineer usually won’t build the dashboard that makes the data legible. A pure designer won’t wire the relay board.

Someone who understands all three — even imperfectly, even at the level of I know enough to know what to ask — can imagine systems that none of them would propose alone. Not because they’re better at any of the three, but because they can see across the seams.

That’s not a defence of being a generalist. It’s a description of a specific job: translating between materials that don’t share a vocabulary.

The failure mode is real too, and I’ve lived it. Knowing a little about everything means being genuinely dangerous at the boundaries — the electrical work I shouldn’t do myself, the security decisions I have to look up every time. The value isn’t in doing all of it. It’s in knowing which parts to hand off.

Where This Goes

Computing is moving into spaces. Buildings that adapt to occupancy. Agriculture that runs on sensor data. Museums, libraries, installations, classrooms. The interfaces in those places can’t assume a screen, a login, or a manual.

Meanwhile the repetitive production work — the code that writes itself, the boilerplate, the fifth CRUD screen — is increasingly not the job. What remains is the judgment: understanding what a space needs, how people feel in it, and what makes a system serve rather than surveil.

That judgment doesn’t come from a framework. Mine came from fifteen years of photographing people who didn’t want to be photographed, which taught me the only lesson that transfers to all of this: the person did not ask to be here. Not the sitter, not the user, not the four-year-old. Your job is to remove what’s in the way and then get out of it.

The Best Systems Are the Ones You Forget

The house doesn’t announce that it’s changing moods. The cube doesn’t confirm your selection. The framework doesn’t tell you it registered your module.

They just work, and then you stop thinking about them.

That’s the same standard as a good portrait — the one where the person forgets the camera is there and you finally see them. The apparatus disappears and what’s left is the thing you actually wanted.

Whatever material I’m working in next, that’s the test.

Francis Fontaine bridges the digital and physical worlds from Québec City. He builds modular web frameworks (stnd.build), home automation systems (Mood Controller), and occasionally objects a four-year-old can operate — all driven by the same architectural instinct.

Are you absolutely sure?

This action cannot be undone.