One reason to adopt Computational Design as a problem-solving methodology is the ability to do more with what you have. When it comes to starting a project, the same tasks are often performed many times throughout the year — so why not automate them?
Project startup in an architecture firm is a reliable sequence of repetitive work. A new project number gets assigned. Folders get created. A Revit model gets set up from a template. Levels get placed. Grids get drawn. Sheets get numbered. Views get organized. It's not complex work — but it takes time, and it introduces inconsistency every time a different person does it differently.
The most valuable automation isn't the dramatic kind. It's the quiet elimination of the work that happens before the real work begins.
What Project Startup Actually Involves
Before a designer can meaningfully begin work on a new project, a set of infrastructure tasks has to be completed. In most firms, this is handled ad hoc — someone does it, probably the person who has time, and the result varies depending on who that is.
Typical Project Startup Tasks
- Creating project folder structure in the file system or cloud drive
- Setting up the Revit model from the firm's template
- Placing building levels based on program or site information
- Creating and numbering a sheet set for the project type
- Populating project information fields (name, number, address, client)
- Setting up views and view templates appropriate to the project phase
- Creating a project-specific title block with correct information
Done manually, this might take two to four hours per project. Done inconsistently, it creates downstream problems: sheets that don't match the firm's numbering convention, view templates that were copied from the wrong source, project information fields that are blank or wrong because nobody updated them from the template defaults.
The Computational Approach
A Dynamo script — or a Python script run through Revit's API — can execute most of these tasks in under a minute. The inputs are minimal: project number, project name, client name, address, building type, number of floors, floor-to-floor height. From those inputs, a well-built script can produce a fully configured starting model.
The script doesn't replace the designer's judgment — it handles the mechanical work so the designer can start with judgment sooner. The first thing they open is a model that already reflects the project's basic parameters, with the right levels, the right sheets, and the right information in place.
Why This Matters at Scale
For a firm running ten to twenty projects per year, automating project startup saves somewhere between twenty and eighty hours annually — depending on project complexity and how thorough the current manual process is. That's a real number, but it's not the most compelling part of the argument.
The more compelling part is consistency. Every project that goes through the automated startup process is configured the same way. Sheets are numbered the same way. Views are organized the same way. Project information is complete and accurate. When you bring a new person onto a project, or when a project manager needs to review the model, the structure is familiar regardless of who started it.
Consistency reduces cognitive load. It means less time orienting yourself to how this particular project is set up, and more time doing the work that actually requires your expertise.
Building the Script
The technical implementation depends on your firm's software stack and what the startup process actually looks like. A Dynamo graph is usually the right starting point — it's visual, it's legible to people who aren't programmers, and it integrates directly with Revit without requiring a separate installation.
The typical development process goes like this: document the current startup sequence step by step, identify which steps are genuinely parametric (they vary based on inputs) versus fixed (they're always the same), build the fixed parts first as a template, then add parametric inputs for the variable parts. Test on a few real project types before deploying firm-wide.
The maintenance burden is lower than most people expect. Once the script is working, it needs updating when the firm's standards change — a new sheet numbering convention, a new view template structure — but it doesn't require ongoing attention. It just runs.
Automation isn't about removing people from the process. It's about removing the parts of the process that don't need people.
Where to Start
If your firm doesn't have any computational design tools in place yet, project startup is one of the best places to begin. The scope is contained, the inputs and outputs are well-defined, and the value is immediately measurable. It's also a good way to build internal confidence in the methodology — when people see a script produce a complete, correctly configured model in under a minute, the conversation about what else might be automatable becomes much easier to have.
The goal isn't to automate everything. It's to identify the work that follows a consistent pattern, remove it from the designer's plate, and redirect that time toward the work that requires their specific expertise and judgment. Project startup is a clear example of the former. Start there.