Every job is a Project — and everything hangs off it.
This guide explains what each thing in the app means, who can do what, and how the work actually flows — in plain terms, no software required. Leave a note anywhere and it comes straight back to the team.
The office app and the field app
The office app is where owners, PMs, and supers plan and steer a project from a desktop: schedules, coordinate items (decisions, commitments, changes, selections), timesheets, and the template library that seeds every new job. The field app is a phone-first tool crew use on site all day — clock in, see today's tasks, run the safety check, add photos, and wrap the day. Crew can execute anything on a project they belong to with no permission friction; only PM and above can redefine the schedule itself.
The thinking behind the app
A handful of principles shape every screen in here. They explain the choices that might look unusual at first — and why the app helps without getting in the way.
It advises; people decide
The app is a co-pilot, not an autopilot. It points out what's worth a look and gets work ready to go, but it almost never blocks the job, and it never moves a job forward on its own. A person always makes the call.
In the appA gate or a booking reminder flags a checkpoint without stopping the next step. When the last blocker clears, a step simply reads "ready to start" and waits for someone to start it. A step only ever becomes "blocked" because a person marked it so.
The truth is computed, not typed
How healthy a job is, how far along it is, what's next, and why a step is stuck are all worked out fresh from what has actually happened. Nobody types those numbers in, so they can't quietly drift away from reality.
In the appA timesheet is rebuilt from the raw clock-in record every time it's opened, never kept as a second copy that could disagree. A job flips to warranty on its own the moment its last phase is done — no one flips a switch.
Attention comes to you
You don't hunt through projects to find what needs you — one list per person gathers it across every job they can see. And it stays quiet on purpose: most things wait patiently and grow louder only as the stakes rise.
In the appThe office has a "Needs you" list, the crew a "For you" list. A pop-up only appears if someone's actually watching; otherwise the item just waits. An unanswered change order nags harder the longer it sits — and only safety alerts are always on and can't be silenced.
Office defines, crew executes
Doing the work — ticking a task, adding photos, clocking in — carries no permission hoops for the crew. Changing what the work is, the schedule itself, is an office job. It's built for a small team coordinating, not a permissions fortress.
In the appAny crew member can work any task on a job they're on, with no sign-off to get started. But only a project manager or above moves a step forward or reshapes the schedule, and crew pick from budget codes rather than inventing them.
One source of truth
Datum holds the real record of a job, and the outside tools point back to it. For now the connections run one way — Google Calendar, Slack, and the rest mirror what's here — so an edit made out there can't quietly overwrite what the team relies on. Two-way isn't ruled out for good; today the app keeps the flow one direction to protect the record.
In the appA calendar event changed in Google is set back on the next sync; Slack receives a one-way echo of the end-of-day report, and nothing typed in Slack comes back into the app.
Nothing is truly deleted
Removing something sets it aside rather than erasing it, and every change keeps a trail you can follow back. The app corrects and supersedes instead of overwriting history.
In the appRemoving a step archives it; publishing a new checklist version leaves already-ticked work untouched; a replaced change order keeps the original in its history; and a deleted photo or document can be restored for about a month.
Project → Phase → Step → Task
What lives inside what — and what attaches where. The interactive version, with every box explained, is under The model; every term is also defined in the Glossary.
Project → Phase → Step → Task
What lives inside what, and what attaches where. Tap any box for the full definition and a link straight to its glossary entry.
Project → Phase → Step → Task
Glossary
The containment spine first — what sits inside what, indented — then everything else, grouped by how it relates: computed values, money, why work gets stuck, daily rituals, attention.
Project
Working nowA project is one job — a build, renovation, or the company's "general operations" bucket for internal time (only one exists). It's the root everything hangs off: phases, steps, tasks, people, money, and coordination.
Every project moves through stages: pre-construction → construction → closeout → warranty → complete, with "on hold" off to the side. A project flips to warranty the moment all its phases are done (marking handover), or an owner/admin can set it by hand. Warranty is simply a stage; work during warranty still tracks and exports like any other time.
A project's type (new build, extension, takeover, basement reno) decides which template is copied in to seed its schedule when created.
A project manager can create a project and edit most things — site details, dates, the schedule. But the big lifecycle switches — stage, fee percentages, and Slack channel — are reserved for owner and admin.
Visibility: owner, admin, PMs, supervisors, and accounting see every active project; crew and designers see only assigned ones.
Phase
Working nowA phase is a labeled chapter grouping consecutive steps — "Foundation," "Framing," "Closeout." It's an organizing layer only; a phase carries no dates of its own since its span is what its steps cover. Phases are numbered automatically by position, so steps don't need individual numbers.
A phase makes a long schedule readable and gives the office one place to flag "check this before we move on" — a single soft, advisory note shown alongside it. The note never blocks work.
A phase is in one of four states: upcoming, in progress, blocked, or done. Unlike a step, a phase has no "not applicable" state. A phase's status is set by hand, not calculated from its steps. When every phase is marked done, the project automatically advances to warranty.
Removing a phase detaches its steps (not deleted, unassigned, kept visible).
Only a project manager or above can create, edit, reorder, or remove a phase.
Related: a phase belongs to a project and contains steps. A step's own blocked status and reason are a separate concept from a phase's status.
Step
Working nowA step is one piece of work in the build sequence — "frame the main floor," "rough electrical inspection." Steps are the real schedule: an ordered list with optional dates inside a phase. Not a checklist; not the same as tasks.
A step has five states: upcoming, in progress, blocked, done, or not applicable. Multiple steps can run in parallel. "Not applicable" means the project doesn't need this step (e.g., a utility locate that doesn't apply); it's different from "done" — it drops out, never becomes the next checkpoint, and never overdue.
A step becomes blocked only when someone marks it manually (never automatic). They can add a short note why. Unblocking clears that note, so unblocked steps never carry stale reasons.
Only a project manager or above can change a step's status. Field crew can tick checklist items under a step, but moving the step forward is an office action.
Related: a step can carry tasks, a checklist, booking prompts, a gate flag, and hand-declared dependencies on other steps.
Task
Working nowA task is one concrete to-do — "order the tile," "call the inspector," "hang drywall." Tasks are actionable items. A step is an optional schedule container; a task can also stand alone.
Every task is either field or office. Field tasks show on the crew phone and dispatch to a specific day. Office tasks (calls, ordering, permits) stay hidden from the crew and can carry an exact appointment time, not just a day.
A task is open, blocked, or done. Marking it blocked requires a short reason. Every task carries a budget code — the office picks one, or the app derives one if omitted, so no task lacks a category. A task can be assigned to one person and carry a small numbered sub-list (seeded by or separate from a checklist).
Anyone on the project crew can execute a task (change status, tick sub-steps, add photos) with no special permission. Only a field supervisor or above can define it: create, edit, reassign, or delete.
Related: a task can sit under a step, always carries a budget code, and can have a checklist applied to seed its sub-list.
Checklist
Working nowA checklist is a named, reusable list in a company-wide library. Publishing a change appends a new version, so work already ticked under an older version stays unchanged.
A checklist attaches to a step or a task — never to a project or phase — but behaves differently depending on which:
- On a step, it's a live pointer to the library. The step always shows the current published version; if the library updates, the step's checklist starts fresh.
- On a task, the current version's items copy onto the task as its own list at that moment. Later library changes don't alter it.
Each item carries a short how-to note and reference link alongside its title.
A checklist is active or inactive, and separately flagged needs review — a housekeeping flag, not a blocker.
Owner/admin create, rename, or publish new versions.
Related: attaches to a step or a task; a template step can specify which checklist to carry into new projects.
Booking prompt
Working nowA booking prompt is a required booking a step lists — an inspection or a trade, each with its label. It lives on a step, usually from a template.
A step can list more than one. The booking badge marks satisfied when ANY commitment or scheduled-or-passed inspection links to the step — not each individually. This is deliberately coarse: a single signal rather than a tracked checklist.
A booking prompt doesn't block anything. It's a visible reminder only.
Related: satisfied by a commitment or scheduled/passed inspection linked to the same step; usually seeded from a template's step.
Gate
Working nowA gate is a flag on a step marking it as a checkpoint worth double-checking before work moves past it — "don't start tile until waterproofing is signed off." It carries a short advisory note explaining what to check.
It gives a schedule deliberate "make sure of this" points and feeds the milestone — the system looks for the nearest gate ahead of work when picking "next."
A gate is purely advisory. Flagging a step as a gate never blocks it or following steps from starting; it's a note, not a lock. A step is either a gate or isn't — no partial or expired state.
A phase separately carries its own single advisory note shown before the next phase begins. It works the same way — soft reminder, never a block — but isn't tied to a gate flag; it belongs to the phase itself.
Only a project manager or above can flag a step as a gate or set its note, as part of editing the schedule. Anyone who can see the project can see which steps are gates and read their notes.
Dependency
Working nowA dependency is a project manager declaring that one step can't start until another finishes — "drywall waits on framing inspection." It sits on the supply spine, since it's about the physical world being ready, not a decision.
The app deliberately does not assume a step waits on the one listed before it — being next in the list is order only, not a hold-up. The only dependency recognized is one a person explicitly draws between two named steps. This keeps the schedule honest: most steps can run in any order or in parallel; only a few genuinely must wait.
A dependency is always soft — it never locks anything or stops a step from moving by hand. It shows a "waiting on [other step]" note on the waiting step; the note clears automatically once the other step finishes. A step can't depend on itself, and the same wait can't be declared twice.
Only a project manager or above can declare or remove.
Related: step, two-spine model, readiness.
Milestone
Working nowThe milestone is the next checkpoint ahead of where work actually stands — a single answer to "what's next," shown on the project and owner portfolio.
It's found by position, not date. Starting from the furthest step in progress, the app looks forward for the nearest unfinished gate step. If found, that's the milestone. If no gate ahead, it falls back to the nearest unfinished step with a date set. If neither exists, there's no milestone. Steps marked "not applicable" are skipped.
This makes the milestone a positional preview, not a forecast — "this is the next thing to clear," not "when it will happen." When multiple steps run in parallel, the milestone looks ahead from the furthest one.
Nobody sets the milestone directly — it's calculated from the schedule's gate flags, statuses, and order. A project manager changes it indirectly by flagging gates, adding dates, or moving steps. Anyone who can see the project can see its milestone.
Related: gate, step, structural progress.
Structural progress
Working nowStructural progress is how far along a project's build sequence is: finished steps divided by total applicable steps.
It's a simple count of completed work — never weighted by dates, pressure, or step size.
A fraction: steps marked done over total steps. Steps marked "not applicable" (work the project doesn't need) drop from both sides entirely. If a project has five steps and one doesn't apply, progress measures out of four; finishing all four = complete. No other state (upcoming, in progress, blocked) counts as finished.
Nobody sets structural progress directly. It recalculates from every step's current status. A project manager or field supervisor changes it indirectly, by marking steps done or not applicable as work happens.
Anyone who can see the project can see its structural progress. It appears on both the project page and portfolio view.
Related: step, milestone, structural health.
Structural health
Working nowStructural health is a one-glance "On track" or "At risk" signal for a project, shown on the project page and portfolio view. Scan the whole portfolio at once without reading full schedules or blocker history.
Only two readings: on track or at risk. A project reads at risk if any of these is true across steps and tasks:
- Something actively blocks progress: an open blocker or unsigned client change request.
- A step or task is manually marked blocked.
- A step or task slipped past its date without being finished or marked not applicable.
Otherwise the project reads on track. A "materials not yet delivered" note does not trigger at risk — it's treated as expected.
Nobody sets structural health directly. It recalculates from the project's current blockers, statuses, and dates. The same calculation feeds both the project page and portfolio view — a project can't read differently in two places.
Anyone who can see the project can see its structural health.
Related: step, milestone, structural progress.
Budget code
Working nowA budget code is the company's "what kind of work is this" taxonomy — categories like "Demolition" grouped under headings like "General Site Preparation." It filters work, assigns no person, holds no dollar figure.
It attaches only to a task (required) and clocked time (required) — never to a step or project, since it tags work being done, not the schedule slot.
One code, General Operations, is on every project automatically and can't be removed. If a task or time entry saves without an explicit code, the app picks a sensible one — the code last used on that project, or the first available — rather than blocking on an accounting decision.
A code is active or inactive, and separately billable or not (General Operations is the one non-billable code today).
Owner/admin create or edit the company-wide master list. A project manager chooses which codes apply to their project. Field crew pick among their project's available codes for untasked work, but can't invent new ones.
Related: attaches to tasks and clocked time; never to a step, a phase, or a project directly.
Two-spine (coordinate) model
Working nowThe two-spine model sorts "why is this stuck" into exactly two lanes, decided in one place so every screen agrees.
- Answer — waiting on a decision or unpicked client/designer choice; money and intent. Only a person deciding clears it.
- Supply — waiting on the outside world: a trade or delivery not arrived, material not on site, failed/held inspection, or step hand-declared to wait on another.
A blocker is tagged one spine when created, and every surface (project page, portfolio, attention inbox) reads that tag. Commitments and material requests are always supply. Decisions and selections are always answer. Inspections and hand-declared dependencies read as supply, since neither is a customer-intent question.
Each spine has its own color: supply reads calm amber ("waiting on someone else"); answer reads red ("only we can clear this"). A missing delivery and an unmade decision are different kinds of stuck.
Nobody sets a spine by hand — it derives automatically from what kind of thing is blocking work, so the tag never drifts out of sync.
Related: commitment, decision, selection, material request, dependency, readiness.
Commitment
Working nowA commitment is "who promised to be where" — a trade arrival, delivery, quote, or callback. It sits on the supply spine.
It tracks two separate things: the promise outcome (open, met, missed, rescheduled, cancelled, or superseded) says what happened; the confirmation state (unconfirmed, confirmed, or at-risk) says how sure anyone is. A confirmed no-show and an unconfirmed on-time arrival are different problems — collapsing them hides that.
A commitment reads "at risk" when flagged at-risk, its expected time passed while open, or it's unconfirmed and close to due. It can raise a blocker on its step. Rescheduled trades stay live; only met, cancelled, or superseded ones drop off. A "gone silent" signal flags commitments unchased in a long stretch, before overdue.
Rescheduling keeps a commitment on the board with a fresh expected time; it resets confirmation since a new date is a new promise. A PM can fold a stale commitment into a replacement, keeping history.
Only a project manager or above can log or edit; anyone can see it.
Related: two-spine model, readiness.
Decision
Working nowA decision is an open question that needs someone's call — a client or designer choice, not a finish/fixture pick — captured once instead of living in memory or chat. It sits on the answer spine.
"Waiting on a decision" becomes real and trackable, not vague. A decision carries a due date, an owner note, and any dollar impact once made. While open it counts as a live wait; once decided or cancelled, the wait clears.
An open decision links to the work it touches — a task, step, commitment, or others — so a reader sees exactly what it's holding up. A decision reaching a step raises a blocker as long as it's open. Decisions with approaching due dates surface sooner, so fast choices don't get buried.
Approving a client change order automatically creates one linked decision recording the approval — logged once, not twice.
Only a project manager or above (or a designer, on their allowed pieces) can create, edit, or decide.
Related: two-spine model, selection, readiness.
Selection
Working nowA selection is a client finish or fixture pick — a tile, a faucet, a light fixture. It sits on the answer spine: a decision-and-money question only the client or PM can settle.
It groups by category (kitchen, bath) and gives every finish choice one home: a budgeted allowance, a lead-time note, and a need-by date. A selection moves through three states: open (nothing picked), proposed (option on the table), and chosen (settled and locked).
A selection with a passed need-by date while still unchosen is overdue. When the chosen price exceeds its allowance, convert the overage directly into a client change request — one step.
Unlike a decision, a selection tracks at the project level, not tied to a schedule step. It shows in a project's list of open answer-spine items.
Only a project manager or above (or a designer) can create, edit, or move a selection forward.
Related: two-spine model, decision.
Material request
Working nowA material request is a crew member's "I need this amount of this material for this job" — raised on site, tracked until it arrives. It sits on the supply spine.
It replaces "waiting on materials" with a real list: what, how much, and by when. It's quantity-only; it never carries a price. It's a coordination list, not a purchase order. A request can tie to a task and step so the wait shows where work is stuck.
The lifecycle: sent → office has it → on the way → on site, or cancelled. "On the way" records how it's sourced (bought, from storage, from another site) — not always a purchase. While open, it's a live blocker on its step; overdue if the need-by date has passed. A request can be marked blocked with a visible reason without losing its place.
The crew member who raised it (while open) or an office lead can edit it; only an office lead can cancel.
Related: two-spine model, commitment.
Readiness (ready to start)
Working nowReadiness is a quiet "this step is now clear to start" signal that appears when the last blocker clears — the mirror image of a blocker.
It answers a narrow question: not "is this project healthy" (that's structural health), but "is this step unblocked enough to begin." It tracks only what the app knows with confidence — a dependency, an inspection, a commitment, or a decision — not a material request or selection, which don't attach cleanly to one step.
A step only becomes a candidate if it had at least one tracked item reaching it; a step with nothing tracked stays silent rather than falsely announcing "ready."
An upcoming step with every tracked item cleared shows "Ready to start." A manually blocked step, once its tracked items clear, shows a softer prompt — asking whether to unblock it, since the person who blocked it may have had a reason the app never saw.
Nothing here changes a step's status automatically; a human still has to act. A step ready but weeks away stays a quiet signal rather than pushing into anyone's inbox.
Related: step, two-spine model, dependency, commitment.
Inspection
Working nowAn inspection is a booked or completed inspection recorded against a project — a city permit inspection or in-house quality check. Most tie to one step in the schedule, but an inspection can stand alone for a general walkthrough.
It exists to track outside-world checkpoints separately from the app's schedule, and to explain why a step is stuck.
An inspection moves through: not scheduled → scheduled (when a date is set) → passed, failed, on hold, or not applicable. Booking the date satisfies a step's "book this inspection" reminder.
A failed or on-hold inspection automatically counts as a blocker on its step (waiting on outside world). A pass clears the way. Turning a failed item into a tracked punch-list item is always manual — a failed inspection alone never creates one.
Only field supervisors and above can book or record an inspection result. Inspections have no connection to safety or incident reporting.
Related: step, deficiency.
Daily goal
Working nowA daily goal is a short line a crew member writes for themselves at the start of a work day — literally "what does done look like today?" A person can write more than one for the same day and project.
It gives each field day a self-set target without adding paperwork. The crew sets it, not the office; it carries no payroll meaning.
Each goal moves through a simple ladder: planned, started (with rough progress checkpoints), then done. A goal can also carry to a later day instead of finishing. At day's end, wrap records a final verdict for each goal — done, not done, or partially done — which decides if it carries forward automatically.
Any crew member on the project that day can write and advance goals. The office has read-only access: a glance view across projects, plus a one-tap "nudge" that pings the Slack channel if nothing's posted. Office can't add, edit, or advance goals.
Posting goals to Slack is a manual crew action; never automatic.
Related: wrap.
Wrap
Working nowA wrap is the once-a-day close-out report for a job site, filed by crew. It doesn't ask the crew to type anything new — it gathers what the day already produced into one readable report.
The office gets one clean end-of-day picture per site (what got done, how the site was left, who worked) without re-entering information.
A wrap pulls together: daily goals marked done, not done, or partially done; site-cleanliness photos; a count of other photos; and the reporting person's hours, broken out by work type.
One running log per site per day. Filing the wrap closes that day's log; refiling afterward updates it — the office sees the update, not a hidden overwrite.
The filer chooses "just me" or "whole crew." "Whole crew" gathers everyone's photos and goals but stays one report under one name, not separate entries per person.
Anyone clocked onto a site that day can file its wrap with no special permission. The office can mark a wrap "seen," sending a quiet confirmation back.
Related: daily goal.
Heads-up
Working nowA heads-up is an item on one of two personal lists: the office's Needs you or the field's For you. Each pools everything needing that person's attention across every project they can see in one place.
One shared set of situations triggers a heads-up: a blocked step, a pending change order, an inspection due, an unresolved punch-list item, a missed end-of-day report, and more. The office and field lists stay in sync about what counts as needing attention.
The office groups items into: Act now (urgent), Waiting on others, Ready to start (positive signal; can snooze but not dismiss), and Snoozed. The field groups around office requests: Act now, Answered (replies to things they raised), and From the office (one-way messages).
A person can mark an item seen, snooze it, or dismiss it. Dismissing clears it from their personal list only; the underlying issue stays open until someone actually handles it.
Visibility is personal: project managers and field supervisors see only their own projects; owners and admins see everything.
Related: notification.
Notification
Working nowA notification is a saved record that something happened, paired with a best-effort push to a person's phone or browser. It's separate from a heads-up: a heads-up disappears once handled; a notification stays as durable history reachable from a bell icon.
It exists so nothing important is shown only once and forgotten, and someone can always look back to confirm they were told about something.
Every notification falls into one of four categories: safety and urgent alerts, messages sent to you, changes to your work, and replies and decisions. A person can turn any category down except safety and urgent, which is always on and cannot be turned off.
A person's preference controls only whether a notification buzzes their device. It never decides whether the record gets created — that always happens regardless, so the history is complete even for muted categories.
Push delivery is best-effort, not guaranteed. If a push fails, it's logged and dropped; the saved record is the fallback.
Related: heads-up.
Template
Working nowA template is a master blueprint of phases and steps for one project type: new build, extension, takeover, or basement renovation. It seeds structure only (no dates, people, or budget codes) — just the shape of the schedule.
When a project is created, the app makes an independent deep copy of that type's active template into it — real, separate phase and step rows, not a live link. Editing the project schedule never touches the template, and vice versa. A template step can carry a checklist and booking prompts to copy in, so new projects' steps arrive already carrying the same checks and requirements.
Only one template per project type is active — the one new projects copy from. Marking a different template active turns the old one off automatically. (Creating a new template as active is a gap today — needs careful review.)
Today, only the new-build template has a filled-out step list. Extension, takeover, and basement renovation templates are empty shells — their step lists need definition.
Only the owner or admin can create, edit, or activate a template.
Related: a template's steps can each carry a checklist and booking prompts; creating a project triggers the copy.
Deficiency
Working nowA deficiency is a punch-list item — a defect or fix tracked against a project, optionally pinned to a room or area. It doesn't attach to a step or task; it stands alone against the project.
It gives "things that need fixing" a durable, assignable record that outlives the moment someone spotted it, instead of living only in conversation or photos.
It's created two ways: raised by hand by anyone on site, or spawned from a failed inspection item. Spawning is deliberate — an inspection failing never creates one automatically.
It moves through open, fixed, verified, closed, or won't-fix, and can reopen if something resurfaces. Whoever marks it fixed can't verify it — a second person has to confirm, the same two-person check used for safety fixes.
An inspection-raised deficiency open more than a week gets pushed back to the office — "still open, fixed on site?" — so it can't quietly go stale. A hand-raised one appears right away.
A deficiency carries photos using the app's shared photo pipeline, including a proof photo when marked fixed.
Who can create, fix, or verify: field supervisor and above.
Related: inspection, heads-up.
Modification request
Working nowA modification request (MR, or change order) is the record of a client-facing change — what changed, why, and the cost — priced and tracked to client sign-off.
It exists so out-of-scope work is priced and agreed before it happens, and the client-facing dollar total reflects only what's signed, not just proposed.
An MR moves through: draft → quoted → sent → approved, declined, cancelled, or withdrawn. Once sent, price locks; approved is final. One MR can supersede an earlier one as a revision — the original drops from the money total once its replacement is approved.
Creating, sending, and approving an MR is project-manager-and-above. Field supervisors cannot touch these.
The client agrees outside the app (call, text, signed document), and office enters evidence afterward. Approving immediately counts toward live budget numbers the client sees and logs a permanent decision record.
A sent MR shows on the office attention list as awaiting sign-off.
Intended / gap: cost ties to budget, but there is no schedule-impact tracking — approving a change never touches the schedule or creates a task.
Related: budget code.
The office app
Pick a screen — each one is generated straight from its unit, status badge included.
Office — Project Overview
Working nowThe Overview is the office's home base for a single project. It answers "what's the state of this job and what needs doing?" and shows only what's relevant today.
At the top sits a single headline — one line chosen in order of importance: a live blocker, else the best next action, else what changed since you last looked, else the day's site-log status, else "all clear." Only one line, never a stack.
Below it, the action queue ranks "do this next" — active blockers first (ordered by how much work they hold up), then overdue decisions, failed inspections, and so on.
Down the right is the Today rail: tasks due today, an "Upcoming" card that merges dated steps, booked inspections, commitment follow-ups and material need-by dates, and a "Reports" card for site-logs the office hasn't acknowledged yet.
A header control opens the on-site roster — who's clocked in right now versus who was scheduled — with a per-person "Send" that pushes a note straight to that person's phone.
Related — an inspection fails, and where the day's work and photos land.
Office — Portfolio Dashboard
Working nowThe Portfolio dashboard is the cross-project home screen — see every project at once without opening each one.
At the top, four numbers summarize the active book: active projects, projects at risk, open blockers across all, and projects with someone on site.
Projects appear as rows grouped into bands: "your projects" (at risk first), then the rest of yours, then other visible projects. Each row shows project name, address, manager, on-site status, health pill (on track / at risk), current phase, open-blocker count with the most pressing one spelled out, and its next milestone. Rows sort so your own projects and riskiest ones surface first. Tapping opens that project's Overview.
What you do here — read-only by design. It's a fast scan of the whole portfolio that points you into the right project. The only control is click-through.
Who can use it — Everyone signs in and sees this dashboard, but what shows differs by role. Owner, admin, accounting see the entire active book. A project manager sees their own projects grouped first, with other visible projects below. Field crew and designers see only projects they belong to. A project someone can't see never shows — no way to tell it from a project that doesn't exist.
Related — Overview uses the same health, blocker, and milestone calculations, so the two screens never disagree. Blocker detail lives in the two-spine model.
Office — Project Coordinate Tab
Working nowThe Coordinate tab tracks everything outside the office's direct control: open questions, promises from trades and vendors, client-requested changes, finish choices, and the paperwork and messages they reference. Up to seven sub-tabs appear, some only when the right integration or role exists.
Decisions lists every open question waiting on someone to choose, tagged with which readiness spine it sits on. Closing one can free a step.
Commitments tracks promises (trade arrival, delivery, quote, callback) with two facts: status (open, met, missed, rescheduled) and whether anyone re-confirmed it's still good. A booking from the Schedule tab lands here.
Modification Requests ("Changes") is the client change-order log: priced, sent, then approved outside the app or declined. Approving is final and auto-records a matching decision; changing course needs a new request, not an edit.
Selections tracks finish and fixture choices per category, open through proposed to chosen. Choosing above the allowance offers a one-tap draft change order.
Recovery recovers a photo or document soft-deleted within 30 days. It never permanently erases anything. Owner/admin only.
Files shows the project's linked Drive folder (read-only).
Comms shows the project's phone line live — texts and calls with reply. Nothing here is stored by Datum; a phone outage reads as exactly that.
Who can use it — everyone with project access browses Decisions, Commitments, Changes, and Selections. Deciding and approving is limited to roles that own that spine, typically a project manager or above. Files and Comms are hidden for field crew and when Drive or phone isn't configured.
Related — decision, commitment, selection, modification-request, and the two-spine model.
Office — Project Field Tab
Working nowThe Field tab is where the office sees what the crew is doing — to-do list, day's report, and clocked time — in three sub-tabs: Tasks, Daily log, and Time.
Tasks splits into an office band (calls, ordering, permits — crew doesn't see) and a field band (crew's phone). Field tasks use a stage-then-send rhythm: "Plan today" sets a due date quietly, then "Send to crew" notifies people — only pushing task-list changes. Sending also decides which budget code bills the work. Every task has status (open, blocked, done); a crew flag opens a two-way comment thread the office resolves.
Daily log is the day's report in one place, auto-assembling task moves, photos, clock-ins, commitment changes so nothing gets typed twice. The office posts a running update or summary note; a one-tap "Seen it" acknowledges the crew's end-of-day wrap. Publishing can mirror it to the project's Slack channel, best-effort.
Time lists this project's clocked time entries — who worked when, on what code, for how long. An entry can be corrected here; overriding a locked entry is restricted.
Who can use it — everyone with project access reads all three. Defining or reassigning tasks needs field supervisor+. Publishing a daily-log note needs field supervisor+; acknowledging a crew report needs project manager+. Correcting a time entry needs supervisor+; overriding a locked entry is owner/admin/accounting only.
Related — task, budget-code, wrap, and Time & Timesheets.
Office — Project Schedule Tab
Working nowThe Schedule tab is the real build sequence — an ordered list of phases and steps, not a checklist. Four sub-views: Schedule, Inspections, Deficiencies, Graph (desktop only, off by default).
What you see — the Schedule sub-view lists steps grouped by phase as a list by default, with Gantt and Calendar views. Each row shows status, dates, task count, and one advisory: the loudest reason it's stuck, or "ready to start" once its last gate clears. Opening a step shows dates, attached checklist, tasks, linked commitments and inspections, and any dependency. A blocked step shows a short reason, cleared automatically once it moves off blocked.
Read-first design: everything opens read-only. An explicit "Edit" toggle (shown only to people who can define the schedule) reveals reordering, renaming, dates, checklists, tasks, and dependencies. Removing a step is always an archive, never a delete.
Inspections lists every scheduled inspection with status, date, and result. Passed frees downstream steps immediately; Failed or On hold keeps it open; N/A is final.
Deficiencies is the walkthrough punch list: open → fixed → verified → closed. A second person must verify a fix before it closes.
Graph is a dependency planner, not a read-only picture: beside the critical-path view it can edit durations, add dependencies, and try what-if changes before committing them. Desktop-only, off by default until an admin enables it.
Who can use it — everyone reads every sub-view. Changing a step's status or reason, editing structure, and applying checklists need project manager+. Adding or reordering tasks need field supervisor+. Recording an inspection needs inspection-management access. Raising or fixing a deficiency is open broadly; verifying needs a second person.
Related — step, phase, checklist, dependency, milestone, gate, and two-spine blocker model.
Office — Project Setup Tab
Working nowThe Setup tab is a project's configuration home — things you set up once and rarely touch. Eight sections in a single-open accordion: Team, Stage, Site details, Project pin, Codes, Drive, Calendar, and Quo. Each loads only when opened.
Team — the project's roster: who's working this build and their role on it. Separate from company-wide role; describes this project only.
Stage shows and (for the right people) changes the project's overall lifecycle stage (pre-construction through warranty/complete). The narrowest control on this screen.
Site details holds address, access notes, and site information the crew and office rely on. Project pin places the exact map location for on-site verification.
Codes manages which company budget codes apply here — pruning the shared catalogue to what's relevant.
Drive, Calendar, and Quo connect this project to its company Drive folder, Google calendar, and phone line. Each section is absent — not shown, not disabled — when that integration isn't configured company-wide.
What you do here — configure the project once (team, site facts, codes, integration links) and occasionally revisit the stage. No read-first toggle because everything here is for people who set projects up.
Who can use it — the tab is visible to project managers and above. Most sections follow that bar; changing the stage is owner/admin only.
Related — project, budget-code, and Templates manager (owner/admin only).
Office — Templates Manager
Working nowThe Templates manager is the company's master library: blueprints for new projects and shared catalogues. Five tabs: Project templates, Checklists, Hazards, Inspections, and Codes.
Project templates holds one blueprint per project type: phases, each with ordered steps. Steps can carry notes, be flagged as gates, have checklists attached, and list booking prompts (like "Book: framing inspection"). Only one template per project type is active at a time. Creating a project copies the active template; editing the template afterward never changes existing projects, and editing a live project never changes its source template.
Checklists is a reusable, versioned checklist library, attachable to many template steps and live tasks. Publishing a new version doesn't rewrite ticks already made against the old one.
Hazards is the library of entries used by the daily safety check (currently off).
Inspections holds pass/fail criteria for recording inspection findings.
Codes is the master budget code catalogue — company-wide list that project managers prune to what applies on their project.
What you do here — build and edit templates (add/reorder/delete phases and steps, toggle active, attach checklists and booking prompts), and maintain the four shared libraries. Removing a phase or step from a template only affects future projects created from it.
Who can use it — owner/admin only. Anyone else sees a message saying so, with nothing to view or edit.
Related — see template, checklist, booking-prompt, gate, and budget-code. New projects are created from Project setup; the resulting schedule is worked from the Schedule tab.
Office — Time & Timesheets
Working nowTime & Timesheets rolls up clocked time from every project for review, correction, and payroll/billing handoff. Two linked screens: Accounting (billing timesheet, payroll, clock locations) and Time fixes (approvals and payroll export).
The billing timesheet is a drill-down tree of the working week (project → budget code → employee → shift, or employee-first), each level with running total and billable/non-billable split. Read-only hours only, no wages. Exports as CSV for invoicing.
Payroll shows per-employee regular-vs-overtime split per pay period (overtime: >8 hours in a weekday or >44 for the week).
Clock locations flags where clock-in or clock-out happened far from the job site — site-supervision check, not a pay decision.
Time fixes is the approval queue for crew-proposed corrections and office time-off requests. Nothing changes on the real timesheet until approved. It also holds the Payworks export: previewable without consequence, or pulled for real to permanently record and lock every shift that period. Later corrections need explicit override. Three distinct exports: per-project/code CSV (invoicing), per-employee operational CSV, and per-employee Payworks CSV (locks pay period).
Who can use it — billing timesheet (hours only): project managers and above (PMs don't see it in menu but can reach it directly). Payroll, clock locations, and Payworks export: owner/admin/accounting only — PMs never see wages. Approving time fixes: project manager, admin, or accounting. Overriding locked entries: owner/admin/accounting only.
Related — see budget-code for how each hour gets tagged, and the project Field tab for a single project's own time entries and corrections.
The field app
Pick a screen — each one is generated straight from its unit, status badge included.
Field — My time
Working nowMy time shows a crew member their own time: placements this week, clocked today, and recent history. Stacked in order of questions.
What you see
Today: every shift clocked today with running total (current shift stays live and counts up).
My week: office's Monday–Friday placement plan — job(s) per day, who else is there, and "Changed" flag for office moves since you last looked. Plan, not actual record.
Earlier shifts: roughly the last 45 days, grouped by day with daily total. Shifts past payroll cutoff show a lock and can't be corrected.
What you do here
On any unlocked shift, "Suggest a fix" proposes corrections — wrong job, wrong time, missing budget code — or add a whole forgotten shift. Nothing on the real timesheet changes until office approves. A shift you're currently working can only be corrected on job or start time, since it hasn't ended yet.
"Fix my time / time off" button opens a same-day sick call-out and full time-off request (both currently switched off for the pilot — leave runs through the older system while the two are used side by side, so this app only shows the door once that changes).
Who can use it
Crew members see and can only propose changes to their own time. Office roles review and approve fixes and time-off requests, and hold final say on budget codes and payroll wages (which don't appear here).
Related: budget code, wrap
Field — Project
Working nowThe Project tab is the field app's look-something-up tab — read-only site record plus today's on-site picture, for checking things rather than acting on them.
What you see
The house — durable property record kept current by office: address, door code, parking notes, homeowner name, access notes. Read-only for crew, with "confirmed [when]" line and one-tap "Still right?" to flag it's up to date.
Today here — the day's dynamic picture: Crew today (who else is on this site), From the office (notes or checklists with a place to reply or push back), Materials (every open request), Inspections glance (status of booked or completed), and Punch list glance (open snags unresolved).
If you're placed on or clocked into more than one job, a switcher at the top lets you flip between them. A supervisor or PM always sees every active job in the switcher, not just their own placements, since they float across sites.
What you do here
Mostly read. You can tick off items on the office's daily briefing, reply to it, confirm the property record is accurate, and raise a material request. Recording an inspection result or working the punch list hands off to fuller pages, and only opens for roles allowed to record those.
Supervisors and PMs (not regular crew, whose posts follow the clock from Today) also get the "Say something" button here, aimed at the selected job.
Who can use it
Crew members see their own placed or clocked-into sites. Supervisors, PMs, admins, and owners can browse and switch to any active project.
Related: material request, inspection, deficiency, and an inspection fails.
Field — Settings
Working nowSettings is the field app's per-person control panel: turn notifications on for this phone, choose what reaches it, see linked phones, switch app look, and sign out. Laid out by the core question: "will my phone actually buzz?"
What you see
This device — whether push notifications are on for your phone. Separate from wanting them: the phone's permission must be granted and a subscription must exist. iPhones must be added to Home Screen, since that's the only way iOS allows notifications.
Notifications — four categories: safety and urgent items always on and can't turn off; messages to you, work changes, and replies can toggle. Saved preferences, editable even if this device can't receive push yet. A note shows when nothing arrives until you enable the device.
Your devices (linked phones) — every phone set up to notify you, with your current one marked. Shows only a label and when it was added.
This app — light/dark theme switch and sign out.
What you do here
Turn this phone's notifications on or off, adjust the four categories, and sign out. If work hasn't finished syncing, signing out warns you first, since it could sit unsent until you're back on signal.
Who can use it
Crew members manage only their own device and preferences. Nothing here is shared or visible to anyone else.
Related: notification, heads-up
Field — Today
Working nowToday is the field app's home tab: one screen for doing something right now — clock in, see what the office needs, check off work. Phone-first, built for a gloved thumb.
What you see
Clock-in control sits at the top. Off the clock, tap a recent job or search another, optionally tag tasks, and confirm. Once clocked in it becomes "This shift": door code, what you're on, how the hour is billed, and a link to wrap. A clock/stop bar stays pinned to the screen bottom for the shift.
"For you" is your personal inbox: things the office is waiting for, replies to things you raised, and one-way notes. A bell in the header keeps a running history of everything sent to your phone as a backstop for missed push notifications.
A daily safety check and today's goals open here (where turned on), right after clock-in — a safe / not-sure / stop-work call, and a line you write for "done" today.
Below sit your open tasks for today and a collapsed "Done today" list to see what you've finished.
What you do here
Clock in and out, tag tasks, answer "For you" items, take the safety check, write goals, and use "Say something" — one floating button for posting an update, raising a heads-up, reporting a problem, or asking for materials, aimed at your clocked-in job.
Who can use it
Crew members see their own Today. Supervisors and PMs see the same layout but can also post to a job they aren't clocked into (from the Project tab instead).
Related: daily goal, wrap, heads-up, notification, task
How it flows
Real workflows — an event happens, the app does what it can on its own, then a loop of steps gets it resolved. Pick a flow on the left, then tap any box to open it.
Features & connected
The whole capability layer — including the outside connections (Google, Slack, Quo) and whether each is live, off for the pilot, or still on the roadmap. Grouped by status.
Attention & notifications
Working nowThe app keeps two separate personal "what needs me" lists and a shared notification gate that decides what reaches a phone. This is core, always-on for everyone.
Its parts. In the office, Needs you pools everything needing attention across every visible job, sorted into bands: act now, waiting on others, ready to start (snoozed only, never dismissed), and snoozed items. In the field, "For you" shows what the office actually needs from the crew today. Both lists pull from the same registry (blockers, readiness, change orders awaiting sign-off, inspections due, stale punch-list items, missed end-of-day reports), so they never drift apart.
A shared notification gate sits underneath. Alerts fall into four categories: safety and urgent (never off), messages to you, changes to your work, and replies or decisions. A person's preference controls only whether an alert reaches their device as a push — it never affects what shows in the app itself. A history (the bell) stays in both apps as a fallback, since push notifications are never guaranteed.
A built, tested escalation ladder chases unseen safety alerts: phone push, then Slack a few minutes later, then text after that if still unseen. This ensures a genuine stop-work never sits unread.
Status: live, except the escalation ladder. The two lists and gate are always-on core. The ladder arms only for safety events, and both safety features that would create one are currently off (see Safety system) — so nothing climbs the ladder today, though the logic is finished and tested. It activates automatically when safety turns back on.
Open decisions. Who should receive safety alerts and by what channel before the ladder can turn on. A secondary question: should SMS stay part of the ladder, or stop at Slack.
See also: office overview screen, field today screen, notification.
Daily goals & wrap
Working nowThe field crew's daily rhythm: a short self-set goal at the start of the day and one report at the end. Both are active for the pilot today.
Its parts. A daily goal is a short line a crew member writes for themselves — "what does done look like today?" — tied to one person, job, and day. It has no payroll meaning. Crew writes it, ticks it forward through the day, and can manually post it to the job's Slack channel. Office sees it read-only, with a one-tap "nudge" if a site hasn't posted.
Wrap is the once-a-day close-out. It assembles a report from what the day recorded: the goal settled (unfinished items carry to tomorrow), site-cleanliness photos, count of other photos, and hours by budget code. One entry per site per day, with a choice between "just me" or "the whole crew," so one lead can wrap the group. Once wrapped, a second crew member sees it's already done, and the office can acknowledge it with one tap — though the "office saw it" receipt on the crew's side is switched off for the pilot.
Status: live, though differently. Wrap is unconditionally always-on — core to the app. Daily goals sit behind a feature switch defaulting off in code, but deliberately turned on globally for the pilot as the in-app replacement for what was a Slack-only ritual. In practice, both are live for every user; the difference only matters if the switch were turned back off.
Open decisions. None outstanding — this ritual has already been shaped by real usage.
See also: field today screen, daily-goal, wrap.
Scheduling
Working nowThe schedule is the app's spine: the ordered work plan, what's done, what's stuck, and whether the job is on track. Core, always-on.
Its parts. A job's plan is phases (chapters), each with an ordered list of steps. A step is upcoming, in progress (parallel is normal), blocked, done, or "not applicable" (job doesn't need it). Only a PM or above changes status. A manual block always carries a short reason, cleared when the step moves — nothing stays blocked by accident.
Gates are checkpoints (advisory only). The milestone is the next gate ahead of actual work — a position, not a date guess. Structural progress is the percentage of steps done. Structural health is the on-track/at-risk read that the project page and dashboard both use, so they never disagree.
When work is stuck, the reason sorts onto one lane: Answer (needs a decision or pick) or Supply (outside world isn't ready — trade hasn't shown, material hasn't landed, inspection hasn't passed). See two-spine. Commitments, decisions, and step-to-step dependencies feed this automatically — a blocked step is never a mystery. When the last tracked reason clears, the app notes the step is ready to start; it never unblocks anything by itself.
Status: live. The whole spine (phases, steps, gates, milestones, blockers, readiness) ships as always-on core; no admin reveals it. A visual map of step-to-step dependencies is built but switched off (future "power planning" wave). Dependencies exist and track either way — only the graph view is hidden.
Open decisions. None block daily scheduling use. One gap: new jobs with no template start with an empty schedule, no warning. See templates.
See also: office schedule screen, office coordinate screen.
Tasks & dispatch
Working nowConcrete to-dos under the schedule — "order the tile," "call the inspector," "hang drywall." A task sits under a step or stands alone. Core, always-on.
Its parts. Each task sorts onto one of two tracks at creation: Field (shows on crew's phone, can be sent) or Office (calls, ordering, permits — never on the field app, keeps crew list uncluttered). Office tasks have exact appointment times; field tasks are day-level only.
Sending a field task is two acts: office plans it (sets target day), then sends it. Push goes only to who changed, not everyone. Any crew member can execute any task on their job — mark done, add photos, add sub-steps — with no permission check, matching how small companies actually work. Defining a task (create, edit, reassign) is supervisors and above only.
Two feedback loops return: crew flags a problem with a task (real back-and-forth thread with photos, not one-way) and office resolves it; crew can also close it once sorted. Separately, office can ask crew to confirm something's done; crew clears it once, then office checks back rather than a fresh alert being pushed.
Every task requires a budget code tag, so time and cost land somewhere trackable.
Status: live. Tasks and dispatch ship as always-on core — no admin switch needed.
Open decisions. None. One design choice worth knowing: when office asks crew to confirm a task is done, no fresh notification pushes — office notices on their own list. That's by design, not a bug.
See also: field project screen, office coordinate screen.
Templates
Working nowReusable blueprints so new jobs don't start blank. The mechanism is built and used daily; what's missing is content for most project types.
Its parts. A template is a master phase-and-step blueprint for one project type. When a new job is created, the app makes its own copy of the active template. From then on, editing the live job doesn't touch the template, and editing the template doesn't reach back into jobs already created. Removing a step from a live job is always reversible archive, never hard delete.
Two libraries support templates. A checklist library holds reusable, versioned checklists. A checklist copied onto a task is frozen — later library edits don't touch it. But one attached to a step follows the library's current version, so publishing a new version updates that step and can reset items already ticked there. (A snapshot-on-apply model, where no library edit ever disturbs live work, is planned.) An inspection-criteria library holds standard pass/fail criteria for inspection types. A hazard library feeds the daily safety brief — see Safety system (currently switched off).
Only owner and admin manage these libraries; others work from what the template or checklist produced on their job.
Status: live, with one gap: only new-build has a defined template today. Extension, takeover, and basement-renovation templates don't exist — their step lists are needed from Jesse. Starting a job under those types gives no starting plan, and creates with no warning.
Checklist and inspection-criteria libraries are fully built and independent of that gap — they work for whatever templates and tasks exist.
Open decisions. Jesse needs to walk through extension, takeover, and basement-reno step lists — roughly 1–2 hours like new-build was defined. Until then, three of four project types have no usable starting schedule.
Technical note: the rule that only one active template per type is enforced when a template turns on or edits, but not when first created — so two active templates of the same type is possible by accident, in a narrow edge case.
Timesheets & exports
Working nowEvery crew hour flows into one record — from a phone tap through payroll and invoicing. Core, always-on.
Its parts. Clock in/out (see field-day flow) stamps time instantly. The raw record rolls into a week view (person, project, budget code), computed fresh every view — no separate copy that drifts. A lunch break is unpaid time removed from the shift before hours are totaled, and a break over the paid limit is flagged for the office. To correct a shift, office edits it directly (locked entry needs owner, admin, or accounting sign-off), or crew proposes a fix for office to approve/decline. Nothing on the real record changes until office says so.
Three exports come from this record:
- Per-employee payroll file. Shaped for the payroll processor — regular hours, overtime, leave (one file per employee). Pulling this file locks the pay period. Overtime is the greater of the daily rule (hours over 8 in a weekday, Monday–Friday) and the weekly rule (hours over 44 in a Sunday–Saturday week), never both stacked.
- Per-project file. Grouped by budget code, for invoicing clients on work actually done.
- Raw dump. Behind-the-scenes, for double-checking exported numbers — not client- or payroll-facing.
Wage figures show only to owner, admin, and accounting roles. Project managers see hours, never dollars.
Status: live. Clock-in/out, timesheet review, corrections, payroll lock, and all three exports are always-on core — no switch needed. No live connection to payroll or accounting software today — every hand-off is a downloaded file by design, with direct connection possible later.
Open decisions. Payroll lock is active — pulling a payroll file freezes that pay period. The backstop cutoff (how a period locks if payroll was never pulled) needs real numbers from Kristen before it's finished. Until then, lock engages only when a real payroll file downloads.
See also: step, budget-code.
Google integration (Calendar, Drive, sign-in)
Switched offThree related capabilities on one Google connection: a one-way project calendar, a read-only view into project Drive files, and real Google sign-in.
Its parts
- Project calendar. App owns one calendar per project and writes to it: steps, bookings, key dates. Press Sync to push the latest schedule out. Nothing flows back from a manual Google edit — Google changes are overwritten on next sync. No automatic trigger; someone presses the button.
- Personal calendar glance. Office staff see their own connected Google calendar inside the app as a read-only strip, fetched live each time, never stored.
- Drive browsing. A project points at an existing Drive folder; app shows a read-only, office-only view of that folder and subfolders. Nothing uploads or changes on Google's side — it marks which file version is "current" for Datum's bookkeeping only; opened files stay untouched.
- Google sign-in. Staff log in with their real Google account. This part is genuinely live.
Status, and why
Calendar and Drive are built but switched off — they need four configuration pieces together: OAuth client id, its secret, redirect address, and encryption key for tokens. None are set in production yet. Until all four exist, the whole capability does nothing: no menu option, no background work, no real data. Built this way on purpose to ship dormant and switch on later without a new deploy — just configuration.
Google sign-in is a separate switch and is live: production app refuses to start unless real sign-in is on (no fallback to "pick a name" developer login), so this half already runs every office login today.
Both calendar and Drive are strictly one-way by design, not just by current limitation. Even once configured, nothing written in Google flows back into the app — deliberate, to avoid the app quietly losing track of the schedule to a Google edit.
Open decisions
- Turning on Calendar/Drive is a configuration task, not a product decision — the four setup pieces need to be created and entered.
- Confirm, once configured, that syncing behaves the same in the live environment as in testing (code-verified but not yet tested against a real Google account in production).
This integration is currently switched off.
Quo (company phone) integration
Switched offA read window into the company's Quo phone system (calls and texts), so office staff can see phone activity for a project without leaving the app.
Its parts
- Line assignment. Link a project to one of the company's Quo phone numbers, so the app knows which line belongs to which job.
- Conversation panel. Browse that line's calls and texts live, straight from Quo — app fetches and displays them but never stores conversation content in its own database.
- Sending. Send a message from the project's line through the app, with an honest "sending…" state.
- Contact matching. Reconcile Quo contacts against the app's people/vendor records by phone number, on demand — fills gaps only, never overwrites or silently creates records.
Not included: This covers phone and text only. DocuSeal (e-signature) is not part of Quo and not in the app — see roadmap items — it exists only as a label the app's approval records can reference someday.
Status, and why
Quo is built but switched off — gated behind a single company-wide API key that hasn't been set. Until that key is entered, the whole integration is a no-op: no menu option appears, nothing runs in the background. This uses one shared company credential (not per-staff login), because a company phone line doesn't belong to one person like a personal Google account does.
Open decisions
- None on the product side — turning this on is purely getting and entering the Quo API key. No design or policy is blocking it.
This integration is currently switched off.
Slack integration
Switched offA one-way echo from the app into Slack, plus the ability to reach one person by direct message. Nothing typed in Slack comes back into the app.
Its parts
- Per-project echo. Enter a Slack channel address for a project, and the app posts a copy of the crew's end-of-day report there, with a nudge if nobody has posted for the day. Photos are linked, not embedded (Slack posts can't carry files directly).
- Person direct message. The app can message one named person directly in Slack by email — this is the delivery channel for the escalation ladder in the safety system feature.
- Larger vision, not built. The app could automatically create a Slack channel per project and send organized daily digests — designed but no code exists. Today, someone manually enters a channel address per project; the app never creates it.
Status, and why
The per-project echo and person-DM are built and technically working, but off by default per project — they activate only once a channel address is entered. No global switch; it's per-project configuration, usually not filled in yet.
The larger auto-channel-and-digest vision is roadmap — a real product idea thought through but not coded. A separate piece — messaging someone in Slack when a task is assigned to them — is built and wired: assigning a task sends that person a direct message, with a toggle on the assignment screen. Like the safety alerts, it currently redirects to a test inbox until the routing guard is switched off, so it doesn't reach real people yet.
Open decisions
- How project Slack channels should be set up (who creates them, when, whether the app does it automatically) and what a useful daily digest should contain. Needs an owner decision before the larger vision can be built.
- When to switch off the test-inbox guard so the built-in task-assignment messages (and the safety alerts) reach real people.
This integration is currently switched off.
Safety system
Switched offSwitched off for the pilot — a complete, tested capability waiting on one decision: who receives safety alerts and incidents, and how. Two parts:
Daily hazard check (field-level hazard assessment). Each work day, someone creates one shared brief: what work happens, which hazards apply (each with a control measure and required gear), and emergency basics. Every worker then decides: safe to proceed, proceed with listed controls, "I want a second opinion," or "stop work." That choice is never silently changed to "safe." The office sees a live board of who checked in and what's outstanding.
Incident reporting with Alberta triage. A worker files a minimal report — what happened, where, who. The system suggests (never decides) whether provincial obligations apply: phone-reportable OHS event, WCB employer report (72-hour deadline), or near-miss worth reporting. A person confirms or dismisses each. Fixing an issue needs two different people — one to fix it, another to verify — so nobody signs off their own work.
Why it's off: both halves have switches (both off for pilot) plus a guard routing every alert to the operator until deliberately turned off. Turning on needs a decided routing model first.
Open decision: who receives a safety concern and incident, and how.
Project budgets
RoadmapA built financial-budget capability for tracking project money against plan — separate from timesheet/payroll accounting, which is the pilot's active part.
Its parts
- Import. Bring a starting budget into a project by work-category code (same codes used elsewhere), giving a baseline to measure against.
- Live report. Running view compares budgeted vs. actually spent and committed, refreshed as new costs and time land.
- Labour burn. Crew self-perform time converts to dollars per category — though wage rates are currently a placeholder flat rate, not real payroll, so dollar figures aren't accurate today.
- Client snapshot. Publish a frozen point-in-time summary outside the office, withdraw and re-publish if needed.
- Client direct purchases. Record costs a client pays directly, counted in the full picture without double-billing.
Status, and why
The whole capability is deliberately turned off — budgets were explicitly ruled out of the August pilot's scope. This is not a technical gap: code is built, tested, and switched off on purpose. Turning it on is a configuration change, not a new deployment.
The bigger open item: budgets as a product haven't been fully thought through with the owner yet. Pieces exist in code, but nobody has decided what the ideal budgeting experience should look like, what to show a client versus the office, or how to replace the placeholder wage rates with real ones.
Open decisions
- What should the budget experience do for Datum, and what should a client see versus only the office?
- Real per-person wage rates must replace the flat placeholder before labour-burn dollars can be trusted.
- When (if ever) to turn the flag on for the pilot or general use.
Roadmap — not yet built or deferred
RoadmapThese items are roadmap entries — none yet ready, each early. Listed so nothing is lost in planning.
- DocuSeal (e-signatures) — status: future. Not in the app today. Approval records are already prepared to reference an e-signature service, but no connection, screen, or workflow exists. Two questions first: how to place signature fields on varying document layouts, and how to send a client's email through the service. Relevant only if the app takes on signed documents.
- Designer workflow — status: future. A "designer" role exists and can see decisions and selections, but day-to-day workflow is not built — it's a placeholder. Whether a real designer experience is wanted, and what it should do, hasn't been decided.
- Rooms/zones — status: built-off (no creation surface). Material orders can tag to a specific room or zone (e.g. "kitchen," "primary bath"), and the underlying records exist. No screen lets someone create or manage the room list yet — so it can't be used even though the foundation is there.
- Live Payworks / QuickBooks (QBO) connection — status: roadmap. Payroll and accounting today work by export (spreadsheet download) loaded by hand into those systems. Live, automatic connection is a deliberate later step, not the current design.
- Time-off requests in the app — status: built-off. Built but turned off for the pilot. Requests stay through the existing outside process. Flag: it's hidden from view, not locked down behind the scenes, so treat as "not ready for real use" until that's tightened.
Each item is either not started, deliberately parked, or waiting for one piece — none blocked by a technical problem, only by prioritization.
Roadmap
Every unit across the guide whose status isn't "live", grouped and badged automatically. Tap a title to read the full write-up (or open the board) where it actually lives.
Built, switched off
On the roadmap
status frontmatter — nothing here
is hand-maintained.