First week with your team

This is how to start Bucky with a team without deploying it to the whole firm, and how that same project then runs the development. Do not provision every seat first. Do not treat MCP or the API as the rollout — those surfaces are for developers and agents, documented under API and MCP.

What “done” looks like this week

One live project on an address you already know, with a cited zoning and feasibility read, and a clear choice of who (if anyone) sees it.

Day one — champion and address

1. Sign in as the person who will run the first site.
2. Open the Projects map. Search the address, drop a pin, or draw the site.
3. Use Project Scout to explore, then Review & create to save a project. See site exploration.
4. Read zoning and feasibility on that site before you invite anyone.

If the site does not work, you found out on day one. That is a successful first use.

Then decide who sees it

Use people on a project. The short version:

• A colleague who will run analysis → add them to the team.
• A client or principal who needs to see the live workspace → viewer invite or share link (Professional).
• A planner, lender, or neighbour you are tracking → stakeholder (no login).
• An architect or builder you may hire → partner company (no login).
• The whole office → do not add them this week.

If nobody else needs to see the project yet, stop. The champion can keep working alone.

Week two — one invite, then seats

If someone else will actually work in Bucky, invite that one person. Add company seats when sharing is habitual, not because a roster exists on paper.

After week one — the same project

Bucky stays on that project through screening, feasibility, entitlement, and team formation. Parties join when the stage needs them. The stage table is on people on a project.

Construction execution is not Bucky. The file remains the sourced record you hand to the people who build.

Prompts on the map and in chat

Example prompts for Scout and BuckyAssist: Prompting BuckyAssist.