Authenticated product and workflow¶

At a glance¶

The contractor application is a project-centric operating system with a strong commercial data spine.

Estimate → Proposal → Bid / Purchase Order → Budget / Actuals → Invoice / Payment

The same project also carries the production and relationship workflows:

Project Setup → Schedule → Specs & Selections → Messages / Questions → To-Dos / Job Log → Files / Photos → Warranty

The modules are not isolated.

Cost-code categories and line items appear to be shared across estimating, selections, proposals, bids, purchase orders, budgets, variations and invoices. Visibility, approval state, notification state and accounting mappings determine which parts of that shared record each participant can see or change.

Scope and evidence¶

This document records observations from a read-only tour of the authenticated CoConstruct contractor application on 3 August 2026. It describes reusable product behavior, not the tenant data in the account used for the tour.

No project, client, team-member, trade-partner, address, file name, message content, account-specific financial value or other tenant data is included here. Existing records and settings were inspected; no project, estimate, proposal, bid, purchase order, bill, message, payment, time entry or setting was created, edited, sent, saved or deleted.

Some controls are tenant- or plan-specific. Treat these observations as verified behavior in one account, with universal product behavior still to be confirmed.

Compare this inside-the-app view with the public product and workflow.

Workflow at a glance¶

flowchart TB
  project["Project record"] --> spine["Shared cost codes and line items"]
  spine --> financial["Financial control\nEstimate · proposal · budget · actuals"]
  spine --> production["Production coordination\nSchedule · hours · tasks · job log"]
  spine --> procurement["Procurement\nBids · purchase orders · bills"]
  project --> participants["Participant experience"]
  participants --> team["Team members\nAccess · assignments · alerts"]
  participants --> clients["Clients\nPortal · selections · approvals"]
  participants --> partners["Trade partners\nSchedule · selections · requests"]
  production --> media["Files · photos · warranty"]
  financial --> invoices["Invoices · payments · accounting sync"]

Product areas¶

Global areas¶

The authenticated shell exposes these main areas:

The shell is an older server-rendered application with some newer financial screens embedded inside it. A replacement should preserve the clear information architecture while being able to evolve individual modules independently.

Help is integrated into the shell through training videos, help-center search, support tickets, webinars, community access and role-specific help articles. This is a useful operational detail for a product used by builders: onboarding and support are part of the product surface, not only external documentation.

Project portfolio¶

The Projects view supports:

• all projects;
• projects requiring attention;
• the current user's projects;
• the current user's projects requiring attention;
• custom filters and project groups;
• Active, Warranty and Archived sections;
• search and project creation.

Project cards expose shortcuts into summary, financials, schedule, selections, variations/status, files, to-dos, messages, warranty and job log. Notification badges on cards and an attention-oriented filter make the portfolio a work queue as well as a directory.

Project-level navigation¶

Each project has a stable navigation structure:

Overview

Financials

• Summary
• Estimate
• Proposals
• Bids
• Purchase Orders
• Bills
• Variations
• Budget
• Invoices

Project management

• Schedule
• Hours
• Specs & Selections
• Messages
• To-Dos
• Job Log
• Files
• Photos
• Warranty Requests
• Project Setup

Most project pages also provide a project search field, an Add To-Do shortcut, client-side preview, print/help affordances and a project switcher.

Project setup and lifecycle¶

Project record¶

The setup form captures more than a name and client. The observed fields include:

• project name and group;
• address, unit/lot/building detail, city, state/province and postal code;
• lifecycle phase;
• warranty expiration where relevant;
• client-access policy;
• financial structure;
• estimates and job-costing toggle;
• base price and custom labels for starting and total price;
• schedule template and start date;
• update clearer;
• team-member project access;
• trade-partner project access;
• one or more clients;
• accounting-system link;
• project color in Task Manager;
• client notification and summary-email preferences.

Lifecycle phases¶

The observed phase model is:

• Prospect — pre-sale management, with some features limited;
• Active — under contract and in progress;
• Warranty — completed project being managed during the warranty period;
• Archived — project complete and no longer needing client access.

This is a useful model for a replacement because it separates sales pipeline work from production and post-completion service without requiring a different top-level object.

Commercial structure¶

The project supports:

• Fixed Price — the contractor sets the client price;
• Open Book — cost-plus and time-and-materials styles where price follows actual cost plus markup.

Estimates and job costing can be enabled or disabled at project level. This matters for smaller builders: a lightweight project can remain operational without forcing every customer into a full cost-accounting workflow.

Commercial workflow¶

Estimate¶

The contractor-side estimate is explicitly marked as not visible to clients. It is a large, expandable cost-code and line-item grid with controls for:

• description;
• quantity and units;
• unit cost and extended cost;
• cost type;
• accounting code;
• multiple fees or markups;
• margin;
• tax;
• total price;
• price per square metre;
• percentage of total;
• notes.

The estimate supports new line items, parameters, markup/margin/tax configuration, expand/collapse, discard and save. It can generate a proposal and export the estimate.

The observed data demonstrates a hierarchical model: cost-code category rows contain child line items, with additional groupings for variations and other line items. A replacement should keep the category and line-item identities stable when the same data is shown in another module.

Proposals¶

The Proposals page describes proposal and contract generation from customizable templates. The list is organized around title, release date and status. The estimate can be used as the starting point for generating a proposal, while proposal templates are maintained globally.

Bid requests¶

Bid Requests can be created from cost lines and include controls for:

• visibility to the client;
• pricing and billing choices;
• attached files and descriptions;
• trade-partner participation;
• sharing through a plan-room or link;
• downloading bid material;
• editing or removing a request from the plan room;
• showing only awarded bids;
• generating purchase orders from bid requests.

This suggests a bid is not merely a message to a supplier. It is a structured commercial request tied back to selected estimate lines and capable of becoming a commitment.

Purchase orders¶

Purchase orders can be created directly, generated from bid requests or generated from the estimate. The page also exposes project synchronization and accounting settings.

The observed PO list includes number, title, issued-to party, amount, status, comments and accounting-system state. The available status vocabulary is:

Draft → Released → Accepted → Billed → Ready to Pay → Paid

with additional states for credit used, declined and voided. PO generation includes options such as one PO for all cost lines versus separate POs per cost line, copying specifications and partner information, hiding lines already on other POs, and selecting awarded bids.

Bills¶

The newer Bills screen presents a supplier/trade-partner bill workflow:

1. upload or add a bill;
2. compare it with purchase orders to catch overbilling;
3. obtain project-manager approval;
4. record payment.

Bills are also surfaced inside the project financial navigation, which reinforces the idea that commitments and actual costs belong to the project record rather than only to an accounting ledger.

Budget¶

The Budget page is a cost-code performance view. Its observed columns include:

• accounting code;
• original budget;
• revised budget;
• committed cost;
• actuals;
• percentage complete;
• projected cost;
• difference;
• cost to complete;
• price per square metre;
• percentage of total;
• notes.

The page also exposes transaction detail and purchase-order detail. This is the most useful single screen for understanding the commercial control loop: the estimate establishes the plan, commitments represent purchased work, actuals represent incurred cost, and projected/cost-to-complete values support forecasting.

Variations¶

Variations have their own project navigation entry, summary report and attention state. They appear in the estimate/financial model as additional commercial line items and flow into invoicing. The project summary exposes a New Variation action and separates approved variations from the base price and selection changes.

The exact approval and client-signature rules should be confirmed with the target builders before implementation.

Invoices and payments¶

The invoice workflow supports creating:

• a progress invoice from the estimate;
• a progress invoice from budget actuals;
• an invoice from variations;
• a new blank invoice.

Invoice lists include number, summary, date, due date, amount, status, client-sharing state and accounting-system push state. The page also reports total invoiced, payments and amount due. The project setup exposes client-payment synchronization and payment methods, while the observed accounting settings are centered on QuickBooks.

Production and communication¶

Project overview¶

The project overview acts as an operational dashboard rather than a static summary. It includes:

• cover photo management;
• schedule/progress state;
• alerts and updates;
• recent photos;
• the current user's tasks;
• financial roll-up.

The dashboard highlights overdue or uncleared activity across financials, schedule, specs/selections and files. Financial cards include base price, selections, variations, total price, cost to complete, invoiced, payments, remaining balance and amount due.

Schedule¶

The schedule has separate draft and published concepts. When a draft exists, the published schedule is read-only until the user goes to the draft. The available views are:

• Field Update View;
• Gantt View;
• Calendar View;
• Task View;
• Baseline View.

The schedule grid includes done state, task ID, task, start, work days, finish, predecessors, assignees and percentage complete. The editor supports task completion, adding tasks, predecessors, assignees, date/work-day changes, attachments and save/publish.

Scheduling settings control predecessor behavior, visible days, assignee notification limits, default views, working-week days and holidays.

Hours¶

The project Hours view records activity-level estimated hours, worked hours, remaining hours and team-member notes. It can also relate hours to specification/selection budget information. The global Time Clock provides clock-in, manual time entry, filtering, settings and export.

Specs and selections¶

Selections are grouped by cost-code category or requested-by date. The page supports new items and includes a category selector. Selection records can carry:

• description/specification;
• amount;
• requested-by date;
• choice;
• status;
• price;
• allowance;
• difference;
• comments;
• change log;
• related files/photos;
• visibility to clients and trade partners.

Selection outputs can be configured from specifications only through everything (specifications plus selections), with options for including files/photos, client information, pricing breakdown and client choices. This is a strong example of one record producing different role-specific documents.

Messages and questions¶

Messages are organized into participant views for clients, team members and trade partners, with the observed tenant explicitly indicating that trade partners cannot view Messages. The message composer supports rich text, links, images, video and file attachments, and provides visibility and urgency controls.

Questions are a separate workflow. The contractor view explains that a client can post a question, after which the contractor can answer and manage related comments. This distinction is useful: a general conversation stream and a question/answer workflow have different response and reporting needs.

To-Dos and Task Manager¶

To-Dos exist inside a project and in a global Task Manager. The common task shape includes a task name, description, due date, internal assignee, trade-partner assignee, client visibility/hidden state and completion/clearing behavior. The global manager adds search, quick filters, page size controls and cross-project reporting.

Job Log, files, photos and warranty¶

• Job Log supports date-range views, including recent-day windows and all dates.
• Files and Photos are separate project destinations with filename, upload-date and posted-by sorting.
• Warranty Requests are a first-class project workflow and global report, with assignee and update-clearer filters.
• Files and photos are repeatedly surfaced from messages, selections, schedule tasks and the project overview rather than living only in a document library.

People and visibility¶

Team members¶

Team-member settings expose project access and an administrator flag. Project setup can select which team members can access a project, and separate alert/notification settings determine how they are notified.

Clients¶

Client access has at least three practical modes in the observed setup:

• no client access;
• email-only notifications;
• login access to the client project view plus email notifications.

Client preferences cover change orders, comments, messages, questions, selection choices, new files and new photos. Client-side preview is available from most project pages, and individual outputs can be controlled for client visibility.

Trade partners¶

Trade partners have their own directory, web-access state and project access. The contractor can select partners for project access and invite/manage their users. Trade Partner Settings control whether partners receive selection information and schedule information.

The observed partner controls also distinguish partner access from general message access. A replacement should model participant permissions explicitly rather than assuming that every project participant sees the same project navigation.

Contacts and leads¶

Contacts support import from CSV, filter and export. Leads add opportunity-specific fields such as stage, sale probability, estimated revenue, estimated sale date and next activity. This is a lightweight CRM layer attached to the same contact system used by projects and clients.

Updates, notifications and clearing¶

The account uses an “updates cleared by” concept across project setup, overview, dashboard and reports. Personal settings include instant alerts, weekly summaries, comment/message notification scopes, email frequency, project email consolidation and calendar feeds. This indicates that notification state is part of the product's workflow model, not just an email preference.

Data, settings and integrations¶

Templates and reusable configuration¶

The global template area includes:

• Cost Catalog — import costs and create new costs;
• Spec/Selection Templates — reusable selection structures by cost code;
• Proposal Templates — reusable proposal/contract documents;
• Schedule Templates — reusable project schedule structures.

Markup, margin and tax¶

The estimating configuration supports multiple markup/margin/tax rows. Each row can have a type, label, calculation, accounting code and a setting for whether it appears in client allowances. The estimate table shows several fees, margin and tax as separate columns, so calculations should be represented as ordered, inspectable rules rather than one opaque percentage.

Accounting integration¶

The observed tenant exposes QuickBooks Online and QuickBooks Desktop integration. Project setup can link a project to an accounting customer and job and can configure synchronization for bills, invoices, client payments, budget actuals and labor costs. Client ACH and credit-card payment settings are also surfaced.

Xero was not exposed in the authenticated CoConstruct settings observed during this tour. Whether that reflects product scope, account configuration or the current migration state needs to be confirmed separately.

The observed tenant also uses locale-specific construction and tax conventions, including GST terminology, metric-area pricing and local address fields. Currency, tax labels, units, date formats and accounting codes should therefore be modeled as configuration rather than hard-coded assumptions—especially if the replacement must serve both US and New Zealand builders.

Other settings¶

The authenticated app also exposes:

• custom branding;
• trade-partner portal defaults;
• holidays;
• lead-intake form embed code;
• personal profile and password settings;
• alert and summary-email preferences;
• calendar feed URLs;
• dashboard thresholds for contacts, questions, to-dos and warranty activity.

Reporting and exports¶

The Reports menu covers:

• all tasks and open tasks;
• all projects;
• purchase orders and variance purchase orders;
• payments and invoices;
• questions;
• to-dos;
• specs/selections;
• variations;
• messages;
• schedule;
• warranty requests;
• job log.

The report family is notable because most operational reports include filters for project, assignee, participant type, status, date or update clearer. Several pages expose reset/run-report controls, and key list pages expose export actions. Reporting is therefore part of daily exception management, not only end-of-period analytics.

Product implications¶

These are implementation inferences from the authenticated behavior, not claims about CoConstruct's internal code.

Shared commercial entities¶

The central entity is likely a project-scoped cost-code and line-item graph. A line item can participate in estimating, selections, proposals, bid requests, purchase orders, budget calculations, variations and invoices. Copying values between modules would create drift; a replacement should preserve references and history.

State is multi-dimensional¶

A record may have separate dimensions for:

• lifecycle status;
• commercial approval/status;
• client visibility;
• trade-partner visibility;
• internal assignment;
• notification/cleared state;
• accounting synchronization state;
• audit/change history.

These dimensions should not be collapsed into one generic status field.

Role-specific projections¶

The product repeatedly renders the same underlying information as contractor views, client views, trade-partner views, reports, proposal documents, selection schedules and accounting exports. This suggests an API/domain model with explicit projections and permission checks, rather than separate copies of each document.

Auditability matters¶

Selections expose change logs, messages retain threaded history, schedules distinguish draft from published, and settings include update-clearing behavior. Any replacement handling pricing or client approvals will need immutable events or a sufficiently detailed audit trail.

Accounting should be an adapter boundary¶

The application carries operational truth while synchronizing selected financial facts with QuickBooks. A replacement should define an accounting adapter around customers, jobs, codes, bills, invoices, payments, labor and actual costs, rather than mixing accounting-specific fields throughout every domain object.

Media is cross-cutting¶

Files and photos can be attached or surfaced in messages, schedules, selections and project overviews. Media should be a first-class object with access rules, labels, uploader, timestamps, project relationship and optional parent-record relationship.

First-release implications¶

The authenticated app supports a much larger scope than the stakeholder says the local companies use. A sensible first release to validate would be:

1. project lifecycle and access;
2. estimate with cost codes, allowances, markup/tax and client-facing proposal output;
3. selections with comments, approvals and change history;
4. variations;
5. schedule with draft/publish, assignees and client visibility;
6. messages, questions, files/photos and a simple job log;
7. project overview with attention/overdue state;
8. budget and cost-to-complete reporting;
9. CSV export and one agreed accounting integration.

Bids, purchase orders, bills, payments, time clock, warranty, CRM, advanced report packs and additional integrations should be retained in the domain model but prioritized only after the target companies identify them as part of their real daily workflow.

Open questions¶

• Which of the observed modules do the local builders use every week?
• Is the shared system intended to serve several companies with strict tenant separation, or one company first?
• Which accounting product must be authoritative: QuickBooks, Xero or another local system?
• Do clients need login access, email-only updates or both?
• Which selection and variation events require formal client approval or a signature?
• Do trade partners need a portal, emailed requests or only internal staff entry?
• Is the estimate the source of truth, or is pricing maintained elsewhere?
• Which reports are relied on for cash flow, margin, purchasing and progress claims?
• What must work on a phone at the job site, and what can remain office-only?
• What migration/import is needed from the retiring US system and existing CoConstruct projects?