BuildPass is the operating system for builders.
We help construction businesses run their operations, from compliance and safety to scheduling and finance, in one place so they can focus on building.
This document defines what we build, how we build it, and why.
It exists so the team can make product decisions without asking permission, and so AI tooling can generate code that actually fits our product.
Who We Build For
Our users are not software people. They are builders, project managers, safety officers, and office admins.
They work across two worlds:
- On site - phone in one hand, hard hat on, patchy signal, no patience for complexity
- In the office - managing compliance, chasing paperwork, coordinating across projects
Some are tech-comfortable. Many are not. The common thread: they are busy, they are practical, and they do not want to learn software. They want software that already knows what to do.
Every decision should pass one test: would this make sense to a site foreman using their phone between tasks?
The Wider Ecosystem
BuildPass does not exist in a vacuum. Construction is a network of relationships. A general contractor's success depends on their subcontractors. A subcontractor's compliance depends on the GC's platform. An architect reviewing an RFI needs a clean, professional portal they can trust.
We build for the primary customer (the builder or GC), but we always consider the people they pull into the platform:
- Subcontractors - invited into projects with scoped permissions. They see their team, their tasks, their compliance requirements. They do not need to learn the full platform.
- Consultants and architects - interact through guest portals for RFIs, submittals, and document review. The experience must be clean enough that a builder is proud to send their architect there.
- Workers - check in, complete inductions, upload certifications. Their interface is the simplest of all. Minimal inputs, maximum clarity.
The success of the GC is the success of the subcontractor. Every feature that touches the ecosystem should reinforce that relationship, not create friction.
Product Principles
1. Simple by default, powerful when needed
BuildPass should work out of the box with sensible defaults. No blank slates. No "configure your workspace before you can do anything."
New accounts should land in a useful state immediately. Configuration exists for teams that need it, but it is never the starting point.
Shipped right: A new builder signs up and their compliance dashboard is already structured for their state's requirements.
Shipped wrong: A new builder signs up and sees an empty screen with a "Create your first template" button.
2. Explain, don't assume
Construction is high-stakes. A missed inspection or an expired licence has real consequences: fines, shutdowns, injuries.
We err on the side of safety in how we communicate actions. When something changes, we tell the user what happened and why. When an action has consequences, we explain them before the user commits.
Trust is built through transparency, not by hiding complexity.
Shipped right: "This worker's White Card expires in 14 days. If it lapses, they cannot enter any active site. Renew now?"
Shipped wrong: A red dot appears on a worker's profile with no explanation.
3. Consistency over cleverness
Common flows should feel identical across the product. If you know how to add a worker in one place, you know how to add one everywhere.
This applies to:
- Navigation - same patterns, same placement, same hierarchy
- Data entry - same form conventions, same validation behaviour
- Import/export - same file formats, same column expectations, same error handling
- Language - same terms for the same concepts (pick one word and stick with it)
We do not invent new UI patterns when existing ones work. Boring consistency beats exciting inconsistency.
4. Adaptive without the blank slate problem
BuildPass serves builders of different sizes, trades, and regions. The product must adapt to these differences.
But adaptability does not mean "build your own experience from scratch." We ship opinionated defaults for each context (trade, region, company size) and let users adjust from there.
Configuration is a dial, not an empty text field.
Shipped right: A Victorian builder sees VBA-relevant compliance requirements pre-loaded. They can adjust, add, or remove.
Shipped wrong: A new builder sees a blank compliance section with "Add your first requirement."
5. Never clutter the interface
Construction businesses generate enormous volumes of data: workers, sites, inspections, documents, certifications.
Our job is to surface what matters and hide what does not. Every screen should have a clear purpose and a clear action. If a user has to scan the whole page to figure out what to do, we have failed.
Progressive disclosure over information dumping. Show the summary. Let them drill in.
6. Mobile is not a smaller desktop
Site users live on their phones. Mobile is not a responsive afterthought. It is often the primary experience.
Mobile flows should be designed for:
- One-handed use
- Poor connectivity (offline-capable where critical)
- Interruption (save state, resume easily)
- Glare and outdoor conditions (contrast, touch targets)
If a flow does not work on a phone on a building site, it does not ship.
7. Data flows in and out cleanly
Builders run on spreadsheets, PDFs, and email. We meet them where they are.
Import and export should be:
- Consistent - same format expectations across the product
- Forgiving - handle messy real-world data gracefully (column order, extra whitespace, mixed date formats)
- Transparent - show what was imported, what was skipped, and why
We never trap data inside BuildPass. If a builder wants their data out, it comes out clean.
8. Solve the root cause, not the surface request
When a user asks for a feature, our first job is to understand the problem behind the request.
Someone asks for a photo upload on a form. A weak response adds a file picker and saves an image. The right response asks whether a photo is even the feature. Maybe the real problem is that the form does not capture enough context to be useful. Maybe the real feature is helping someone complete a submission that actually passes review.
Apply the five whys. Unpack the root cause. Then build the thing that actually solves it.
This applies to feature requests, bug reports, and customer feedback equally. The answer is rarely "just add the thing they asked for." The answer is usually one layer deeper.
Shipped right: A customer asks for duplicate detection on worker records. We investigate and find the real issue is that the import flow does not match on existing records. We fix the import matcher.
Shipped wrong: We add a "find duplicates" button that scans the whole database and surfaces a list the user has to manually resolve.
Strategy
Let Builders Build
Our strategy headline: let builders build.
BuildPass replaces the fragmented mess of spreadsheets, email chains, paper forms, and disconnected tools that construction businesses use to manage operations.
We are not a point solution. We are building the whole product. An AI-native construction OS that spans compliance, safety, scheduling, finance, and field operations.
Three Streams
We build across three streams. Each has a distinct purpose, a distinct operating style, and a distinct measure of success.
Core protects and grows what we already do well. This is the foundation: compliance, safety, daily operations, worker management, site administration. Core is where trust is built. If Core is unreliable, nothing else matters. The focus is quality, methodical thinking, and scaling with extreme intent. Core defines the platform's shared building blocks, integrates AI into everyday workflows, measures and promotes engagement, and supports the customer success team to be efficient.
Expansion explores what we could do well. New capabilities that grow the surface area of what BuildPass handles. This includes products like Ledger (finance, pre-construction, procurement) and any future modules that extend the platform into new parts of a builder's business. Expansion is experimental and fast. The focus is finding new value quickly, turning hypotheses into evidence, protecting the core while we learn, and de-risking the roadmap. Not everything in Expansion will survive. That is the point.
Field is the on-site experience for anyone on a construction site. Products like SupaSite live here. A single companion app that replaces the fragmented set of tools workers currently juggle. Field unlocks network effects as workers carry it from site to site, project to project, company to company. It serves GCs, subcontractors, and solo operators. It is the ecosystem connectivity layer, the data sharing surface, and the product-led growth entry point. Field is where the highest ambiguity lives, but also the highest potential for viral adoption.
The Subcontractor Growth Flywheel
In the data model, a subcontractor is really just a company-to-company relationship with scoped permissions. This is not a separate product. It is a mode of the existing platform.
The flywheel: GCs onboard and invite their subs into projects. Subs get value from managing their compliance, workers, and tasks in one portal. Subs see the platform, start using it for their own projects, and invite their own subs. The cycle repeats.
We are not trying to build a full sub vertical (rostering, job management, service dispatch). We give subs the site operations layer that connects them to the GC. Guest portals for RFIs and submittals are a key entry point. When an architect or consultant receives an RFI through BuildPass, the experience must be clean, professional, and frictionless.
Integration Philosophy
BuildPass is not a walled garden. Construction businesses use dozens of tools, and we cannot replace all of them overnight.
- Be the best platform to integrate with. Clean APIs, well-documented webhooks, OAuth 2.0 partner authentication.
- Meet builders where they are. If a builder's accountant uses Xero, we sync with Xero. We do not force the builder to change their ecosystem.
- Own the core workflow, integrate at the edges. Compliance, safety, and field operations are ours. Accounting, payroll, and specialised trade tools are partners.
We never build an integration just to tick a box. Every integration should either reduce a builder's admin burden or unlock data that makes BuildPass smarter.
AI as Infrastructure
AI is not a feature. It is how we build. We use AI to:
- Ship faster than our team size suggests
- Automate repetitive compliance and admin work for our users
- Surface insights that would be invisible in spreadsheets
- Reduce the expertise required to use the product correctly
- Convert unstructured field data (voice, photos, notes) into structured artifacts
But AI should be invisible to the user. They should not see "AI-powered" labels. They should just notice that BuildPass seems to know what they need before they ask.
AI works directly on our core primitives. People, Companies, Projects, Records. It classifies, routes, drafts, and summarises. Every new feature should be evaluated for AI potential. The customer value: faster onboarding, fewer manual steps, smarter workflows.
What We Ship vs What We Don't
Apply these principles as a filter:
Ship it if:
- It makes a common workflow faster or safer
- It reduces a builder's admin burden
- It works on mobile and desktop
- It has sensible defaults
- A non-technical user can figure it out in under 30 seconds
- It strengthens the GC-to-sub relationship or the ecosystem flywheel
Don't ship it if:
- It requires configuration before it is useful
- It only serves power users
- It adds visual clutter without clear value
- It duplicates an existing flow with a slight variation
- It cannot be explained in one sentence
- It addresses the surface request without investigating the root cause
Measuring Success
We measure product quality through:
- Activation - Do new users reach value quickly?
- Breadth - Are builders using multiple modules, or just one?
- Retention - Are they staying? Is churn preventable or structural?
- Trust - Are builders relying on BuildPass as their system of record?
- Ecosystem - Are subcontractors converting from invited users to paying customers? Is the flywheel turning?
For Builders and AI Agents
This document is designed to be consumed by both humans and AI coding tools.
When Building Features
When generating code, building features, or reviewing PRs, use these principles to evaluate decisions:
- Default to the simplest implementation that satisfies the principle
- When in doubt, ship the version with fewer options and clearer defaults
- Every user-facing string should be written for someone who does not use software professionally
- Error messages should explain what went wrong AND what to do about it
- If a feature needs a tutorial to use, simplify the feature
When Evaluating Requests
When reviewing feedback or feature requests, do not just build what was asked for. Apply this process:
- What did they ask for? State the surface request.
- Why do they need it? Identify the underlying workflow or pain point.
- Is there a deeper cause? Apply the five whys. Is the real problem one layer down?
- Score it. Does the proposed solution align with product principles? Does it serve the broader ecosystem or just one user?
- Ship or park. High-scoring requests get built. Low-scoring requests get parked or declined with a clear reason.
This is a living document. As BuildPass evolves, so should this vision. But the core commitment does not change: build for builders, keep it simple, earn their trust.