Cleaned from the raw auto-transcript: speakers attributed where identifiable, filler removed, obvious transcription errors corrected (e.g. “Tinder” → “tender”, “Zero” → “Xero”, “flat”/“flag” ambiguity, “workshop resource” → “worksheet resource”). Timestamps preserved so any line can be cross-referenced to the audio.
Key findings
Confirmed decisions
- Timeline stays June 27. Alpha (Apr 25) will likely slip. Beta design work pulled forward so alpha + beta run in parallel, not sequentially.
- Weekly cadence every Tue/Wed through end of June for design review, prototype walkthroughs, testing.
- Snapshot-divergence model for resources/recipes endorsed by Oxcon — explicitly preferred over benchmark’s “carte-blanche update”.
- Recipes = Candy master items + benchmark sub-items, unified, with a mandatory input parameter. Items can be turned into recipes via a builder.
- Reporting is deferred to the Release milestone. Not in alpha.
- M365 is source of truth for users. Admin assigns roles only; nothing else managed in oxFlow.
- Concurrent adjudication while others estimate is a required behaviour — new business rule to add (missing from current list).
Open decisions — need Oxcon input
- Xero as source of truth for companies. Greig/Matt flagged real risk that half-created contacts break Xero batch-payment sync. Needs resolution before we bake it in.
- Plug-rate origin for early estimates. Proposed: draw from curated internal reference rates. Not yet signed off.
- Reference-rate comparison against variable SOP structures. One tender lumps “boardwalk”, another itemises every bolt — how do you compare $/m³? Oxcon agreed this is the first candidate for AI-driven checks (Layer 3) rather than deterministic rules.
New requirements surfaced (not in current spec)
- Multi-window / split-screen workflow. Candy-style side palette for the resource library while editing a worksheet; ability to view multiple items side-by-side; copy-paste items between contexts that carries resources but drops task links. Treated as fundamental, not cosmetic.
- Live estimate dashboard — % priced vs plugged, by value and count; items flagged for review, not-started, broken, underway, closed. Needed for gold-review and scramble visibility.
- Tags & clarifications variance pricing on subcontract adjudication — tag missing scope from a qualification and attach a variance price so comparisons become like-for-like.
- NTT workflow (new items / quantity changes from client mid-tender) — needs first-class handling, not just re-import.
- Estimate Viewer as distinct from Editor — read-only exec drill-down with slicing/filtering, summaries, no edit risk.
- Worksheet power-user affordances — slash commands, @-mentions for variables/resources. Abraham flagged the worksheet as the single highest-risk UI surface.
Corrections / simplifications to current design
- Drop the indirect-cost bucket model. Oxcon’s framing: Direct cost → Risk → Offsite overhead → Margin. Risk is a direct cost without a schedule item. The “indirect” concept in benchmark is an artefact of how benchmark calculates, not how Oxcon wants to think.
- Rename “project-specific” price books → “tender-specific” everywhere. Abraham flagged his own inconsistency.
- “Atom” wording in the resource intro — soften. First-principles framing lands better than “atom”.
- PM / site-manager recharge buildup stays out of tenders. Keep as a flat recharge-rate resource; the salary/vehicle/phone/leave buildup lives in a separate overhead-budget exercise. Could be a recipe but shouldn’t be dragged into tender estimates. Forecasts must not re-inflate fixed recharge rates on live jobs.
Risks & constraints Greig raised
- Architectural tunnel-vision on estimating risks painting the forecasting / cash-flow / project-cost-management phases into a corner. Greig wants explicit design-thinking for later phases brought forward, even at the cost of alpha coding time. Standing concern, not one-off.
- Deadline pressure → scope-narrowing is the failure mode he’s watching for. Wants an early signal from our side if it starts happening so budget/subscription decisions can be renegotiated.
- Budget lever available if needed: drop benchmark subscriptions or switch to monthly during the maintenance overlap.
Immediate action items
- 361: Add concurrent-adjudication rule; rewrite indirect-cost section; rename tender-specific; add live-dashboard, multi-window, Estimate Viewer, NTT workflow, tags-and-clarifications variance pricing; design AI-driven reference-rate checks (Layer 3); pull beta design thinking forward.
- Oxcon: Review spec + business rules and push back; nominate testers; decide on Xero-as-source-of-truth; decide on plug-rate origin; decide on borrowed-rate supplier visibility in reporting.
- Scheduling: weekly Tue/Wed design review in calendars through end of June.
0:00 — Framing
Abraham: The one thing we’re noticing developing with AI tools — it’s not so much about the coding side, it’s about giving you the right information, the right context, the right instructions. Getting those signed off and agreed up front makes the next day so much easier. That’s the end game.
I’m going to walk through this really quick. I suggest we get to the end before you ask questions — it won’t all make sense in the middle, but hopefully by the end you’ll have the full picture, and then we can fire off questions.
Who’s in the room: two teams, one deliverable. 361 brings the experience in software development and in the intersection of construction and software engineering. Oxcon owns the business — oxFlow is being built for you. You own the workflows, the data, the vocabulary, and the final list is yours. The purpose of these docs is for you to push back. If our vision doesn’t match your world, we need to know before we build it. It’s so much easier to flesh this out now — like a building: once you’ve built the foundations, the structure, and come back to change one of the foundations, it’s so much harder than it needs to be.
2:18 — Current state and vision
Abraham: Current state is a number of disconnected tools — benchmark, Workbench, spreadsheets, emails. We know the story.
Vision in one sentence: one platform, one data model, from tender through to project close. Not just estimating — the entire process all the way to project closeout.
I’m not going to read the full function list from the proposal. The wording you’ll see now won’t line up exactly with that list, but the essence has come through.
3:42 — Dates
Abraham: We kicked off Feb 28. Same timeline targets end goal June 27. We’re late. Originally we planned alpha → beta → release sequentially. We’re going to pull the beta design thinking back earlier and run alpha and beta in parallel to claw back time. End of June is a hard date.
Practically that means weekly sessions in your calendars — Tuesday or Wednesday, every week from here to the end. Design docs, prototypes, screens, testing — we’ll have something to do every week.
5:18 — Cooking analogy
Abraham: This is an idea I came up with, not AI — I like thinking of estimating as cooking at scale. Raw ingredients → reliable recipes → the assembled thing the client buys.
- Resources = ingredients (labour, materials, plant, subcontract) — the atoms.
- Recipes = reusable combinations.
- Items = the cake. What the client actually buys.
You’ll see this analogy throughout the design docs.
7:04 — Three core concepts
Abraham:
- Resource — the most basic first-principles cost unit.
- Recipe — a reliable, named combination, reusable across items.
- Item — what the client buys. Description, unit, quantity. Every item has a worksheet, which is where you sell your story — build up methodology, arrive at a rate.
Oxcon: Why have you changed from ingredient to atom?
Abraham: Ingredient is still the analogy; “atom” is just another way to say smallest component — a first principle. I’ll adjust the wording.
8:50 — Five-layer entity grouping
Abraham: The system has many entities — tenders, estimates, companies, etc. To make it tractable we’ve grouped them into five layers.
Layer 1 — Work hierarchy (9:48)
Tender → Estimate → Heading → Item → Worksheet.
Oxcon: What’s the difference between a tender and an estimate?
Abraham: A tender is the container — it describes a pricing opportunity linked to a client: closing date, tender due date, win probability, price and non-price attributes. An estimate is the cost build-up inside a tender. A tender can have multiple estimates — base, alternative, version 1, version 2, etc.
Oxcon: If we’re submitting an alternative, the base and alternative sit within the same tender?
Abraham: Exactly.
Oxcon: What about cost-to-complete and the way we run it as a project — multiple versions, etc.?
Abraham: That’s project cost management — a different entity and a later phase. This is alpha: estimating through to submission.
Oxcon: OK. Let’s note questions as we go.
Layer 2 — Building blocks (12:24)
Resources and recipes, plus content blocks, calculation blocks, and variables that all feed the worksheet. The worksheet is your canvas — tell the story, explain the methodology, bring in resources, recipes, pictures (content blocks), text (inclusions, exclusions, task breakdown, etc.).
Layer 3 — Pricing and procurement (13:10)
Once you’ve built hierarchy and put costs in, you go to market for up-to-date pricing. Two new concepts:
- Price book — named collection of resources. Types: internal (our generic rates), external (supplier-scoped — e.g. pricing lists from Pol Products, Sika, Firth), or tender-specific (note: Abraham used “project-specific” in places — that’s a slip; canonical term is tender-specific).
- Subcontract package — the flipped perspective: you choose items that form a package and go to market to price them. Underlying concept is the same — resources linked to a supplier.
Oxcon: So a price book is essentially a resource list?
Abraham: Exactly, with some metadata — supplier, region, date range, expiry — to support anomaly checking.
Adjudication (14:44)
Abraham: This was missing in benchmark and we really want to get it right. Adjudication is a formal comparison across competing sources. It’s an entity in its own right — has snapshots, timestamps, draft vs final states. You export to market, get results, import back in, compare suppliers, add variances, feed the winning rate back into the estimate as a resource.
Oxcon: Does it handle tags and clarifications from subcontractors?
Abraham: Yes — you can apply a variance price to qualifications a subcontractor raises, so you can make like-for-like comparisons. Someone might qualify their price rather than missing the schedule; you tag and price those clarifications.
Oxcon: So you can pull those tags out and say “do I want to apply a number to that variance?”
Abraham: Exactly. The ultimate goal of adjudication is an informed, like-for-like comparison.
Layer 4 — Commercials and submission (16:50)
Abraham: Once the cost build-up is done, apply your commercials. A new concept: rules. Think margin, overhead, profit, contingency — anything applied after build-up. There’ll be smarts about how rules are applied.
Oxcon: Including loading and unloading?
Abraham: Loading and unloading happens at the submission stage — after rules are applied, you have a final stage where you can manually adjust rates and values.
Then comes the Publisher — pretty PDF/Excel output, inclusions, exclusions, tags, branding, standard assumptions.
Oxcon: Will there be a module to write tags in the tender?
Abraham: Yes.
Layer 5 — Reference data (18:13)
Companies (from Xero), users (from M365), units, categorization, and codes.
- Categories are flexible and easy to create — for slicing and dicing reporting.
- Codes are specific and rigid — they drive what passes through to Workbench.
19:47 — Reporting gap flagged
Oxcon: Nothing on reporting?
Abraham: Correct — reporting lives in the Release milestone, not alpha. We’ll bring that design work forward in the next few weeks.
20:01 — Work hierarchy detail
Abraham: Tender — external pricing opportunity, one per client pricing engagement. Attributes: client, client reference, tender due date, win probability, etc. Relationships use standard notation: many-to-one, one-to-many; optional relationships marked.
Estimate — the price build-up. Attributes: status (draft, submitted, active, inactive, reviewed, archived, etc.). Relationships: one estimate → many headings; one estimate → many commercial rules. A lead estimator is assigned at the estimate level.
Oxcon: Pedantic question — if heading is the top level, what does that make the others?
Abraham: One estimate can have multiple top-level headings — like sections. Concrete works, bridge works, etc. Not locked to a single top heading.
Heading — grouping inside an estimate, nests up to 5 levels deep. In benchmark terms this maps to “section” or “total item” — a sub-total that’s visible to the client.
Item — the unit of priceable work. Exactly one worksheet per item. The most structured of all entities: item types, statuses.
Terminology rule: when we say type on an entity, it means it controls how it works through the system. When we say category, it’s purely a reporting classification and has no system impact.
You can assign an estimator to an item for task allocation. Oxcon runs a flat structure so the hierarchy is deliberately soft, not rigid.
Worksheet — methodology canvas. Variables, calculation blocks, content blocks, resource usage — builds up to the item cost. Content blocks are admin-defined (inclusions, exclusions, task breakdown, risks, etc.). Items can nest; every item has exactly one worksheet.
28:16 — Resources, flags, modifiers
Abraham: Resource types — currently proposing 5: labour, material, plant, subcontract, other. Each type can have flags (optional) and modifiers (optional).
- Flag — a pre-defined descriptive attribute the admin curates. Does not affect cost math — purely informational and drives anomaly checks. Example: a resource might have a “includes public holiday rate”, “includes small tools”, “includes cartage”, “wet hire vs dry hire”, “operator included”, “fuel included” flag. Instead of stuffing this in the description, it’s a tick on the resource.
- Modifier — does affect quantity or rate. Example: wastage, standard mobilisation cost.
Oxcon: Are flags predefined?
Abraham: Yes — you define the flag set when creating the resource. Not every resource gets every flag. For an earthworks resource you might enable only the “cartage included” flag.
Oxcon: Where does something like format-resources (simple × 2, × 3, × 4) fit?
Abraham: That’s more of a recipe-shaped problem than a modifier — e.g. “150 thick path” vs “200 thick path”. Modifiers are for simple tweaks. Concrete wastage, with-fuel / without-fuel — those are good modifier examples.
Oxcon: Is resource → supplier still tied?
Abraham: Yes, supplier is an important attribute, held at the price book level.
33:19 — Recipes
Abraham: Key thing: a recipe must have at least one input parameter. That’s what lets it be used as a resource-like thing when pulled into a worksheet.
- Simple recipe example: crew rate. Input parameter = duration (hours or days). The recipe’s worksheet uses that parameter in the calculation.
- Complex recipe example: formwork or placement rate. Inputs = length, width, depth → recipe calculates concrete, labour, etc.
An input parameter can be mapped from a variable on the parent worksheet.
Oxcon: Complex resources in Workbench would be sub-items. Is that a recipe?
Abraham: Yes — a recipe is essentially benchmark’s item library + Workbench’s sub-items unified into one concept. You can also turn any item into a recipe — the recipe builder prompts for input parameters. Good for supervision / management-staff crew buildups.
Oxcon: The item library is used anywhere; an item is localised to an estimate?
Abraham: Yes.
Oxcon: E.g. reinforced in-situ concrete — that’d be a recipe where you give cubic metres of concrete, tonnage of steel, square metres of formwork, etc., and it outputs a number?
Abraham: Exactly. And for early-stage estimates you might run a very basic recipe — just volume of concrete and a % Rio — then later replace with something more detailed.
38:08 — Price books continued
Abraham: Price book has a type: internal / external / tender-specific. Metadata — region, date range, expiry date — drives anomaly checking (e.g. flag if you’re using a price book past expiry).
System-generated price books exist but are flagged differently and hidden from users. Critical for the system to work.
Oxcon: Could we generate a standard price book item from benchmark history — e.g. square metre of path, scaffold — and evolve it over time?
Abraham: Absolutely.
Oxcon: Where do quoted rates sit?
Abraham: A tender-specific price book — same mechanism.
Oxcon: Where do plugged rates for early estimates come from?
Abraham: Not fully decided. Logical place: internal curated rates. We’ve sketched a reference rates entity — curated rates that carry more weight and can be used as reference throughout, especially when AI tooling comes in. Worth discussing further.
43:46 — Adjudication mechanics
Abraham: Price-book adjudication vs subcontract-package adjudication — under the hood they’re doing the same thing. Price book adj → choose a resource already in a price book and drop it into the estimate. Subcontract adj → create a subcontract rate and an associated price book, then drop that into the estimate as a resource linked to the subcontract adjudication.
Oxcon: So at resource level it’s comparison + selection; at subcontract level you’re doing a leveling + more intelligent comparison and then selecting.
Abraham: Exactly.
45:09 — Layer 4 recap and business rules
Abraham: Commercials = rules + submission values + publisher. Reference data = companies, users, units, categorization. That’s the concept map.
Business rules — constraints that govern entity behaviour. There’s a detailed list. Example rules: heading nests up to 5 deep; every recipe has exactly 1 worksheet; every item must have an item type; rate-only items are only valid as scheduled items.
Your key role over the next few days is to read the rules list carefully and flag anything that breaks your business logic.
Oxcon: Example — I can run a subcontractor adjudication while someone else is estimating on the same tender?
Abraham: Good catch — that’s not in the list yet. Add: concurrent adjudication must be supported. That’s actually a good one.
48:20 — Roles
Abraham: Three roles: administrator (everything), lead estimator (can create estimates, new tenders, adjudicate, apply commercials), estimator (more controlled access). Viewer is not a role — it’s a shareable link.
Oxcon: Can there only be one lead estimator?
Abraham: Multiple people can hold the lead estimator role. On a given tender you assign one lead estimator from among them.
Oxcon: Roles are assigned at the user level, not per-tender?
Abraham: Correct. User role is a global property; the per-tender lead estimator is a choice from eligible users.
50:41 — Integrations
Abraham: M365 (users), Xero (companies), Workbench in the interim (activity codes, work centres).
Oxcon (Greig/Matt): Why Xero for companies?
Abraham: Source of truth. No point maintaining another supplier/client list.
Oxcon: But we don’t set everyone up in Xero at the point we go to get a quote — only if we intend to do business with them. At tender time we just need their name and email.
Abraham: My suggestion is still to set them up in Xero at tender stage, minimal info only — otherwise you end up managing two lists.
Oxcon (Greig): The risk is half-created contacts. If Xero contacts are incomplete — missing IRD/GST — batch payments fail. We don’t want a workflow where it looks like they’re set up but they’re actually only half-set-up. That’s a pain in the arse.
Abraham: It is a trade-off. The other pain is someone having to create contacts in Xero that aren’t linked to any accounts yet — they flow through the system, but when they hit Xero they’re not linked to anything. That might not matter.
Open decision: Xero-as-source-of-truth vs oxFlow-managed-for-tender-stage. Flag for further debate — we had the same argument with CLL and landed on Xero, but they don’t do their estimating inside the same system.
53:24 — Deliverables and asks
Abraham: Delivery = milestones. The team is pushing hard for Apr 25 estimating replacement; we may be a little late. We’ll start beta earlier to work on both in parallel.
From Oxcon we need:
- Review the design spec + prototype + supporting function list.
- Nominate testers who can work closely with us when we fire things off.
54:49 — Walkthrough of the two docs + prototype
Abraham: Two documents:
- Design spec — concept map, business rules (with rationale per rule), roles and permissions matrix, non-functional requirements (e.g. UI loads in 2s — more for us than for you), then per-entity pages with attributes, relationships, states, and worked examples.
- Flows & information architecture — how you work through the system. Sections on estimator journey and view inventory (pages: home dashboard, tenders list, tender detail, estimate editor, worksheet editor, etc.). This is the one you should spend the most time on.
Also a prototype — clickable, fake data, not every button does something. Don’t worry about colour or button placement; focus on functions. Can I export? Filter by status? Duplicate a tender? That’s the feedback we need.
The glossary is a single-page flip-through of every entity if you want one place to see it all.
1:01:45 — Tender detail page walkthrough
Abraham: Tender detail: add new estimate, mark won/lost, client, tags (categorisation), tender program link. Programs are the setup for later forecasting — you upload a program (tasks), link a task to an item; that exposes the task’s duration as a variable in the item’s worksheet. Example: link the construction summary task (250 days) to a construction supervision item → you now have duration_construction as a variable in the calculation (e.g. 50% PM time, 20% site engineer, etc.). Can also link 3 piling tasks to a piling item → you get total piling duration → feed production rates.
1:04:34 — UX asks from Oxcon
Oxcon: Ability to widen columns, pull across, see more of a worksheet. Bulk categorise. Bulk apply type. Drag-and-drop resources from library into worksheet. Multiple views.
Abraham: Yes — anything’s possible; now is the time to bring it up. Structural decisions matter most. Colours are easy later.
Oxcon: Having multiple windows is fundamental. Candy has a side palette (resource list / supermarket). Benchmark doesn’t — you can’t open a master resource or master item list and drag into the worksheet. That’s a major downside.
Abraham: So — fixed-set-of-windows (e.g. dedicated library palette), or full free-form multi-window?
Oxcon: Depends. Easiest win is ability to open two browsers side-by-side. Even better: 4-way split. In benchmark, to re-check what you did on a nearby item, you navigate up three levels then back down — 8 clicks to get back where you were 2 minutes ago. Brutal.
Abraham: You’d want to open 3 cookbooks and 1 pantry, essentially.
Oxcon: Yes. Also modern copy-paste — open 3 browsers, copy an item from here, drop into there; it brings resources but drops task linkages.
Decision to make: fixed-purpose side palettes, or fully free multi-window? Needs a follow-up.
1:07:16 — “AI chatbot on the worksheet” wish
Oxcon: I want an AI chatbot I can talk to in natural language — fill in fields, analyse what I’ve done and haven’t done against the library, pull stuff out. I don’t want to build from first principles; I want to talk to it.
Abraham: The dream. One day.
1:11:08 — Resources: flags and suppliers, revisited
Oxcon: Current resource descriptions are long-winded — “20 MPa pumped concrete, fibre-reinforced, blah blah”. Are those flags, modifiers, or both?
Abraham: Resource type is the structural classifier — labour, material, plant, subcontract, other. Within a type, flags carry scope/conditions without bloating the description. For labour: region, rate tier, allowance, hours-per-day, “includes away allowance”, penalty rates. For plant: wet hire vs dry hire, operator required, fuel included.
Oxcon: How are you going to determine what the rate actually is — e.g. a wet-hire vs dry-hire rate?
Abraham: Flag is informational, not a rate modifier. If you flag a rate as “wet hire” but also have an operator line in your build-up, the anomaly review raises a minor check. Similarly, dry-hire rate with no fuel line in the build-up → flag.
Oxcon: So if I want to use a dry-hire rate as wet, I need to build the wet-hire rate separately.
Abraham: Correct. Flags don’t modify the rate.
Oxcon: Flags have to be categorised by resource type — we don’t want 100 random flags.
Abraham: Yes — categorised by type, limited set, with a bespoke free-text flag option.
Oxcon: As long as flags still show in the resource card/filter, we don’t need them in the description. Fuzzy search should match on flag text too.
Abraham: Yes — flags appear in search and in filters.
1:16:55 — Supplier attribution on borrowed rates
Oxcon: If we pull an old rate from another project (nominated supplier on it), we want the option to turn that supplier off within the current estimate — otherwise reporting shows a random supplier on one line for no reason.
Abraham: That’s exactly what a tender-specific price book is for — disposable resources, used on that tender only, not visible elsewhere.
Oxcon: But we do that all the time — “shit, I forgot to get a price; let me use that rate from two years ago”. We’re not going to filter through external price books every time.
Abraham: Fair — we need a quick path for this. Worth refining.
1:18:46 — Review, analysis, live dashboard
Oxcon: Where does the end-to-end analysis live? “I’m 70% subs, 30% self-perform” — gold-review analysis, dashboards. What you and Brian went through over half a day the other day.
Abraham: Categorisation drives the reporting view. Before reporting, there’s an anomaly check — catches missing/wrong things for the estimator. Then commercials. Then a shareable view.
Estimate Editor (edit) and Estimate Viewer (read-only) are separate pages. The viewer is designed for exec review — drill down into items, slice by category, filter by highest-qty resource or highest-value item, etc.
Oxcon: A live dashboard overview — how much is plugged, how much is fabricated, how much is sort of there. Really useful when you’re behind and scrambling.
Abraham: Yes — by value, by count, by status. Items flagged for review, flagged for not-started, broken, underway, closed.
1:22:42 — Pre-commercials review (3 layers)
Abraham: Three-layer anomaly review surfacing likely errors before an estimate progresses.
Colour convention (throughout the design docs): green = largely done; orange = maturing, room for improvement; red = needs input.
Examples:
- Item with plant but no fuel or operator.
- Materials with unusually high wastage, or missing transport / cartage.
- Provisional sums, missing quantities.
- Item status unpriced → blocks progression.
- Item status plugged → blocks progression.
- Unit mismatch on snapshot divergence.
Snapshot divergence (1:23:51)
Abraham: When a resource or recipe is sucked into a worksheet, the worksheet takes a snapshot. If the source resource later changes, the anomaly review flags that the snapshot has diverged; the estimator explicitly accepts or syncs. Estimator has control — unlike benchmark’s carte-blanche update.
Oxcon: That’s way better than how benchmark handles it.
Layer 2 — Reference rates (1:25:06)
Abraham: Reference rates are curated min/max/target ranges — rules of thumb. At item level: e.g. reinforced concrete should be $700–$1050/m³. If outside the range, flag during review.
Oxcon: Can you do rules of thumb at item level?
Abraham: Yes.
Oxcon: The challenge is SOP variety. One tender has “boardwalk lump sum”. Another itemises every nut and bolt. How do you compare?
Abraham: Honestly, no deterministic answer yet. This is probably the first candidate for Layer 3 — AI-driven checks — pass the structure + reference rate to an LLM and ask whether the rate is applicable.
1:27:52 — Content blocks
Abraham: Admin-defined content blocks: inclusions, exclusions, task breakdown, risks. Name + explainer. Users drop them into a worksheet. Importing can pre-create them. Content blocks exist on recipes too — so when a recipe is pulled into an item, its content blocks transfer.
Oxcon: So a crew is essentially a recipe with a duration input parameter, same concept as Candy’s complex resource or benchmark’s sub-item.
Abraham: Yes — think of recipes as templates. Template for a crew, a resource, a whole item — all recipes.
1:30:41 — Overhead / PM rate build-up debate
Oxcon: Should we build first-principles site-manager / PM buildups (salary, vehicle, phone, leave) inside oxFlow — as a library — so it’s in one place?
Greig: A project doesn’t care. The project is charged a single recharge rate. There’s no benefit breaking that down at the project level — the project doesn’t see vehicle cost for Lance out of the overhead budget.
Oxcon: So we use a recipe or a price book for the flat recharge rate, and do the first-principles buildup elsewhere (e.g. an internal overhead-budget estimate in oxFlow, separate from tenders).
Abraham: Correct. You can do the buildup as a recipe, but you wouldn’t drag that recipe into tenders — it’d keep breaking down at Workbench transfer, which you don’t want. Keep the recharge rate flat for tenders.
Oxcon: And forecasts — if fuel prices change, we don’t re-inflate the recharge rate on live jobs. The job’s rate is fixed at tender. If the business adjusts recharge, it changes in the library, not retroactively per job.
Abraham: Agreed.
1:35:38 — Scheduled items, direct vs indirect
Abraham: Items flagged as scheduled are the only ones sucked into the final quote. Everything else is supporting structure. There’s business logic around direct vs indirect costs.
Direct cost — straightforward. Indirect cost that isn’t priced — straightforward. Indirect cost that is priced — how do you treat it?
Oxcon (Greig): Our rule: an indirect cost is anything the project never sees an invoice for — paid by Matt out of overhead. We apply it as a percentage of direct cost. Anything on-site that we price because the client asks for it is still direct, even if benchmark forces us to dump it in the “indirect” bucket.
Abraham: So the “indirect” bucket in benchmark is an artefact of how benchmark calculates (direct + overhead % + other items + margin on sum). Risk sits in that bucket for the same reason — it has to get margin applied uniformly.
Greig: Exactly — drop the indirect-cost bucket model. For oxFlow, simplify to: Direct cost → Risk → Offsite overhead → Margin. Risk is a direct cost that happens to have no schedule item. Don’t abide by the indirect artefact.
Abraham: That’s a simplification — I’ll confirm by reading the indirect-cost section of the spec and revising. Rule ordering matters: default sequence is Direct → Offsite overhead → Margin → (adjustments) — but you can reorder per tender (e.g. apply a final discount).
Risk handling: build up risk in a section that doesn’t sit under any scheduled item; distribute across scheduled items. Per-estimate rule can govern how — e.g. “apply 50% probability to unscheduled items, then distribute across remaining items”. Keep rules smart but simple, with a standard set that gets auto-applied and can be overridden.
1:35:40 — Schedule imports, NTTs
Oxcon: Process for importing schedules and handling NTTs (new items, changed quantities) during a tender — needs functionality.
Abraham: Importer pre-populates; smart detection of headings vs items; drag-and-drop re-structuring; flag items as scheduled/non-scheduled.
1:45:00 — Calculators / code blocks
Oxcon: Calculators — where do our spreadsheets / calculators go?
Abraham: That’s the calculation block concept on the worksheet.
1:45:30 — Wrap: Greig’s architecture concern
Greig: Out of everything we’ve looked at, what’s the hardest bit?
Abraham: Worksheet page — making it easy and intuitive. Variables, slash commands, @-shortcuts — Slack/Notion-style power-user affordances. Most other pages (tables, lists, filters) are straightforward. Worksheet is the highest-risk UI surface.
Greig: And conceptually — we’re clearly getting a feel for estimating, but there’s an eye on forecasting, cash flow, actuals, committed, combining all together. My concern: don’t lock the architecture into estimating so tight that it can’t accommodate forecasting and cash-flow properly later. The classic trap — shit-hot core product built rigid, then they bolt on later features and those are always a bit shitter because the original architecture is too constrained. Are you comfortable we’re not doing that?
Abraham: Not nervous, because we know what’s coming. My position now is to pull design thinking for later phases forward — spend the time refining thinking even if coding slips. Clear instructions to the LLM save so much downstream.
Greig: Don’t lose sight of that, particularly when under deadline pressure. If you feel yourself narrowing, tell us — we can ease something (e.g. drop subscriptions, go monthly on benchmark) rather than compromise the architecture.
Abraham: 100%.
Greig: The maintenance period extends runway. Options exist.
Abraham: Key is getting the design sum down. Any cost comes off the lump sum.
1:51:07 — Close
Abraham: The fact that we know the end goal now, earlier than most estimating-first products, lets us plan ahead. My concern for later phases is more around after we deploy the whole system and start adding components — that’s when the risk of architectural lock-in bites.
Greig: Leave the back door open.
Abraham: That’s why we’re dealing with New Zealand’s premier construction technology specialists.
Greig: Any other questions? Good work. Excited.
Action items (captured from the conversation)
From 361 side
- Add rule: concurrent subcontract-package adjudication while another user estimates (missing from current rules list).
- Update commercials spec to drop the “indirect cost” bucket model. New model: Direct → Risk → Offsite overhead → Margin. Risk = direct cost without a schedule item.
- Revise spec wording “project-specific” → “tender-specific” throughout.
- Clarify the “atom / ingredient / first principle” framing in the resource intro.
- Add live-dashboard requirement (plugged vs priced, by value/count/status).
- Add multi-window / split-screen / side-palette requirement — decide between fixed-purpose panes and free multi-window.
- Add Estimate Viewer (read-only exec drill-down) alongside Estimate Editor.
- Add NTT (client-driven schedule changes) workflow.
- Add tags-and-clarifications variance pricing to subcontract adjudication.
- Design path for reference-rate checks across variable SOP structures — first AI-driven (Layer 3) candidate.
- Bring beta-phase design thinking forward; run alpha + beta design in parallel.
From Oxcon side
- Read the design spec and business rules list; return pushback.
- Nominate testers.
- Decide on Xero-as-source-of-truth for companies vs oxFlow-managed at tender stage.
- Decide on plug-rate origin (proposal: internal curated reference rates).
- Decide on borrowed-rate supplier visibility in reporting (quick “turn off supplier” path within a tender).
- Confirm simplification of indirect costs (likely yes).
Scheduling
- Put weekly Tue/Wed design review in calendars through end of June.
Constraints to revisit if timeline slips
- Drop number of benchmark subscriptions, go monthly — available lever for budget flexibility.