Build
The Build tab turns your architecture into a develop-and-test plan. It lays out every buildable component in the order it can actually be built — so you can run planning workshops, see what’s ready to start now, and understand what’s waiting on what.
It answers a question your model already knows the answer to: given everything we’ve designed, what can the team build first, and what has to wait? You never draw the plan by hand — ArchRepo derives it from the relationships and data you have already modelled. Open it from the project’s Build tab.
“Build” here means Develop and Test. Every component has a develop stage and then an integration test — and test means proving it works together with the components it depends on, not just on its own. So this plan is as much about the order things can be tested together as the order they can be developed. That difference drives most of the waiting you will see on the timeline.
Two Views
| View | What it shows | Best for |
|---|---|---|
| Board | Components grouped into build waves — each wave is a layer of the dependency order. | A quick read of what’s ready now versus later. |
| Timeline | A schedule with a day axis: every component has a develop bar and an integration-test milestone. | Sequencing, spotting long chains, and workshop discussion. |
Switch between them with the Board / Timeline toggle.
Reading the Timeline
- Develop bar — how long a component takes to build, from its Estimate (T-shirt size); see Where the Durations Come From. A faded, dashed bar means no estimate is set, so a default (Medium) is assumed.
- Integration-test milestone (◇) — the point where the component’s own build is done and every part it integrates with has completed. A dashed connector shows it waiting.
- AC chip (✓ N AC) — how many acceptance criteria the component carries, a quick gauge of its test scope.
Where the Durations Come From
Each component’s develop bar length comes from its Estimate — the T-shirt size (XXS–XXL) set on the item, which ArchRepo converts to working days. To change how long a component takes on the timeline, update its Estimate. A component with no estimate is drawn with a faded, dashed bar and a default of Medium is assumed.
The working-day value for each T-shirt size is configurable per project — see T-Shirt Size Durations in Project Settings.
Colour Tells You Readiness — and Progress
Bars use two colour families. This is the heart of the view: the timeline’s job is to show what’s ready to build and what’s close.
Design readiness — for components not yet started, how close each one is to being buildable:
| Colour | Meaning |
|---|---|
| Grey | Waiting for design |
| Amber | Waiting for design review |
| Yellow | Waiting for reviewers |
| Lime | Waiting for design approval |
| Mint | Ready to build |
| Red | Blocked |
Build progress — once work has started, set each component’s Build Status and the bar reflects it:
| Colour | Meaning |
|---|---|
| Blue | In Development |
| Plum | In Test |
| Green | Done |
Built items are hidden by default. Once a component’s Build Status is Done it drops out of the plan — it’s finished, so it’s just noise for what’s left. Bring built items back with the build status filter set to Done.
Focus on One Component’s Impact
Select a row and choose Focus impact to narrow the whole view to just that component and everything connected to it — what it’s waiting for, and what’s waiting on it. It’s the fastest way to answer “if this slips, what’s hit?”
Filters and Search
- Status filter — narrow to a single readiness or progress state (for example Ready to build, Blocked, In Development, or Done).
- Search — dims the rows that don’t match, so a name or reference stands out without losing context.
- Account for Design Phase — by default every component starts at day 0 (build-parallel), so structure and dependencies read clearly. Turn this on to push each component’s start to when its design is complete — surfacing where design, not build, is the bottleneck.
Using It in a Planning Workshop
- Start with Ready to build — that’s the buildable frontier the team can pick up now.
- Filter to Blocked to see what’s held up by a contract that isn’t design-complete yet.
- Read the readiness colours to spot what’s close — push a review and it unlocks.
- Use Focus impact to reason about a single component’s ripple before committing to a sequence.
- As work begins, set Build Status on components — In development, In test, Done — and the plan keeps pace, dropping finished work out of view.
Want to know how the order is worked out — why one component waits on another? See How Build Dependencies Are Worked Out.