A bespoke timber-building brief for an architect or developer should protect the design intent while making the project interfaces visible. It is not a request for the architect to surrender design control, and it is not a substitute for the locally responsible team’s approvals, engineering or site coordination. It is the shared record that lets a factory discussion begin with the right questions.
For a bespoke route, the quality of the brief matters more than the number of inspiration images. A coherent project note shows what the building must achieve, which facts are confirmed, where the team needs input and who owns each local interface.
Describe the project before describing the product
Begin with the building’s purpose, user group, destination market and stage of development. Is it a residential scheme, a hospitality element, a commercial space, a repeatable development concept or another application? Explain what is driving the design: site relationship, daylight, views, room sequence, planning envelope, client brief, visual language or a specific construction logic.
These facts make it possible to decide whether a timber-building factory package can be evaluated at this stage and which further technical or project information would be needed.
Make the project team and decision path clear
Name the professional roles that are already appointed and identify who is responsible for design coordination, local regulations, structural review, services, foundations, procurement and installation. A project does not need every consultant in place before a first conversation, but unallocated responsibilities should be marked as open rather than folded into an assumed supply scope.
This is especially useful where the architect is developing a concept for a client or developer. It preserves a clear boundary between the factory’s response to an agreed brief and the local team’s control of the project as a whole.
Share the minimum viable design package
A useful early package may include site context, plan logic, approximate dimensions, elevations or massing, key sections, a schedule of known openings, visual references and notes identifying which elements are fixed versus exploratory. The materials should explain decisions rather than merely illustrate atmosphere.
For example, an image can show desired rhythm or scale; a plan can show circulation; a short note can explain why a particular roof line matters. The factory discussion can then focus on the questions relevant to the proposed package, not on guessing the intent from a single image.
Record the technical questions honestly
List the questions the design team wants answered, such as the information needed for a proposed configuration, the drawing stage required for an order-specific discussion, the relationship between a factory package and local work, or the evidence needed to evaluate an element. Do not present an unverified standard, performance value, certificate or local approval outcome as a resolved project fact.
The construction guides can help frame a technical conversation, while the Glulam Homes route provides relevant context where glulam is being assessed. Neither replaces project-specific verification by the locally responsible team.
Separate factory package from local project scope
Eurodita can assess a proposed factory package, configuration and agreed documentation against the supplied project brief. Local approvals, engineering, foundations, groundworks, services, installation and destination-market coordination remain with the buyer and locally responsible project team unless a written agreement says otherwise.
That separation should appear in the brief itself. It reduces the risk that a manufacturer’s response is later described as a complete construction service when the local work has not been defined.
Give the factory a workable programme context
It is useful to state the client’s decision stage, any known procurement milestone and whether the enquiry is a one-off scheme or a repeat development concept. A programme should be context, not an assumed delivery commitment. It helps the team decide what needs to be resolved first and whether the next output should be a clarification list, a configuration discussion or an order-specific proposal.
A concise architect and developer checklist
- project purpose, market and stage;
- lead design and local coordination roles;
- site and layout context;
- known dimensions, opening logic and design references;
- fixed decisions and open questions;
- factory-package expectations;
- local scope owners and next decision date.
A bespoke brief that names both ambition and boundaries makes the first factory response more useful, more comparable and safer for every party to rely on.
Create a design decision register
Before the next meeting, divide the brief into three columns: decisions that are client-led, information that must be supplied or checked by the locally responsible team, and questions for the factory package discussion. Client-led choices might include spatial priorities, visual references and procurement objectives. The local column can cover site information, approvals and specialist inputs. The factory column should ask only about the scope that can be assessed from the supplied project record.
This simple register prevents the brief from turning into an unstructured collection of images. It also gives a developer or architect a clear way to explain progress to the client: what has been selected, what is awaiting local verification and what requires a response from the proposed manufacturing route.
Create a design decision register
Before the next meeting, divide the brief into three columns: decisions that are client-led, information that must be supplied or checked by the locally responsible team, and questions for the factory-package discussion. Client-led choices might include spatial priorities, visual references and procurement objectives. The local column can cover site information, approvals and specialist inputs. The factory column should ask only about the scope that can be assessed from the supplied project record.
This simple register prevents the brief from turning into an unstructured collection of images. It also gives a developer or architect a clear way to explain progress to the client: what has been selected, what is awaiting local verification and what requires a response from the proposed manufacturing route.