Architect, AI Design — Residential Developer (Canada)

We are a property developer in Canada. We design, build and hold apartment buildings. We run the company on software we write ourselves.

This seat is the future of our architecture department.

Here is what we mean. Today a concept is produced the way it has been produced for forty years: a site arrives, someone opens a model, and weeks later there is a set of options that nobody can fully explain. We want the person who looks at that and asks a different question: not how do I produce this one, but how do the next twenty get produced, correctly, in hours, with the checks built in. You will produce concepts yourself from day one with the best current tools, because the projects do not wait. And you will turn that production into a system, with our software lead, so that each project makes the next one faster and safer.

We are asking for a rare combination and we know it: real architectural depth, fluency in the current generation of design and feasibility tools and the judgment to evaluate them, and enough technical literacy to build yourself, or with an engineer, rather than hand them a wish list. If you have two of the three and are honest about the third, read on. If you have one, this is not the seat.

WHAT YOU OWN

1. The design logic. What makes a unit work, what makes a plan buildable, what a developer needs to see to d ---------- . Encoded, not remembered.

2. Concept production. Site to option set: massing, unit mix, floor area, parking, yield, and whether each option clears spatial separation and egress. Delivered on dates, with the best tools available today, from your first week.

3. The kit. Our unit types, room standards, families and templates, so every concept starts from a library rather than a blank model.

4. The constraints. Zoning envelopes, setbacks, height, parking, limiting distance and unprotected openings, encoded from authoritative sources and tested against projects we have already built.

5. The generation system, with our software lead. Intake, generation, numbers, checks, output, driven by our AI agents. You bring the domain and the design logic; he brings the platform.

6. The checks. Rule checks that run on a model before anything is issued, so a municipality, an engineer or a supplier never finds a gap before we do.

7. The learning loop. Municipal comments, engineer comments, site deviations and cost actuals feed back into the kit, the constraints and the checks, every project.

8. Tool evaluation. You know the current platforms, what each is good for, where each breaks, and when to build instead of buy. You make those calls with evidence and you revisit them as the tools change.

WHAT YOU DO NOT OWN

Design direction. What the building should be is d ---------- at a gate by our founder against options and criteria. Your job is to make that decision easy and well informed.

Process control. Drawing control, gates, approvals, consultants and change control belong to our design manager, who gates your work the same way they gate an outside firm.

HOW THIS SEAT IS MEASURED

Two numbers, from month one. Concepts shipped on their dates. And hours per concept, falling every quarter. The first stops the system from swallowing the work. The second stops the work from swallowing the system.

WHERE IT GOES

The seat grows with what it builds: the feasibility product for partners, the design technology function, and if it goes as we intend, the head of design over both production and process. We hire people who have done the job and then widen the job.

WHAT WE NEED YOU TO HAVE DONE

• An architecture degree and at least meaningful experience in practice, including residential design development taken through permit. You can design a unit that works and you can tell when one does not.
• Used at least two of the current site-planning and feasibility platforms on real projects, for example TestFit, Forma, Giraffe, Archistar, Higharc, Hypar, Skema, Finch, Deepblocks, or built the equivalent in Grasshopper or Dynamo, and you can say precisely what each gets right and where it breaks.
• Built or led a design-automation workflow that other people used after you built it: a Grasshopper or Dynamo definition, a Revit API or pyRevit tool, a Python pipeline. Something that ran in production, not a personal experiment.
• Used a large language model or an agent inside a real design or feasibility workflow, not a chat window: tool calling, structured outputs, an MCP server, an agentic coding tool. You can say what it got wrong and how you constrained it.
• Read and applied a building code's spatial separation and egress provisions on a real project. The Canadian code is useful, not required; you will learn ours with our design manager and our consulting architect.
• Produced a concept or feasibility package inside a week that a developer d ---------- on.
• Remote-experienced, with a working overlap into the Canada business day, and able to explain what a tool does and cannot do to an owner who is not technical.

Useful, not required: production software engineering; Canadian zoning or NBC Part 9; Speckle, IFC or open BIM tooling; having worked inside a developer rather than a practice.

NOT A FIT

A portfolio of renders. A computational designer who cannot design a unit. An architect who has never automated anything. A software engineer without the architecture. Anyone who describes a platform by its marketing page rather than by where it broke on their project.

HOW TO APPLY

Start your reply with the word ENVELOPE. Applications without it are not read.

Answer these five. Short is fine. Specific is essential. Vague answers are the fastest way out.

1. Compare two of the platforms you have actually used, for a four-unit wood-frame townhouse on a narrow infill lot. What does each get right, where does each break, and what would you not trust either for?

2. That lot has limiting-distance limits on both side walls. What is the first calculation you run, what does it constrain, and how would you encode it so a system applies it correctly to the next lot?

3. You have produced one concept the conventional way. Describe, concretely, how you would make producing the next twenty a system: inputs, steps, what you automate first, what stays human, where the checks live, and how it fails safely.

4. Something you built or ran that used a language model or an agent in a real workflow. What did it call, what did it get wrong, and how did you constrain it?

5. A concept or feasibility you produced in under a week that went to a developer's decision. What was in the package, what was d ---------- , and what did you get wrong?

Include a link to something you built that we can open: a repository, a Grasshopper or Dynamo package, a Speckle stream, or a short recording of a definition running. Applications without a working link are not read.

OUR PROCESS

We read replies within two business days. Shortlisted candidates get a fictional work sample: a real lot of ours with its real constraints and a public zoning source, forty-eight hours, any stack you like. We ask for two things: the option set with its numbers, and one page on how you would make the next twenty a system. Then one call with our founder and our software lead. Then an offer. This seat is long-term and we would rather find the right person than fill it fast.