TL;DR: Profitable architecture practices don’t manage projects differently on the design side. They manage them differently commercially. That means fee proposals built from real stage-level delivery data; time tracked by RIBA stage so overruns are visible early; a process for capturing and billing variations before they become write-offs; and live WIP visibility so the practice director knows where every project stands, not just when the invoice goes out.
The RIBA 2025 Benchmarking Report shows the profession posting its highest ever recorded revenue at £5 billion, up 24% year on year. Good news, on the surface. But the picture for smaller practices is different: those with 1–4 staff are seeing flat revenue and a slight fall in profits. The profession is growing. The margins aren’t spreading evenly.
That divergence isn’t about design quality. It comes down to an architect’s project management at the operational level: how fees get set, how time gets tracked, how variations get captured, and whether a practice director can see where each project stands on a given Tuesday, not just on invoice day.
Here’s what the profitable end of the market does differently.
What do profitable architecture practices do differently in how they manage projects?
Profitable practices share four operational habits: fee proposals built from actual stage-level delivery data, not estimates; time tracked by RIBA stage so consumption is visible before overruns harden; a disciplined process for capturing and billing variations before they become write-offs; and live WIP (work in progress) visibility so the practice director knows each project’s margin position without waiting for the invoice.
These four habits aren’t independent. A practice that tracks time by stage has better data for future fee proposals. A practice with real-time WIP visibility spots variations earlier. They compound. Their absence compounds, too, which is why the same projects lose margin the same way, year after year.
Why fee proposals are where most margin loss starts
Most architecture practices don’t underprice their value. They overestimate how efficiently they’ll deliver. Without time data per RIBA stage from completed projects, fee estimates default to optimism. Stage 3 runs long. Stage 4 gets squeezed to compensate. By the time the invoice goes out, the project that looked profitable on paper has written off a week of senior time.
The fix isn’t to charge more. It’s to build the fee from actual delivery data: how long did Stage 2 take on the last three comparable projects? Where did Stage 4 run over? Research with UK architecture practices shows that chargeable time in the sector typically runs at 60–80% of total hours logged. If fee proposals assume 80% and the practice delivers at 65%, that gap comes out of the margin on every project.
Sound familiar? It’s one of the most consistent patterns we see.
Why time tracking at RIBA stage level matters more than time tracking alone
Most practices track time. Far fewer use that data to understand how they’re actually delivering. The difference is granularity.
When time is recorded by project but not by stage, you get a total that tells you the project ran over. It doesn’t tell you where. That makes it hard to improve the next fee proposal, because you can’t see which stages the practice consistently underestimates.
Stage-level tracking reveals patterns across the portfolio. If Stage 3 is routinely consuming 30–40% more time than budgeted, that’s not a client management problem. It’s a pricing problem. For a practical look at what good time tracking for architects involves, including the five criteria worth evaluating any tool against, that post covers the details.
There’s a related dimension: utilisation. RIBA benchmarking data on capacity planning for architects shows many practices are targeting the wrong utilisation figure altogether. Stage-level time data and utilisation visibility need to work together. You need both.
Variations: the revenue that disappears before the invoice
Variation revenue is typically lost in one of two ways: the variation is identified but not raised with the client quickly enough, or it’s logged informally and forgotten before it’s billed. Either way, it becomes a write-off. Practices that reliably recover variation revenue log it the moment it occurs, quantify it in hours and fees, and bill it before the project moves to the next RIBA stage.
This is almost always a systems problem, not a client relationship problem. The hesitation is understandable. Raising a variation feels like an awkward conversation, especially on a project the practice values. So it gets deferred, then deferred again. Then Stage 4 starts, and the Stage 2 variation that was “just a few hours” is three months stale.
Fresh Projects’ guide to managing scope creep makes the point well: a clear scope definition at the outset, paired with a process for promptly raising variations, doesn’t damage client relationships. It protects them. Clients who are informed of cost implications early are far less surprised than those who receive an unexplained invoice at the end of a stage.
WIP visibility: knowing where a project stands before the invoice goes out
Work-in-progress visibility means knowing, at any point in a project, how much of the fee has been consumed relative to how much has been earned. Without it, practices find out a project is loss-making when they raise the invoice. With it, they can intervene: reset the scope, issue a variation notice, or adjust the resource while something can still be done about it.
Research on revenue recovery in architecture and engineering firms highlights a pattern most practice directors will recognise: by the time an overrun is visible in the accounts, the project is usually too far advanced for anything meaningful to change. Real-time WIP visibility moves that moment of recognition forward by weeks. That’s the window where intervention is actually possible.
Spreadsheets don’t deliver this. The data is always a week stale, usually more. A connected system that feeds timesheet data into the project view in real time does.
What the right infrastructure looks like for an architecture practice
None of the above works if the tools aren’t connected. Time tracked in one system, projects managed in another, and invoices raised in Xero without a live feed between them means data that’s always out of date. You can’t intervene on WIP you can’t see. Our post on software stack for architects covers the six connected layers worth building, from project management through to debtor automation and reporting.
For UK architectural practices, WorkflowMAX is built around this setup. It handles fee tracking, WIP, variations, and timesheets in a single system, structured by RIBA stage, with direct Xero integration. The platform does the job. What determines whether it actually improves profitability is how it’s configured: stage templates that reflect how the practice delivers work, charge-out rates that account for real overhead, and billing rules that match the firm’s contracts. If you want to see what implementing WorkflowMAX properly involves for a practice of your size, that page covers the methodology.
The platform choice matters. But it’s the configuration that separates practices that see the change from those that don’t.
Tighter operations, not better architecture
Profitable practices aren’t doing better architecture. They’re running a tighter commercial operation: fees grounded in real delivery data, time records that show where the hours actually go, a process for capturing variations before they disappear, and visibility into WIP before it’s too late to act.
If you’re not sure where your practice sits on any of these, an App Fit Sprint is where we usually start. It’s a structured review of your current systems and processes, with specific recommendations for what to change. No commitment beyond the session.
Book a discovery call to find out what that looks like for your practice.
