Innovation

Why an architecture practice builds software

Most of what goes wrong on a building project isn't a design problem. It's an information problem.

A decision gets made in a meeting and written down in three different places. A drawing is superseded but the old one is still on site. Someone asks what was agreed about the roof and four people have four answers. None of that is anybody's fault. It's what happens when a project involves a dozen people, runs for a year and produces several thousand documents.

Every practice deals with this somehow. Most deal with it by remembering harder.

We started writing things down instead. A folder structure that worked, so it got used on the next project. A way of recording decisions that stopped the same question being asked twice. A template for a report that took an afternoon rather than two days. After a few years those things had stopped being notes and started being a system.

That system became DesignFlowOS.

What it is

DesignFlowOS is built on a simple conviction: the work that needs your judgement should have all of it, and everything else should be structured enough to move without constant chasing. Not by replacing you, but by giving your practice a structure to hold its information, a system that runs when you step back, and intelligence woven through both, so the admin that never needed you stops landing on your desk.

The DesignFlowOS ecosystem Five stages, a standards layer above them and a practice intelligence layer beneath.
Standards layer SOP Library
Structure Studio Structure
Run the studio Studio OS
Project intelligence Dolemai
Site capture SnagFlow
Learn Academy
Practice intelligence layer DFAI

DesignFlow AI, woven through every stage rather than bolted onto one.

The system is a loop rather than a line. Standards feed the studio, the work moves through delivery and out to site, and what happens on site comes back. The products connect because the work connects.

Why it matters if you're a client

You don't need to know any of this to work with us, and none of it appears in your project as software you have to use.

What it does mean is that the discipline goes both ways. Building tools for other practices forces us to be exact about how we work: what happens at each stage, who decides what, where a decision gets recorded, what a good report actually contains. You can't systematise a process you haven't thought properly about.

So the thing you get isn't the software. It's a practice that has had to write down how it works, and can therefore tell you.

Where to find it

DesignFlowOS and Dolemai are separate businesses, each with its own site.