The small-practice software problem is rarely “Which app is best?” It is that the same decision gets drawn, typed and checked in several places. Each extra handoff creates work and another opportunity for versions to diverge.
An Archinect discussion among small-practice professionals raises exactly this mix of tools, subscriptions and repeated work. The solution is not a universal stack. It is a map of what your practice must produce and which tool owns each piece of information.
Start with deliverables, not subscriptions
List your last three projects. For each, record the outputs clients and authorities actually needed: concept diagrams, planning drawings, coordinated documents, specifications, schedules, visualisations, issue records and handover files. Then mark the tool used and the file that was considered authoritative.
If a door schedule is edited in a model and in a spreadsheet, write down which is master and how changes reach the other. If the answer is “someone remembers,” that is the gap to fix before buying software.
Draw the handoff chain
Follow one change through your workflow. For example: a window size changes. Where is it first approved? Which drawing or model changes? Does it update the schedule? Who checks the specification? What gets issued to the consultant and client? Count the points at which somebody copies information manually.
Mark each handoff automatic, checked manual or uncontrolled. You do not need to eliminate every manual step. You need a deliberate check where errors would be costly. Sometimes a simple issue log is worth more than another licence.
Calculate the whole cost of a tool
Subscription price is only one line. Add training, migration, hardware, consultant compatibility, template maintenance and the time spent exporting and repairing files. Then calculate how often the feature you want is actually used. A specialist tool may be excellent on one project type and unnecessary on the rest.
Run a small pilot on a past project, not the next urgent live issue. Compare time to make a change, number of corrections and clarity of the final handoff. If the new workflow cannot beat the old one on a repeatable task, postpone the purchase.
Keep professional judgement outside the stack
Software does not decide whether a detail is buildable, a product suits the climate or a submission meets local requirements. Assign people to those decisions. If you use AI to draft notes or organise information, review every output against the actual project and applicable rules.
Write a one-page stack policy: where the truth lives; who can edit it; how an issue is named; how a change is reviewed; how files are archived. A small practice can change tools later. It is much harder to recover a decision that was never recorded.
A 30-minute software audit
Pick one recent project and list every place its current area schedule, room names and drawing issue status appeared. Count how many times somebody retyped the same fact. Each manual re-entry is a possible error and a cost. Then identify the authoritative source for each fact. If two tools both claim to hold the final version, settle ownership before shopping for an integration.
For one proposed new subscription, write its annual price plus onboarding hours, migration effort, staff training, file exchange and the cost of leaving later. Compare that total with the specific hours or errors it should remove. Run a pilot on a small live task with an agreed success measure: for example, fewer repeated room updates or faster issue checks. A tool that looks impressive in a demo but adds a parallel model has failed the test.
Do not demand one tool for every design stage. A sketch tool can be appropriate for a sketch. The risk appears when unverified information is copied into the contract documents or a former option remains visible as current. A lean stack has clear boundaries between exploration, approved design and issued information.
The right stack lets a colleague open the project tomorrow and understand what is current. That is a stronger buying criterion than the longest feature list.
Choose one owner for each recurring decision
Draw a small information map for doors, rooms and finishes. For each item, name the source record, the person who can approve a change and every place where the result appears. If the room name lives in the model, the planning schedule and a presentation deck, decide which version is authoritative and when the other two are refreshed. This is a workflow decision before it is a software purchase.
Then try a real maintenance test. Change one approved item in a copy of an old project. Time how long it takes to update drawings, schedules, specifications and exports, including checks. Note which error was most likely to escape. A proposed new subscription earns its place only if it reduces a meaningful problem without creating a different uncontrolled handoff.
Keep a simple exit plan for each tool: who owns the account, where files are stored, how to export them and what happens if the subscription ends. A small practice can become dependent on one person’s login or one proprietary file format. Backups and version naming are less exciting than rendering features, but they make the work recoverable. The goal is not the shortest software list. It is a set of tools whose outputs the team can trust and continue using.
Browse current architecture jobs on Jobs.archi and read our guide to the gap between architecture school and practice for a related next step.
The post One Model, Three Exports, Four Subscriptions: A Small Practice Software Audit first appeared on jobs.archi.