Skip to content

Product opportunity and scope

At a glance

The recommended product is a focused, builder-owned workflow.

It should cover the parts of CoConstruct that local companies actually use.

The first release should connect estimating, proposals, budgets, selections, change orders, scheduling and client communication. Purchasing, accounting, payments and advanced reporting should be validated before becoming commitments.

Scope at a glance

flowchart LR
  first["First release"] --> validate["Validate with anchor builders"]
  validate --> later["Later phases"]
  first --> commercial["Estimate · proposal · budget"]
  first --> delivery["Selections · changes · schedule"]
  first --> client["Messages · files · client portal"]
  later --> finance["Purchasing · bills · invoices · payments"]
  later --> extensions["Accounting · CRM · AI · advanced reporting"]

Opportunity framing

Stakeholder context

The current project context says that a US system is expected to be replaced soon and that several local building companies want to develop a system that mirrors CoConstruct. They do not use all CoConstruct features.

This is currently stakeholder context, not independently verified product or market data. It should guide discovery, not become an architectural commitment.

The project should initially be framed as:

A focused, builder-owned construction workflow for the parts of CoConstruct that local companies actually use.

That framing leaves room to discover whether the result should be:

  • One shared product used by several builders.
  • A configurable product with company-specific templates and rules.
  • A private system for one anchor customer.
  • A reusable internal platform that may later become a commercial SaaS product.

Proposed first release

Core product spine

  1. Company setup, users, roles and permissions.
  2. Clients, trade partners, vendors and projects.
  3. Cost codes and reusable estimate templates.
  4. Estimate with line items, markup/margin, tax and scope.
  5. Client-facing proposal and approval.
  6. Original budget and basic job-cost visibility.
  7. Selections and allowances with deadlines and client decisions.
  8. Change orders with approval history and price impact.
  9. Schedule, tasks and daily logs.
  10. Client portal for messages, files, photos, selections and approvals.
  11. Searchable audit trail and exportable project data.

Candidate later phases

  • Purchase orders and vendor bid management.
  • Bills, invoices and online payments.
  • Accounting integrations.
  • Warranty and punch-list workflows.
  • Plans, annotations and submittals.
  • Takeoff.
  • CRM and email marketing.
  • AI-generated client updates.
  • Advanced WIP, forecasting and portfolio reporting.

The sequencing should be changed if the anchor builders identify accounting, purchasing or warranties as daily-critical workflows.

Likely differentiation

These are hypotheses to validate, not settled strategy:

Simpler than Buildertrend

Focus on a small number of deeply connected workflows. Do not expose a large menu of features that the target builders will not use.

More transparent than incumbent platforms

Offer clear pricing, clear ownership and a clear feature boundary. Buildertrend’s current public pricing is custom-quoted and revenue-qualified, which creates room for a more direct commercial model.

Better migration and portability

Treat import, export, historical access and customer ownership of data as first-class features. CoConstruct’s public API notice suggests that integration continuity may be a real concern for existing users.

Local fit

If the target companies are New Zealand-based, validate requirements around Xero, GST, local terminology, date formats, bank payments, privacy obligations and mobile connectivity. This is an assumption based on project context and must be confirmed with the builders.

Client experience as a wedge

Many builders may not need an entire operating system first. A strong client portal linked to selections, approvals, change orders, photos, progress and payments could provide visible value quickly, while the internal financial model grows behind it.

Scope risks

  • “Mirrors CoConstruct” may hide different workflows between companies.
  • Financial correctness is more difficult than the visible UI suggests.
  • Client and trade permissions can become complex quickly.
  • Data migration may require custom mapping and historical preservation.
  • A shared system can become an unbounded list of bespoke requests.
  • Accounting integrations can dominate the project if chosen too early.
  • A field workflow that is slow or unreliable will produce stale office and client data.

The first scope should therefore be defined by a small number of complete, tested workflows rather than by a feature checklist.