Studio Setup & Systems

When architects imagine setting up a studio, they picture the space: the long table, the pinned drawings, the good coffee. Those matter for morale and culture, but they are not what makes a practice deliver. The real infrastructure of a studio is invisible: the way files are named, the templates every proposal starts from, the single place where the current version of a drawing always lives, the checklist that runs before a set goes out. This machinery is boring precisely because it works; when it is absent, the symptoms are dramatic and familiar. Two people editing different copies of the same plan. A revised drawing sent to site while the old one is still on the contractor's table. An afternoon lost hunting for last year's specification. A new hire who cannot find anything and dares not ask. Every one of those is a systems failure wearing the costume of a people problem. The founder's job is to build the quiet infrastructure early, while the practice is small enough that habits form easily, so that the studio's reliability does not depend on any one person remembering everything. Culture is what you feel in the room; systems are what let the room deliver.

The first tangible decision is where to work, and the honest answer for most new practices is: as little space as you can respectably manage. Rent is a fixed monthly cost that eats runway whether or not a fee arrives, so a founder should resist the instinct to sign an impressive lease early. Working from home suits the true solo start; a coworking desk or a shared studio suits the next stage, giving you an address, meeting rooms and other professionals to spar with without a long lease; a dedicated office earns its cost only when a team, client visits and the need for a settled culture justify it. Whatever the stage, a studio needs a few non-negotiables: reliable power and a backup, genuinely fast and stable internet because your files increasingly live in the cloud, a space you can bring a client into without apology, and somewhere drawings can be laid out and marked up. In India, plan realistically for power cuts and connectivity gaps, an inverter or UPS and a mobile-data fallback are not luxuries but continuity insurance, and a disciplined backup routine, ideally automatic and off-site in the cloud, protects you against the theft, fire or failed hard drive that can otherwise erase years of work in an afternoon. Location has a soft value too: a studio a client can reach easily, or one near the kind of work you want, quietly shapes who walks through the door. But none of that justifies overpaying early. Let the premises follow the practice; do not let an ambitious address dictate the practice you can afford to be.

A studio's tools fall into a few clear layers, and the discipline is to choose deliberately in each and then standardise across the team. There is the design and documentation layer, CAD and increasingly BIM authoring tools, plus rendering and image editing. There is the communication and project layer, email, a messaging tool, a task or project tracker, and a way to run and record meetings. There is the business layer, accounting, invoicing, time-tracking and a place to store contracts. And underneath everything sits storage and the common data environment, discussed next. The temptation in a young studio is tool sprawl: everyone uses their own favourite, files scatter across personal drives, and knowledge lives in individual heads. Resist it. Pick one authoring standard, one storage system, one project tracker, and make them the practice's, not the individual's. Budget honestly for genuine licences rather than pirated software, both because professional liability and client trust demand it and because subscription costs are a real line item to plan around. The aim is not the largest toolkit but the smallest coherent one that everyone actually uses the same way, because a modest set of tools used consistently beats a brilliant set used differently by every desk.

If a studio adopts a single discipline, make it this: a common data environment, or CDE, one agreed, managed place where the current information for every project lives, with clear rules about who can edit, how versions are controlled, and when information moves from 'work in progress' to 'shared' to 'issued'. The CDE is the idea at the heart of modern collaborative practice and information management standards such as the ISO 19650 series, and while those frameworks were written with large BIM projects in mind, the principle scales all the way down to a two-person studio saving to one cloud folder with a naming rule. The value is that everyone, and every consultant and contractor, is always working from the same, latest, correct information, which quietly eliminates the single most expensive category of mistakes: people building or coordinating against a superseded drawing. A CDE does not require expensive software to begin; it requires agreement and habit. Decide where files live, how they are named and versioned, what 'issued' means and who may do it, and then hold the line so that nobody keeps a private copy on a laptop. As the practice grows into serious BIM and multi-consultant coordination, formalise it toward the ISO 19650 way of working, but start the habit on day one.

Nothing screams 'systems' less and matters more than how you name and arrange files. A consistent project folder structure and file-naming convention are the humble backbone of a reliable studio, and they cost nothing but the discipline to agree them once and honour them forever. Decide a standard folder tree that every project gets, so anyone can open any job and know instantly where the drawings, the correspondence, the consultants' inputs, the photographs and the issued sets live. Adopt a naming convention that encodes what a file is at a glance, typically the project code, the discipline or type, the drawing or document identifier, and crucially the revision, so that 'the latest one' is never a matter of opening files to check dates. Never bury version history in filenames like 'final-final-v3-USE-THIS'; use a clear, incrementing revision system and a superseded folder for old issues. These rules feel pedantic until the day a drawing goes to site, a dispute arises, or a new team member joins mid-project, and then they are the difference between a two-minute answer and a lost afternoon. The test of a good file system is simple: could someone who has never touched the project find the current issued plan in under a minute? If not, the system is costing you money you cannot see.

Every task a studio does more than twice deserves a template, because a template is how a practice bottles its hard-won standard and pours it into every new job without reinventing it or forgetting a step. The obvious ones are drawing sheets and title blocks, so every drawing that leaves the studio looks unmistakably like your practice. But the higher-leverage templates are the documents that protect and speed the business: a fee-proposal and letter-of-appointment template so no scope or payment stage is ever left vague; a standard set of specification clauses; a site-report and minutes format; a drawing-issue sheet and transmittal; an email template for chasing payments; a project-startup checklist and a drawing-issue checklist. Each one turns a decision that used to be made anxiously from scratch into a considered default that already reflects the firm's best thinking. Templates also make delegation possible: a junior armed with a good checklist and a proven template can produce reliable work far sooner than one starting from a blank page. Build your templates from real projects as you go, keep them in one known place, and review them when a project teaches you something. Over years, this library becomes one of the practice's most valuable and least visible assets, the accumulated intelligence of everything you have learned about how to do the work well.

The reason all of this matters is that a practice that runs on individual memory has a hard ceiling: it can only be as large and as reliable as the founder's attention. Systems raise that ceiling. When the file standard, the CDE, the templates and the checklists carry the knowledge, a new hire becomes productive in days rather than months, work can move between people without dropping, and the founder is freed from being the single point of failure for everything. This is precisely the moment growth either compounds or collapses. The studios that scale gracefully from two people to twenty are almost never the ones with the most talent; they are the ones whose quiet infrastructure was strong enough to absorb more people, more projects and more complexity without the wheels coming off. Build the systems while you are small and it costs you a little discipline; try to retrofit them during a growth spurt and it costs you chaos, errors and burnt-out staff. The goal is a studio whose reliability is designed in, not heroically improvised each day, so that everyone, including you, can spend their best energy on the architecture rather than on hunting for the right file. That is the whole quiet promise of systems: they turn a fragile group of talented people into a durable practice.