Architecture practice management software
What architecture practice management software is, what it has to handle that generic work tools do not, and how to judge whether a system is built for architects or configured for them.
Every architecture practice runs on the same handful of things: work it hopes to win, work it has committed to, people whose time is finite, fees agreed in advance for work of uncertain extent, drawings issued in sets, and consultants and builders who need answers.
Architecture practice management software is the category of system built to hold all of that as one connected model, rather than as separate tools joined by people remembering.
What makes architecture different
Architectural work has structural features that general work-management platforms cannot express without configuration, and often cannot express at all.
Fees are staged, and the stage is the entitlement. A practice is paid because something happened: concept complete, DA lodged, a set issued. A system that treats a fee as a total cannot represent the event that makes a claim legitimate.
The programme is tied to external approvals. Councils and authorities set dates the practice does not control, and everything downstream moves with them.
RFIs and variations carry contractual weight. They are not tasks with a label. An unanswered RFI is a programme risk. An agreed variation changes what the practice is owed.
Consultants are a third category of person. Not staff, not clients. They have scopes, packages and fee requests, and they need a way in that is neither an employee account nor a client view.
Deliverables are drawings. Issued in sets, revised, and depended upon by dates.
The test worth applying
The useful question when comparing systems is not how many features they have. It is:
When a programme stage moves, what else changes?
In a scheduling tool, a date changes. In a system with a model of an architecture practice, the resourcing plan changes, the deliverable dates change, the claimable fee moves, and the cash forecast moves with it.
That is the difference between software that stores your practice and software that understands it.
Where the categories overlap
To be fair to the general tools: they are excellent at what they are for. They are flexible, mature, and if your work is genuinely generic they will serve you well.
The argument is not that they are bad software. It is that configuring a general work tool until it almost fits an architecture practice leaves the practice maintaining the difference in spreadsheets, conventions and somebody's memory.
How Mudo approaches it
Mudo is built around these structures rather than configured into them. The practice-wide view is the front door, projects are workspaces rather than folders, and the relationships between programme, resourcing, fees and delivery are held by the system rather than by the person who knows.
Common questions
- What is architecture practice management software?
- Software that runs the business of an architecture practice, covering winning work, planning it, resourcing it, delivering it and getting paid for it, using the structures architects actually work in. That means staged fees, programmes tied to approvals, RFIs and variations with contractual weight, consultants who are neither staff nor clients, and deliverables that are drawings issued in sets.
- How is it different from project management software?
- General project management software models work as tasks, people and dates, and expects you to configure the rest. Architecture practice management software already knows what a fee stage is, what a variation does to it, and why a drawing revision matters. The difference shows up in the parts a general tool cannot represent, which is where practices end up keeping spreadsheets.
- Do small practices need it?
- Small practices need it more than large ones, because they have no operations team absorbing the gaps. In a three-person studio the director is the resourcing plan, the fee tracker and the QA process, and the cost of that is invisible until it is not.
- What should I look for when comparing systems?
- Ask what happens when a programme stage moves. If the answer is that a date changes on a chart, the system is a scheduler. If the resourcing plan, the deliverable dates and the claimable fee all change with it, the system has a model of your practice rather than a set of features.
Try it on a real project
Free for solo practices: one user, two projects, no card.