Practice design for small architecture firms

By George Valdes, co-founder at Toolblocks.

Most small architecture firms don't have an operations department. They have a few people trying to keep a lot of promises.

If that's you, this post is about a simple idea that changes everything: treat operations like a design problem.

Not "add more process." Not "become a mini-corporation."

Just design the system so the same work is easier the second time.

It usually looks like this when you've outgrown improvisation:

• An invoice drafted after dinner.
• A spreadsheet that only one person understands.
• A task list in one place, an email thread in another, and the "latest" notes in someone's head.

None of that means you're disorganized. It means your firm has outgrown improvisation.

Practice design

Practice design is what happens when you treat how the studio runs like a design problem.

Not "add more process."

Design the system so the same work is easier the second time.

If you're already good at scope, schedule, and constraints, you already have the skill. You just haven't pointed it at your own studio.

Why this matters

Most firms don't fail because they can't design. They get squeezed by tiny leaks.

The leaks show up as:

• Work that gets done twice because it isn't captured once.
• A milestone that ships, then billing slips because "we'll send it tomorrow."
• A decision that doesn't make it into the set, so it becomes a new round of coordination.

If you've ever thought, "We're slammed, but the bank account feels…normal," you know the feeling.

Here's what actually happens. You hit a deliverable, you move on, and the invoice lives in a tab until it expires. Three weeks later you build the invoice from memory. The work was real. The margin didn't survive the delay.

A quick diagnosis for small firms

When someone says "we need better operations," what they usually mean is one (or more) of these:

• Work disappears: tasks, decisions, and scope changes don't get captured reliably.
• Work repeats: you re-do coordination because you can't find the last answer.
• Work drifts: the next deliverable isn't explicit, so everything becomes "in progress."
• Work delays cash: billing is treated like admin, not a production step.

Practice design is just closing these loops with a few defaults.

Common failure modes (and how to fix them)

If you want this to be practical, start here. These are the repeatable breakdowns I see most often in small studios, plus the smallest fix that actually changes behavior.

1) "We're busy, but cash feels tight"

• What's happening: billing is treated as admin work that can wait, so invoices lag behind delivery.
• Small fix: add one billing trigger to your workflow: a deliverable is not "done" until the invoice is drafted (or sent) the same day.
• Helpful tool: if you want a simple way to standardize fees and invoice math, use an invoice calculator.

2) "We keep re-answering the same questions"

• What's happening: decisions live in chats, email threads, and someone's memory.
• Small fix: keep a decision log (even a tiny one) and make it searchable. The key is consistency, not format.

3) "Scope creep is killing us"

• What's happening: scope changes get accepted conversationally, but never get priced, scheduled, or translated into the set.
• Small fix: adopt a one-sentence scope-change habit: "When scope changes, we write it down and decide what moves: fee, schedule, or deliverable."

4) "We lose momentum between phases"

• What's happening: phase transitions are ambiguous, so work drifts and handoffs get messy.
• Small fix: add a short phase transition checklist and reuse it every project.
• Helpful tool: start with a project phase checklist and tune it to your firm.

5) "We get surprised late by coordination issues"

• What's happening: quality checks happen too late, or in too many places, so issues pile up.
• Small fix: move checks earlier with a consistent review moment (end of week, end of phase) and a short checklist.
• Helpful tool: if PDFs are part of your workflow, a lightweight PDF QA/QC pass helps catch the boring inconsistencies before they become a fire drill.

A starting point that won't turn into paperwork

If you're a 1–4 person firm, you don't need a "system." You need a few defaults that protect your time and your cash.

1) Pick three outcomes you care about

Don't pick ten. You won't use them.

Examples that work for small studios:

• Invoices go out within 24 hours of the billing date you promised yourself.
• Every project has a clear next deliverable and a named owner.
• You can explain what changed since last week without reopening ten tabs.

Write them down. Put them somewhere visible. That's enough.

2) Find the exact moment things get vague

"We should…" is where profit goes to die.

Listen for the recurring questions:

• "Which version is the right one?"
• "Did we decide 36 inches or 42?"
• "Who's sending the email?"
• "Why is billing behind again?"

You don't have a software problem yet. You have an "information goes missing" problem.

3) Reduce context switching by standardizing the repeatable parts

This is where "one line item" thinking is healthy. The goal is not to replace every tool you already use. The goal is to stop translating the same facts across them.

Pick a couple of repeatable objects and make them boring:

• A template for what "done" means on a deliverable.
• A checklist for site and code research so you don't re-discover the same links each project.
• A consistent place where decisions get recorded in a way you can find later.

When you don't do this, you pay a translation tax: retyping, hunting for sources, and re-loading context before you can make a decision.

The smallest viable operating system for a studio

If you want practice design to stick, keep it to four "objects" that you maintain relentlessly:

• One source of truth for tasks: what is happening next, who owns it, when it's due.
• One decision log: a running list of project decisions (small is fine) you can search later.
• One scope-change habit: the moment scope changes, you record it and decide what moves.
• One billing trigger: billing becomes a step that happens because the milestone is done.

You'll notice none of these require a new tool. They require a default.

A decision log template you can copy

Put this in whatever tool you already use (a doc, a note, a task comment). The point is not the format; it's the habit.

• Date:
• Project:
• Decision: what we decided, in one sentence
• Why: the constraint or trade-off
• Impact: what changes in drawings/specs/budget/schedule
• Owner: who will implement it
• Source: email / call / meeting / code section / client text

If you do this consistently, you cut down the "did we decide 36 inches or 42?" tax.

A billing trigger that doesn't get "handled later"

Small firms often treat billing like a separate admin activity. That's the mistake.

Try this default instead:

• Definition of done includes billing: "done" means the deliverable shipped and the invoice is drafted (or sent) the same day.
• Calendar guardrail: you pick one recurring time window (e.g., Friday 4–5pm) to send anything that wasn't sent in-flight.
• One file, one place: invoices live in one folder with a consistent naming convention you can search.

This isn't about being "more organized." It's about eliminating avoidable cash-flow lag.

What practice design is not

• It isn't bureaucracy.
• It isn't tracking everything.
• It isn't "replace your admin team."

It's closer to shop drawings than policy manuals: small defaults that stop mistakes and delays.

Where "studio intelligence" fits

If your studio is already running tasks, you're halfway there. The next step is using tools that can do the repetitive research work inside a task, with sources you can verify and corrections you can keep.

That's the version of "intelligence" that matters in a small firm: less busywork, fewer dropped details, and fewer surprises.

If you want a north star, use this: a well-designed practice makes "getting paid" feel routine.

FAQ

What is practice design for an architecture firm?

Practice design is applying the same thinking you use on projects (constraints, scope, iteration) to how your studio runs. It's not bureaucracy. It's a few defaults that reduce repeat work, prevent dropped decisions, and keep billing from slipping.

What are the first SOPs a 1–4 person firm should document?

Start with SOPs that protect margin and reduce rework:

• Billing SOP: when invoices get drafted/sent (tie it to "done").
• Decision log SOP: where decisions get recorded and how they're written.
• Phase transition SOP: what changes from SD → DD → CD so handoffs don't drift.
• Scope-change SOP: what you do the moment scope changes.

If you want a starting scaffold, use a project phase checklist and simplify it until you actually reuse it.

How do I stop billing delays without hiring an admin?

Make billing a production step, not an afterthought. The smallest move is to define "done" as "deliverable shipped + invoice drafted/sent same day." If you need help standardizing the math so it doesn't feel heavy, try the invoice calculator.

What's the simplest way to reduce context switching?

Standardize the repeatable objects (deliverable definitions, decision logs, checklists) and keep them in one place. You're aiming to stop translating the same facts across tools, not to replace everything you use.

Where does Toolblocks fit into this?

Toolblocks is building task-centered studio intelligence: tools that reduce the repetitive parts of project work (and the admin drag around it) so small firms can move faster without adding overhead. You can explore more on the architecture industry page and browse workflows on use cases.

About the author

George Valdes is the co-founder of Toolblocks. He previously led product as Head of Product at Integrated Projects (AI-powered Scan-to-BIM) and was Head of Marketing at Monograph. He co-founded Architechie NYC and serves as a board member for the 1735 NY Ave Investments Fund at the American Institute of Architects (AIA). He is based in St. Petersburg, Florida, and is bilingual in English and Spanish.