Most studios choose software the same way: a principal sees a demo, likes it, and announces it on Monday. Six weeks later the project architects have quietly gone back to email, and nobody wants to raise it because the decision has already been paid for. The problem was never the product. It was that there was no method — no agreed criteria, nobody weighting them, and no way to tell a real objection from a preference.
This is a framework for making that decision properly. It takes about a fortnight, it needs four people rather than one, and it produces a choice the studio can actually defend six months later.
The trade-off underneath every option
Every tool you will look at sits somewhere on one axis: depth versus setup cost. At one end, software that does very little but works on day one. At the other, platforms that can model anything provided somebody builds and maintains the model. Neither end is wrong; the mistake is choosing without knowing which end you need.
The honest question is who, by name, will own the configuration in eighteen months. If there is no answer, you belong at the shallow end regardless of how impressive the deep end looked in the demo.
Weight the criteria before you see a demo
Criteria chosen after a demo are just a rationalisation of what you already liked. Agree and weight them first. A workable starting set for a design practice, which you should adjust rather than adopt wholesale:
| Criterion | Weight | What you are testing |
|---|---|---|
| Fit to how you actually work | 30% | Phases, drawings and approvals modelled natively, not configured in. |
| Adoption friction | 25% | Can a busy project architect keep it current on a bad week? |
| Mobile and site use | 15% | Whether decisions made away from a desk reach the project. |
| Consolidation | 15% | How many other tools it lets you retire. |
| Total cost over 3 years | 10% | Licences plus configuration, migration and training. |
| Exit | 5% | How your data comes out if this goes wrong. |
Weights are the argument. Have that argument once, in the room, before anyone opens a product page.
Who is in the room
Four roles, and the decision degrades sharply if any is missing. A principal who owns the budget and the fee consequences. A project architect who will live in the tool daily and whose abandonment kills it. Whoever handles invoicing, because hours and fees have to reconcile. And whoever will own the configuration — the person who cannot say no later if they were never asked.
- Principal — owns the fee consequences and the budget.
- Project architect — the daily user, and the one who can kill it by quietly not using it.
- Whoever invoices — hours have to reconcile with what goes out the door.
- The eventual owner of the configuration — veto rights, because they inherit the maintenance.
Score against a real project, not a demo
A demo is a performance of the happy path. Instead, take one live project — ideally a slightly messy one, mid-phase, with a consultant involved — and run two weeks of genuine work through each shortlisted tool. It costs more than watching a sales call and it is the only step that reliably predicts what happens in month three.
Score each criterion out of five, multiply by the weight, and look at the total. The number rarely decides anything on its own, but the places where two tools diverge sharply are exactly where the real conversation is.
If a tool cannot survive two weeks of one messy live project, it will not survive a studio.
When the team disagrees
Disagreement usually means the weights were never really agreed, so go back to them rather than arguing about products. If the principal and the daily user split, weight the daily user more heavily than feels comfortable: a tool the principal likes and the team abandons produces nothing, while a tool the team adopts and the principal finds merely adequate still produces a working studio.
Decide, and write down why
Record the weights, the scores and the one thing you knowingly gave up. In a year, when someone asks why you are not using whatever is being marketed hardest that month, that document is the answer — and if the decision does turn out to be wrong, it tells you which assumption failed instead of leaving you to start from zero.
Once you have chosen
Selection is the easier half. Most tools that fail in studios were chosen sensibly and rolled out badly, which is a separate discipline with its own failure modes — a pilot project, a migration plan, and a month of somebody answering questions.