ScopeRunway — Pre-Alpha Walkthrough

Thanks for taking a look. This is a working pre-alpha, not a finished product — read the honesty notes below before you start, they'll save you a surprise.

Before you start — what this is and isn't

• Your data lives only in your browser. There's no account and no server-side copy. Everything is saved to this browser's local storage. Clearing site data, switching browsers, or switching devices loses it — export before you do either (Export JSON on any project page gets you a file you can re-import).
• Multi-currency. Pick EUR, USD, GBP, AED, SAR, AUD, or RSD when you create a project (or change it later in Project Info → Settings). Every figure on that project — typed in or AI-extracted — follows the currency you picked; there's no FX conversion between projects, and no mixing currencies within one project.
• Desktop only. No mobile layout.
• This is pre-alpha. Some rough edges are expected — that's what this review is for.

1. Get in

You'll have a link and an access code from me directly. Enter the code once — it's remembered for a year in this browser.

2. Create a project

From the project list, New Project. You'll set:

• Project name and sector (Residential, Commercial, Industrial, …)
• Currency (EUR, USD, GBP, AED, SAR, AUD, RSD) and target budget as a whole number in that currency
• How to start the breakdown:
  • Blank project — three placeholder categories to edit from scratch
  • Import from file — load a previously exported .json
  • Create with AI (beta) — upload a project brief (PDF/DOCX/TXT/MD, up to 3 files) and the app drafts a starter breakdown: facility type, sector, and scope items, all editable before anything is saved. No brief handy? There's also an offline path — import a prepared *.semantic.json with no API call at all. It's labelled beta in the app for a reason — check what it produces before trusting it.

3. Build the physical hierarchy — Site → Facility → Floor

This is the physical structure the project sits on, separate from the fee breakdown in WBS below. It drives what shows up in Deliverables later, so worth getting right before you move on.

• Site — under Sites & Facilities on the project page, + Site. Set a code, name, site type, and area.

• Facility — + Facility under that site. Set a code, name, facility type, gross floor area (GFA), and how many floors above and below grade it has. The facility type comes from a template library (e.g. "MultiFamily") the project can pick as its active template.

• Floor — built entirely on the Deliverables → Facility page, in the Floors panel above the deliverable table. Three ways to populate it:

  • + Add floor — adds one blank row at a time.
  • Auto-generate — builds a full floor stack from the facility's floors-above/below counts: basements numbered B01, B02… (deepest first), a mandatory Ground Floor, "Typical" floors filling the middle, and a Roof floor on top. This replaces any floors you've already defined and resets their deliverable assignments, so use it early, not after you've already ticked boxes.
  • Paste rows — paste tab-separated rows from Excel (LABEL / NAME / USE / GRADE) for a floor list you already have elsewhere.

  Each floor row has a Label (short code, e.g. GF), Name (e.g. "Ground Floor"), Use (dropdown), and Grade Position (Above / At grade / Below). Rows are drag-reorderable; removing a floor also removes whatever deliverables were assigned to it. A small badge next to "Floors" flags when your defined floor count doesn't match the facility's declared floors-above/below — it's a nudge, not a hard block.

  No demo data handy? Load Demo Data on the Facility page seeds one site, one facility, and six floors so you can see the shape of it immediately.

4. Break down the fee — WBS

Open WBS. This is the core of the tool: your target budget split across weighted categories (e.g. Strategic/Pre-Design, Technical Design Production, Project & Design Management, Digital Delivery/BIM), each showing its live amount in your project currency and a running balanced check against your total.

At the top of the page is a color-coded allocation bar — one segment per top-level category, sized to its share of the fee. Drag the thin divider between two segments to redistribute percentage between them live, or click a divider for a quick +5% nudge; click a segment (or its label in the legend underneath) to jump straight to that category's row. Each parent category with sub-lines gets its own smaller version of this bar inside its row, for redistributing between siblings the same way. Next to the bar, a Master adjust control (a slider plus −1%/+1% buttons, shown as "×1.00") scales the whole budget up or down in one move — only active in manual mode.

Beyond dragging, you can override any line's percentage or amount directly by typing into it, add sub-lines, switch a category's sub-lines between "% of budget," "% of parent," or "fixed amount" modes, or apply a structural template. Undo/redo is there if you want to experiment.

5. Deliverables — document types and the Register (MIDP)

Deliverables → Site and Deliverables → Facility are where you switch on the actual documents, drawings, and models the project will produce, per site or per facility/floor. Every deliverable in the catalog (e.g. "Floor Finish Plan", "Structural Calculations") already carries a fixed document type — you don't assign it by hand. Ticking a checkbox activates that deliverable for that facility or floor; the doc type badge next to it is read-only.

Document types are a closed set of 10: Drawing (DRG), Drawing Index (DRI), Technical Schedule (TSC), Specification (SPC), Bill of Quantities (BOQ), Schematic/Schedule Drawing (SCM), Shop Drawing (SHOP), BIM/Digital Model (MDL), Project Management Document (PMD), and Report (RPT). Each one carries rules that quietly shape the register and the hours behind it:

• Area-based (only Drawings and Shop Drawings) — sheet count is expected to scale with the facility/floor's physical size, not stay fixed.
• Sheets always one (most other types) — a Specification, a BOQ, a Model issue, etc. is one deliverable, not a set of sheets, regardless of what a base sheet count says.
• Phase eligibility — each doc type has a default set of phases it's allowed to appear in (e.g. Specifications not before Developed Design, Bill of Quantities not before Technical Design, Shop Drawings only in the Construction Phase). This is informational metadata carried onto the register row, not a hard gate on activating the checkbox.

Deliverables → Register (MIDP) is the payoff: one row for every checked deliverable across the whole project, auto-built from the Site and Facility pages — nothing lands here that wasn't explicitly switched on, and anything the app can't resolve (a broken floor reference, an unknown doc type) shows up in a red "unresolved assignments" banner instead of silently vanishing. Each row carries location (site/facility/floor/zone), identity (discipline, task team, doc type, format, paper size), the ISO 19650-style delivery fields that will fill in later in a project's life (responsible party, LOD/LOIN, CDE state, planned date — deliberately blank at this pre-contract stage), and effort (see below). Filter by facility, floor, doc type, or discipline; toggle a grouped view (by discipline, then doc type); and Export CSV or Export Excel, both respecting your current filters. Think of it as the project's Master Information Delivery Plan in spirit — the single list of everything owed — without a per-task-team (TIDP) breakout, which this app doesn't model yet.

6. Effort — turning deliverables into hours

Once a deliverable is switched on, the Site and Facility tables show an Hrs column next to it — that's effort loading. Two things drive it:

• Hours per sheet — a default baked into the app per doc type and discipline (e.g. a Drawing is ~8h for Architecture but ~10h for Structural; a BIM Model is ~20h for Architecture/Structural/MEP, ~15h for Civil/Infrastructure). You don't set this per line; it comes from the doc type/discipline combination.
• Scope Factor (SF) — the multiplier you can override per deliverable, in the "SF" column, to push effort up or down for a line that's unusually simple or complex compared to the default assumption. On facility pages, a floor's assigned type can carry its own multiplier too.

The formula, roughly: hours = effective sheet count × hrs/sheet × scope factor (× floor multiplier where relevant). Effective sheet count respects the area-based / sheets-always-one rules from the doc type above.

There's also a separate, more advanced Bottom-Up Estimation workspace (reachable directly at a project's /bu URL — it isn't linked from the main nav yet, so treat it as an early, optional extra rather than part of the core flow). It lets you build a resource-loaded plan by hand: name real people or roles with rates and weekly capacity, assign specific deliverables to specific WBS budget lines with per-person effort splits, and reconcile that bottom-up total against the top-down, fee-derived hours from WBS — flagging a warning if the two diverge by more than ~15%.

7. Phasing, Schedule, and Programme — three different timelines

These sound similar but answer different questions. None of them is "the deliverables register in schedule form" — the register has no timeline view of its own.

• Phasing — percentages only, no dates. Pick which project phases are in scope (PRE, CON, DEV, TEC, TEN, Construction by default) and set what share of the total fee falls in each one (a Rate-of-Completion weight, must sum to 100%). Then, per WBS category, set what share of that category's effort falls in each phase (a loading curve — flat, front-loaded, back-loaded, bell curve, or uniform, with quick-apply shapes). This answers "how is the fee distributed across project stages," not "when do things happen."
• Schedule — takes Phasing's percentages and lays them on a real calendar: a Gantt of the phases themselves (not deliverables, not WBS categories). You choose how each phase's duration is sized — Manual (type weeks directly), Date-bounded (set an end date, durations back-calculated from the RoC split), Capacity-driven (cap FTE per phase, duration sized to fit), or Min FTE (duration sized so no phase needs fewer than a minimum team). Adjacent phases can overlap by a configurable number of weeks, there's a master slider to stretch or compress everything at once, and an S-curve chart of cumulative hours/fee against FTE over time.
• Programme — a second, independent Gantt, but built from WBS categories (Architecture, Structural, MEP, …) as bars, not phases and not deliverables. It deliberately ignores Phasing's phase percentages. For each category you pick a scheduling rule — start at project start, a fixed offset, after another category finishes, at another category's % complete, or in parallel with another category — plus an assumed team size (FTE); duration is hours ÷ (FTE × weekly capacity), or you can override the duration and drag the bar directly. It's forward-positioning logic only — not a critical-path scheduler, no resource leveling — and gives you summary stats like total duration, peak/average FTE, and an indicative complexity index based on concurrency and dependency density.

In short: Phasing = how the fee splits by stage. Schedule = when the stages happen on a calendar. Programme = when the WBS work packages happen relative to each other, independent of stage.

8. Export

Export JSON (full project, re-importable) or Export CSV (register-style export) — both on the project page and inside WBS.

What I want your opinion on

This isn't a bug hunt — it's a validation check. Specifically:

1. Does the WBS breakdown match how you'd actually structure a fee? Would you change the default categories or weights?
2. Is the physical hierarchy (Site → Facility → Floor) the right shape, and does the way floors get built (auto-generate, paste, manual) fit how you actually track floors — or does your work need something it doesn't capture?
3. The AI brief import — try it with a real (or realistic) brief. Does the draft it produces save you time, or create more editing work than it's worth?
4. Does the Phasing / Schedule / Programme split make sense, or would you expect fewer, more merged views?
5. What's missing that would stop you from using this on a real project today, beyond the known gaps below?

There's a full roadmap on the landing page if you want to see what's already planned — including a Risk & Assumptions Register in active development.

Send feedback either through Give feedback in the app, or directly to me.