# BuildPass Method — full content

> The complete BuildPass Method handbook in one file, with the Labs articles after it. Each page's canonical URL is noted under its heading; see https://company.buildpass.ai/llms.txt for the index.

# Manifesto

Source: https://company.buildpass.ai/manifesto

> What we believe about construction and why we're building this.

## Foreword

At BuildPass, we've been on a clear mission since the start. We've recently distilled that mission into a single statement:

> Build the world's smartest operating system for construction.

It's a mission we can rally around – it's bold, ambitious, and energising. It gets us out of bed each day, ready to tackle the challenges ahead with vigour.

But when it comes to articulating our _why_, we've always struggled. There are simply so many reasons this mission matters. A single statement or "vision" tends to be too abstract and doesn't do our purpose justice. So this short document explains why an operating system for construction sites is so crucial. Call it our "manifesto," if you will.

---

## Manifesto

The construction industry is arguably one of the most important in the world. It develops and maintains the built environment that supports humanity and allows us to thrive. It houses families, enables workplaces, facilitates communities, supports travel, and propels human progress. Yet, this critical sector has many challenges: declining productivity, persistent safety issues, high suicide rates, and a sense that it's not driving us forward as effectively as it could. BuildPass is determined to help address these shortcomings.

When searching for the highest-leverage ways to help the construction industry, we need to identify the most significant problems. Through extensive conversations with customers we've learned that the administrative side of construction is its greatest weakness. Complex regulations, poor record-keeping, outdated administrative tools, and disjointed communication—all within a complex and changing environment—create the root cause of many industry-wide issues. The ripple effect leads to blown budgets, eroded consumer trust, reluctance to join the industry, ineffective financial infrastructure, and a great deal of stress for everyone involved.

The most impactful thing BuildPass can do is apply technology to simplify, systemise, and automate these administrative processes, allowing industry professionals to focus on the more creative, fulfilling aspects of their work and to collaborate on successful projects. By building the world's smartest operating system for construction sites, we can unite all of the people involved in a project into an intelligent, AI-powered ecosystem that resolves these administrative headaches.

No matter how advanced technology becomes, construction will always be about people. Construction professionals are the heartbeat of the industry, and we must put them first. Their experience of using technology should be intuitive, connected, efficient, and even delightful. Right now, there are too many disconnected apps, vendors selling dreams they don't deliver on, and outdated solutions that fail to meet modern expectations—no wonder there's a sense of frustration among those working in construction.

To truly improve lives, we must simplify available choices, build remarkable, connected experiences, involve every stakeholder (from management to field workers), and help our workforce get home safely and on time, without being burdened by inefficient processes. Focusing on people is the most important thing we can do.

We are living in a pivotal era for the construction industry. There's an urgent global need for more infrastructure and housing, an increasing shortage of qualified workers to complete this work, and a technological revolution driven by AI. Together, these factors create an unprecedented opportunity to reshape such a vital industry.

When we consider the importance of construction to humanity, the administrative burdens its people face, and the powerful trends now converging, it's clear why construction needs a smarter operating system to underwrite its future. BuildPass is dedicated to helping build this future, and we couldn't be more excited to be part of it.

---

# Values

Source: https://company.buildpass.ai/values

> The principles that guide every decision we make at BuildPass.

## Own Your Impact

Take ownership and initiative, drive outcomes with a sense of accountability and self-determination, act with the confidence that your efforts shape our company's future.

> _Accountability, proactivity, empowered, self-determination, innovation from anywhere, initiative_

### What does this mean

- We take pride in our work and we take responsibility for its delivery
- We don't wait to be told what to do — if we see an opportunity for improvement, we take action
- We feel empowered to make decisions in the best interest of the company, knowing our team will back our decisions
- If we say we will do something, we do it. If anything changes, we communicate early
- We seek work that will have the most impact on the company
- We act with agency and know our own efforts influence the trajectory of the company

### What doesn't this mean

- Working in a silo
- Not communicating decisions and progress with the team
- Making irreversible decisions without consulting others
- Comparing ourselves internally or boasting about our work

---

## Build With Ambition

Embrace ambitious challenges, adapt to change swiftly, and strive for continuous personal and professional growth, pushing the boundaries to achieve bold visions.

> _Growth-oriented, hungry, ambitious, bold visions, embracing challenges, adaptable, dealing with ambiguity, embracing change, wearing many hats_

### What does this mean

- We are inspired and motivated by our vision and mission
- We realise that personal growth requires stepping outside of our comfort zone
- We are motivated by ambitious goals, not afraid of them
- We are scrappy when we have to be, and perfectionists when we can be
- We adapt to new situations and accept change in our stride
- We thrive in a fast-paced environment
- We're not scared to try new things and are always willing to throw our hat in the ring
- We understand we'll never have all the answers and are willing to act on the information at hand

### What doesn't this mean

- Being reckless in the pursuit of growth
- Sacrificing other values or our morals in favour of relentless ambition
- Disregarding our own well-being
- Disregarding feedback or being unwilling to change course where required

---

## Co-create The Future

Engage with customers and innovate collaboratively, focussing on impactful and industry-leading solutions, always maintaining a customer-first mindset.

> _Customer-first approach, customer collaboration, industry-leading innovation, prioritising quality, mission-focussed_

### What does this mean

- We always put ourselves in our customer's shoes
- We build innovative products that drive the industry forwards
- We listen to problems, not feature requests
- We think outside the box and are willing to solve problems in unique ways
- We consult with customers when making product decisions

### What doesn't this mean

- Building everything that customers ask for
- Building features just because competitors have them
- Using innovative technology just because we can or because it's unique
- Innovating without purpose or delivering business impact

---

## Listen Loudly

Foster an environment of empathy and trust, where open and respectful feedback is encouraged, ensuring everyone feels heard and supported.

> _Empathy, trust, open feedback, respectful, understanding roles, supportive environment, emotionally safe_

### What does this mean

- We feel comfortable giving direct feedback to each other, knowing that it comes from a place of trust and respect
- We have the utmost respect for each other
- We appreciate and celebrate our differences
- We listen deeply to each other, always seeking to understand

### What doesn't this mean

- Delivering feedback brashly or in an insensitive way
- Only listening and not giving our own opinion
- Holding back on feedback for fear it might not be received well

---

## The Non-negotiables

Key principles at BuildPass that sit alongside our values. They are foundational to how we work and who we are.

### Personal Development

We consistently focus on personal development and the company will support us to do so. We strive to make marginal improvements every day, knowing these compound greatly over time.

### Team Work

We work collaboratively and leverage each other as much as possible. Team is everything. We communicate clearly and regularly, knowing this is critical to our success.

### Human-first

We are all humans, and we never forget that. We place each other's well-being first. This is not only the right thing to do, but it creates the best outcomes for the company. We develop real relationships with our colleagues and we care deeply for each other.

### Flexibility

We trust each other enough to have flexible working arrangements, knowing we'll always get the job done. We perform our best when our personal lives are in order, and flexibility at work is there to support this.

### Honesty & Transparency

We act with integrity and give our honest opinions. We act with as much transparency as commercially possible, both internally and externally.

---

# Mission

Source: https://company.buildpass.ai/mission

> What we're building and why it matters — our north star.

Build the world's smartest operating system for construction.

---

# Product Vision

Source: https://company.buildpass.ai/product

> What we build, how we build it, and why it matters.

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:

1. **What did they ask for?** State the surface request.
2. **Why do they need it?** Identify the underlying workflow or pain point.
3. **Is there a deeper cause?** Apply the five whys. Is the real problem one layer down?
4. **Score it.** Does the proposed solution align with product principles? Does it serve the broader ecosystem or just one user?
5. **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._

---

# The BuildPass Method

Source: https://company.buildpass.ai/method

> How we build, who we hire, and what we expect.

There is a type of person who sees a problem and builds something to fix it. Not analyses it, not escalates it, not schedules a meeting about it. Builds something.

In construction, these people are everywhere. They're the ones on site who work around a problem before it becomes a delay. They take pride in their craft. They don't need to be managed. They just build.

That mentality is the single most important quality we look for in every person at BuildPass, regardless of role.

---

## Builders

A builder in customer success redesigns their own onboarding workflow before anyone asks them to. A builder in marketing makes the landing page instead of requesting one. A builder in sales studies the product until they can demo it cold, then writes a playbook so the team can too.

The traits are consistent across every function:

Builders work best without permission. They use judgment, act, and communicate what they did. Builders default to automation. They look at repetitive work and feel compelled to eliminate it. Builders are endlessly curious. They tinker, explore, and learn by doing. Side projects aren't homework. They're how their brain works. Builders prototype before they present. A working proof of concept in three hours teaches more than a slide deck in three days. Builders ship weekly. Not quarterly, not when it's ready. Weekly.

The common thread is agency. Builders work best when given a problem and the freedom to solve it. They ship before they're ready, because a working v1 teaches more than a perfect plan ever could.

These traits are not exclusive to engineering. They show up in every discipline when a company optimises for them. We do.

---

## AI-native

There is a meaningful difference between a company that uses AI and a company built on it.

Using AI means a chatbot here, a copilot there. Incremental improvements to existing processes. Building on AI means redesigning the processes entirely. Asking: if we started this function from scratch today, knowing what AI can do, what would it look like? The answer is almost never "the same thing, but faster." It's usually something fundamentally different.

BuildPass is built on AI. Every function, every workflow, every role is designed with the assumption that AI is available, capable, and improving. This changes what's possible in ways that compound over time.

In product and engineering, it means agentic workflows, self-healing systems, and a development velocity that doesn't scale linearly with headcount. Our founders build product directly with AI. Our engineers ship at a pace that surprises people who learn the size of our team. Every new feature is evaluated for AI potential before it ships.

In customer success, every customer could have a dedicated AI assistant that knows their setup, their history, and their industry. A knowledge base that writes and updates itself as we ship. Our people shift from reactive support and admin to proactive, data-driven work. They spot problems before customers do, identify expansion opportunities from usage patterns, and spend their time on what actually requires a human: technical expertise, strategic guidance, and judgment that AI can't replicate.

In marketing, content generates, tests, and iterates without manual production. Feature pages create themselves when code ships. Videos re-record when the product changes. Strategy and creative direction are the human contribution. Production is infrastructure.

In sales, preparation is automatic. Follow-ups draft themselves. Product knowledge deepens to the point where every salesperson is a technical consultant. The human contribution is the relationship, the trust, the read of the room. AI tools analyse every interaction, providing insights and feedback to improve our human skillsets every day.

This isn't a future state. The tools exist today. The question is whether we use them with enough ambition.

Every person at BuildPass uses AI daily. Not occasionally. Daily. We chase 10x improvements, not 2x. Using AI as an assistant gets you 2x. Rebuilding around it as infrastructure gets you 10x. We're after the 10x.

[Read more about AI fluency per team](/method/rubric)

---

## Ownership

There is a version of ownership that looks like raising a problem and walking away. That's awareness, not ownership.

Ownership at BuildPass means arriving with the problem, a proposed solution, and a clear ask. It means driving things forward rather than waiting for someone else to notice. It means following through, not just flagging.

For anyone in a leadership role, this is especially important. If a project you're responsible for lacks direction, the expectation is that you create the direction. Get the right people in the room. Get agreement. Drive it forward. The worst outcome is a project drifting because nobody drove it.

---

## Speed

A good decision made today is almost always better than a perfect decision made in three weeks. You can iterate on something that exists. You can't iterate on a plan.

Ship the v1. Learn from it. Improve it. Ship again. The discipline isn't getting it right the first time. It's getting it out fast enough that you have time to get it right by the third or fourth.

Companies rarely fail from too much progress. They fail from moving too slowly or giving up.

---

## Flat

We don't add management layers. We hire people who don't need them.

Flat doesn't mean unsupported. It means the support exists for people who seek it out. We protect time for building, deep focus, and collaboration. Calendars aren't full of standing meetings. If you need a sounding board, a decision, or help getting unblocked, you reach out. Book the time. Ask for the session. The door is always open, but you have to walk through it.

The people who thrive here actively create their own support structures. They seek context. They ask for feedback. They pull people into conversations rather than waiting to be invited.

---

## The system of record

BuildPass is the operating system for construction. In an AI world, that means something very specific: we are the system of record and the tools for core operations.

Customers are going to build their own workflows on top of AI. They'll use agents to manage their projects, assistants to draft their communications, and custom tools to solve their specific problems. That's already happening. The question is where the data lives, where the single source of truth connects everything, and who provides the tools that keep the core of a construction business running day to day.

That's BuildPass. We provide the operational tools builders depend on, compliance, safety, worker management, project tracking, and we structure the data flowing through them intelligently. Data in, data out, with AI making it meaningful along the way. The system of record and the tools that run on top of it.

AI works directly on our core primitives: People, Companies, Projects, Records. It classifies, routes, drafts, and summarises. Users don't see "AI-powered" labels. They just notice that compliance requirements are pre-loaded for their state. That a safety alert fires before a certification expires. That a new hire's induction is ready before anyone creates it.

Import is as important as the product itself.

---

## Three streams

We build across three streams, each with a distinct purpose.

**Core** is the foundation. Compliance, safety, daily operations, worker management. This is where trust is built. If Core is unreliable, nothing else matters. The standard is quality, consistency, and scaling with extreme intent.

**Expansion** explores new territory. Finance, pre-construction, procurement. New capabilities that extend BuildPass into new parts of a builder's business. The focus is finding value quickly, testing hypotheses with real customers, and protecting Core while we learn. Not everything in Expansion will survive. That's by design.

**Field** is the on-site experience. A single companion app replacing the fragmented tools workers carry from site to site. This is the ecosystem layer, the network effect, the product-led growth engine. Workers carry it with them. Subcontractors discover it through their GCs. The flywheel turns.

Let builders build. That's the strategy.

---

## Hiring

The best builders are rarely found through job postings. They're found in communities, building things.

People who ship side projects, explore new tools, and spend their own time pushing what's possible have already demonstrated the quality that matters most: they build because they can't help it. Not because someone asked them to.

That's our hiring pipeline. We go where curious people gather. We look for demonstrated ability over claimed experience. We don't care about your degree or your last job title. We care about what you've made. Show us. Better yet, build something with us. That's the interview.

We bring in hungry, curious people and give them real problems. The ones who thrive earn a permanent place. This creates a healthy pressure that raises the standard for everyone.

Self-selection is the mechanism. We set a clear bar and make it visible. People rise to meet it or they recognise this isn't the right environment for them right now. We'd rather be honest about what we expect than discover a mismatch six months in. The expectations aren't hidden. They're written here.

---

## Why this matters

Construction is one of the most important industries in the world. It develops and maintains the built environment that supports humanity. It houses families, enables workplaces, facilitates communities, and propels human progress.

Yet this industry has been underserved by technology for decades. Complex regulations, poor record-keeping, outdated tools, and disjointed communication create the root cause of many of its biggest challenges: blown budgets, safety incidents, eroded trust, and a workforce that's stretched thin.

We are living in a pivotal moment. An urgent global need for more infrastructure and housing. A growing shortage of qualified workers. A technological revolution driven by AI that changes what a small, focused team can accomplish.

These forces are converging. The opportunity to reshape construction technology is unprecedented, and it won't last forever. BuildPass exists to seize it.

The BuildPass Method is how we make sure we're worthy of it. We hire builders, because the people building tools for construction should be builders themselves. We build on AI, because incremental improvement isn't enough. We move fast, because the industry can't wait. And we set a high bar, because the people who build our world deserve nothing less.

**Let builders build.**

---

# AI Fluency Rubric

Source: https://company.buildpass.ai/method/rubric

> How we measure AI proficiency across every function at BuildPass.

This rubric helps you figure out where you are today and what the next step looks like.

This is our first pass. It'll evolve as we learn. But we need a starting point so each functional lead can honestly assess their team and figure out where to focus.

We think about AI proficiency as a power curve with four levels:

## 0x Disengaged

Uses AI occasionally but nothing about your work has actually changed. Same process, same output, just with a chatbot open on the side. If you're here and not actively moving up, you're below the bar.

## 1x Competent

You're meaningfully better with AI than without it. You use it daily across your core work. You can show specific examples of how it's made you faster or your output higher quality. You've built repeatable prompts and workflows you actually rely on. This is the minimum for everyone within 90 days.

## 5x Operator

You've gone beyond your own desk. You're building workflows, automations, or tools that other people use. You think in systems, not one-off prompts. You can point to something you've built that's changed how your team works. This is where functional leads need to be.

## 10x Builder

You've re-engineered how the work gets done so it looks fundamentally different. Categories of work have been eliminated or run without humans. You're building the infrastructure that levels up your whole function. This is where we're heading.

## Assessment

We assess across four dimensions: whether you've got the right **mindset** (AI as infrastructure, not a toy), whether you've got a **strategy** (you can explain how AI changes your function), whether you're actually **building** (repeatable workflows, not one-off prompts), and whether you take **accountability** (you own the output, not just the input).

## What each level looks like per function

### Product

Engineering & Design

| Level | Description |
| --- | --- |
| 0x | Uses AI for snippets and debugging but hasn't changed how they design, build, test, or ship. Can't explain their tool choices or how their usage has evolved. |
| 1x | Uses AI regularly across implementation, debugging, testing, and docs. Shows real tool literacy and has a structured approach for generating specs and prototypes they reuse across projects. |
| 5x | AI fundamentally changes how they engineer. Defaults to AI-first where appropriate. Built workflows and tooling that improve output beyond just themselves. Strong judgment on tradeoffs and failure modes.<br>- Can point to new skill sets developed through AI: writing SQL, data analysis, building dashboards<br>- Rapidly generates working solutions users can try. Fidelity and speed both up |
| 10x | Re-engineers how software gets built so AI is part of the operating model. Code production, review, testing, and delivery meaningfully restructured. Building towards the self-healing, self-evolving product described above.<br>- AI triages incidents, runs test suites, resolves common issues autonomously<br>- Engineers steer with judgment and taste instead of grinding boilerplate |

### Customer Success

| Level | Description |
| --- | --- |
| 0x | Uses AI to draft follow-up emails or summarise calls but the core work is unchanged. Account plans, renewal prep, health tracking still done manually the same way. |
| 1x | Has repeatable prompts for account research, meeting prep, and renewal drafting. Feeds real context into AI before customer conversations. Uses AI to do things they wouldn't have had time for before: deeper account analysis, structured pre-reads, stronger prep. |
| 5x | Clear before/after story. Built account plan templates, health score frameworks, or engagement workflows that the whole team uses. AI surfaces risk signals and expansion opportunities before conversations, not after.<br>- Automated renewal prep and account review generation<br>- Building AI-driven account intelligence that flags churn risk and expansion triggers |
| 10x | The function is proactive by default. Categories of manual work eliminated. CSMs walk into every conversation with a complete picture generated automatically.<br>- Account health, risk, and expansion running as live systems, not quarterly exercises<br>- CSMs operating as strategic partners, not administrators of the relationship |

### Customer Support

| Level | Description |
| --- | --- |
| 0x | Asks AI one-off questions then goes back to handling tickets the same way. Uses it to draft Slack messages but hasn't applied it to real work. No evidence of impact. |
| 1x | Has repeatable prompts for core parts of their job. Feeds ticket context, product docs, and customer history into AI before responding. Uses AI to do things they wouldn't have had time for before: thorough investigation, structured summaries, second-pass quality checks. |
| 5x | Clear before/after story spanning months. Produces tools, templates, or processes others on the team use. Actively iterates on their AI workflows like a product.<br>- Has built or is building bespoke AI agents personalised per customer or account<br>- AI drafts first responses, classifies tickets, and surfaces knowledge articles before the rep opens the ticket |
| 10x | Changed what the team does, not just how fast. Categories of work either no longer exist or run without human involvement. Building towards the dedicated AI partner per customer described above.<br>- Knowledge base writes and updates itself as the product ships<br>- Support reps operate as proactive technical experts, not ticket coordinators |

### Sales

| Level | Description |
| --- | --- |
| 0x | Uses AI call summaries and drafts outreach emails. Can't describe how AI has changed win rate, deal velocity, or pipeline quality. Before and after looks the same. |
| 1x | Uses AI products daily across core workflows: research, HubSpot analysis, call prep. Built a personal prospecting workflow that saves significant time. Self-serves pipeline analysis without waiting on ops. |
| 5x | Chains multiple AI tools into repeatable workflows. AI research flows into account plans into personalised outreach. Shares what's working and has become a go-to resource.<br>- Uses AI to surface signals they wouldn't have found manually: expansion triggers from usage data, competitive displacement opportunities<br>- Every salesperson operating as a forward-deployed sales engineer |
| 10x | Redesigned core sales motions around AI-native logic. AI owns the operational layer: CRM updates, meeting notes, pipeline analysis, enrichment, prospecting. Reps focus on judgment and relationships.<br>- Preparation is automatic. Follow-ups draft themselves<br>- The salesperson is fully present, fully prepared, and fully human in every conversation |

### Marketing & Content

Growth & Content

| Level | Description |
| --- | --- |
| 0x | Uses AI for first drafts only. Output reads like unedited AI. No real workflow. Can't explain how AI has changed their process or output quality. |
| 1x | Uses AI regularly across content, SEO, and performance review. Volume and quality both up with specific examples. Built a reusable prompt library the team pulls from. |
| 5x | Running AI-driven experiments with measurable results. Built a content system that drafts, formats, and schedules across channels. Always-on agentic workflows running without human involvement.<br>- Content pipelines, monitoring, and campaign ops operating 24/7<br>- A/B testing at scale with AI-generated variants |
| 10x | Content connected directly to the codebase. A feature ships, a page appears. Video walkthroughs that re-record themselves when the product changes. The marketing team's highest contribution is strategy, positioning, and creative direction. AI handles the rest.<br>- Personalisation engine at scale tied to pipeline<br>- Automated entire job categories with measurable revenue impact |

### Exec Ops

Operations & Founders

| Level | Description |
| --- | --- |
| 0x | Uses AI to tighten emails or summarise meetings. Priority routing and judgment work unchanged. No repeatable workflow. |
| 1x | AI aggregates calendar, context, and prior threads into a weekly brief. Structured flow where AI does first pass on emails and comms. Can cite time saved with specific examples. |
| 5x | Connected calendar, CRM, email, Slack, and notes into one system that produces briefings, flags conflicts, and routes follow-ups. Others reuse what they've built. |
| 10x | Replaced recurring reporting with live dashboards and AI briefs. Freed capacity for strategic work. Redefined responsibilities. Stakeholders changed how they consume information. |

### People

People Experience

| Level | Description |
| --- | --- |
| 0x | Manually does work AI could meaningfully assist with: comp modelling, scenario planning, workforce analysis. Hasn't tested whether AI would improve it. Blocks team from experimenting. |
| 1x | Uses AI daily with repeatable prompt templates refined each cycle. Connected AI tools into recurring workflows. Sets direction for their team's AI experimentation. |
| 5x | Automated a core People process end-to-end with AI-native logic: agentic screening, AI-generated deliverables, quality checks. Replaced recurring manual work with live, AI-populated systems.<br>- Every person has their own AI agent managing calendars, surfacing priorities, drafting communications<br>- Office manager agent per region with full memory of how things operate |
| 10x | Rebuilt the function around AI-first delivery. Agents generate personalised outputs from role data, deliver just-in-time content, auto-assess completion. Redefined team roles. The operational overhead of running a company this size shrinks dramatically. |

---

# About

Source: https://company.buildpass.ai/about

> What BuildPass is, and what this site is for.

## About BuildPass

BuildPass is construction management software for builders, contractors, and project teams. The product covers site management, health and safety, quality assurance, asset management, and an AI toolkit, all in one connected place, so the people on site can focus on building. We're building the world's smartest operating system for construction.

We're an Australian and North American company, with teams in Richmond, Victoria and Austin, Texas. You can learn more about the product, pricing, and the team at [buildpass.ai](https://www.buildpass.ai) (or the [US homepage](https://www.buildpass.ai/us)), and see open roles on [our LinkedIn jobs page](https://www.linkedin.com/company/buildpass/jobs/).

## About this site

The BuildPass Method is our public handbook. It captures the thinking behind the company in five documents: the [Manifesto](/manifesto) (why we exist), our [Values](/values) (how we make decisions), our [Mission](/mission) (what we're building toward), our [Product Vision](/product) (what we build and why), and [The BuildPass Method](/method) itself (how we work, who we hire, and what we expect). The [AI Fluency Rubric](/method/rubric) lives there too.

We publish it openly because we think candidates, customers, and partners deserve to see how we actually operate before they work with us. Reading by machine? Start from [llms.txt](/llms.txt), or fetch the whole handbook in one file at [llms-full.txt](/llms-full.txt).

For questions about anything on this site, see the [Contact](/contact) page.

---

# Contact

Source: https://company.buildpass.ai/contact

> How to reach the BuildPass team.

## Get in touch

The fastest way to reach BuildPass is by email at [hello@buildpass.ai](mailto:hello@buildpass.ai). We read everything. Questions about the product, this handbook, partnerships, press, and careers all land in the right hands from there. Open roles are listed on [our LinkedIn jobs page](https://www.linkedin.com/company/buildpass/jobs/).

In Australia, you can call us on [1800 319 716](tel:+611800319716) or [+61 3 9917 4285](tel:+61399174285). In the United States, email is the fastest channel, or [book a demo](https://www.buildpass.ai/book-a-demo) and our US team will be in touch. For support and everything else, the contact options at [buildpass.ai](https://www.buildpass.ai/contact-us) are the most direct route to the team.

## Offices

**Australia:** 2/33 Stewart Street, Richmond, Victoria 3121, Australia

**United States:** 3212 E Cesar Chavez Street, Austin, Texas 78702, United States

## Elsewhere

- [LinkedIn](https://www.linkedin.com/company/buildpass)
- [X (Twitter)](https://x.com/buildpass_)
- [Instagram](https://www.instagram.com/buildpass_/)
- [YouTube](https://www.youtube.com/channel/UC8UkqUn6xvFIAWsIjUIIQ2g)

If you're writing about something you read on this site, like the [Manifesto](/manifesto), [Values](/values), or [The BuildPass Method](/method), mention the page so we can route your note to the person who wrote it.

---

# Privacy

Source: https://company.buildpass.ai/privacy

> How this site handles your data.

## What this site collects

The BuildPass Method (company.buildpass.ai) is a static, read-only content site. There are no accounts, no login, no forms, and no comment features. We never ask you for personal information here, and the site sets no advertising or tracking cookies.

We use [Vercel Web Analytics](https://vercel.com/docs/analytics/privacy-policy) to understand aggregate page traffic. It is a cookie-free analytics service: it records anonymised page views and approximate region, and it does not track individual visitors across sites or store personal identifiers. The site is hosted on [Vercel](https://vercel.com), whose infrastructure processes standard request logs (IP address, user agent) transiently to serve and secure the site.

## What we do with it

Aggregate analytics tell us which pages of the handbook people find useful. That's the whole story. We don't sell, share, or enrich any data from this site, and there's nothing here to link a visit to a person.

## The BuildPass product

The BuildPass product itself (at [buildpass.ai](https://www.buildpass.ai)) handles customer data and is governed by its own [Privacy Policy](https://www.buildpass.ai/privacy-policy) and [Terms of Service](https://www.buildpass.ai/terms-of-service). If you're a BuildPass customer, that policy is the one that applies to your account and project data.

## Questions

Anything about privacy, on this site or at BuildPass generally, goes to [hello@buildpass.ai](mailto:hello@buildpass.ai) and we'll get you an answer.

---

# Software factories should amplify human judgment, not replace it

Source: https://company.buildpass.ai/labs/factory/building-an-effective-software-factory

> How we built Foreman to help us learn faster, make better decisions and ship more.

[BuildPass](https://www.buildpass.ai) runs construction operations on site for more than 1,000 general contractors and over 500,000 workers and subcontractors across Australia and North America.

At the start of 2026, we began exploring two new areas: helping construction companies [manage their finances](https://www.buildpass.ai/features/finance), and helping them [price and win work](https://www.buildpass.ai/features/preconstruction). Building Win and Pay meant learning these domains while building software customers could use.

By the end of August, both new products were in customers' hands, with 100+ major releases across Win, Pay and their shared platform.

Writing code had stopped being the main constraint. Getting the right context quickly, noticing missing details and deciding which problems mattered were harder. More output was only useful if it helped us test our understanding and improve the product.

We built Foreman around those decisions. It gathers context, brings questions to the people who can answer them and carries their judgment into the work. Our engineers build and continually improve that system, as well as the products it helps deliver.

**Figure: Releases over time**

Monthly major releases for Build (including BuildPass Agent) and for Win and Pay with their shared platform. The animation follows the release history, then zooms out to compare the two series across completed months.

## Foreman

Foreman connects finding a problem, deciding what to do and learning from the result:

- **Intake:** collect customer and team feedback, support threads, adviser notes and production errors
- **Triage:** clarify the intent, gather the relevant context, ask for missing input, and decide whether and when the signal should become work
- **Build:** implement the change within the patterns of the codebase
- **Verify:** establish confidence in the change through tests, security and domain checks, an independent review and browser testing in the real product
- **Close the loop:** tell the reporter what changed and what it means for them, then use their feedback to inform the next decision

Each stage leaves state and context for the next. A human still makes every merge call. The factory brings forward the initial signal, intended outcome and current evidence, so a reviewer can understand the change without reconstructing the whole run or keeping every detail in their head.

**Figure: Signals moving through Foreman**

Customer feedback and automated findings enter triage, where Foreman clarifies intent and gathers context. Work that needs an answer returns to a human; accepted work moves through build and verification before a human merge decision and a reply to the reporter.

## One bottleneck at a time

We did not start with a plan for Foreman. It took shape as we worked through these bottlenecks, often in parallel. Each change taught us something about the product or how to build it. None is permanently solved; we keep adjusting the system as our understanding changes.

### Bottleneck 1. Writing code

Early in 2026, an agent could take a clear card to a working branch while we were in a meeting. Producing a scoped change was no longer the rate-limiting step.

“Build construction finance. Make no mistakes.” The dream one day, but today it skips a critical step: understanding the domain deeply enough to distinguish a correct answer from a plausible one.

We were learning these domains ourselves. Agents could help us explore an unfamiliar workflow or compare possible approaches, but we still needed to know which assumptions required an answer from a customer or construction adviser. Faster implementation made those decisions more important, not less.

### Bottleneck 2. Doing the right work

Cheap code creates new problems. You quickly learn that not every idea should become a change. The code can be clean, tested and wrong: the taste, judgment and context teams build up over time are not easy to replace.

Our first control was a triage skill, a checklist an agent ran before touching a card. Foreman's version of triage is quite detailed, pulling together application, company and industry context. It accepts work that clears the strict rubric. Most importantly, it holds work that does not and asks for human input before uncertainty hardens into code that further agent iterations treat as concrete truths.

**Figure: Through the triage rubric**

Signals pass through seven questions about duplicates, card type, vision, root cause, readiness, decisions and domain judgment. Duplicates and off-vision work close; unanswered questions wait for human input and return through triage. Accepted cards carry their intent, sources and confidence into the build queue.

Triage resolves four things before an agent builds:

- **Intent:** the outcome behind the request
- [Vision](https://company.buildpass.ai/product): whether the proposed direction advances the product
- **Context and input:** what is already known, and which evidence, expertise or human input is missing
- **Decision:** whether the work should enter the queue, and when

Foreman records its reasoning and confidence for each.

When Foreman cannot decide responsibly, it holds the card and sends a specific question to the reporter, product team or construction advisers. Instead of asking someone to review an entire problem, it can identify the missing answer that would change the decision. When someone answers, the card goes back through triage.

That helps us learn too. A question often points out details we had missed or narrows several plausible approaches to one we can defend. We can concentrate on shaping the parts we understand confidently, while making the remaining uncertainty explicit rather than carrying all of it in our heads.

Foreman reads a wiki assembled from customer calls, demos, adviser sessions and domain research, and records the sources used for each verdict. Relevant context can reach the next person without them having to retrace every conversation.

We also preserve selected human corrections as guidance and evaluation cases. These are deliberate engineering changes, not automatic learning from every interaction. As the product moves from greenfield modules to refinement and edge cases, the evaluation suite moves with it. Rubric changes must pass that set before they land.

### Bottleneck 3. Running enough work

Once more cards cleared the gate, our own human attention became the limit again. One person could only start, steer and review a few sessions at a time. Fast agents still spent too much time waiting for the next instruction.

We separated the work. Each card runs in its own worktree, with its context attached, inside a local Linux sandbox on our hardware. Multiple agents can work concurrently, and orchestration agents can pick up eligible cards, start workers and report what needs attention.

We use [Linear](https://linear.app) as the durable queue of what needs to be done. [GitHub](https://github.com) records the state of each change and detailed review evidence. We have used tools including [Conductor](https://www.conductor.build), [Superset](https://superset.sh) and [Orca](https://www.onorca.dev/) as control surfaces for the fleet.

The useful change for our engineers is being able to get into the right context quickly. Less time goes into reconstructing a session or remembering what happened on another card. More can go into understanding the problem, comparing approaches and improving the checks that let the next piece of work proceed safely.

**Figure: Orchestrating the work**

An orchestrator takes work from the queue and assigns it to available capacity across three sandboxes, each running up to sixteen sessions. Completed sessions send pull requests to review.

### Bottleneck 4. Trusting the code

Parallel output made human comprehension the next problem. With hundreds of pull requests arriving each month, we needed the details that could change a decision to remain visible.

Every push gets an independent review, adapted from Peter Steinberger's [autoreview skill](https://github.com/openclaw/agent-skills/blob/main/skills/autoreview/SKILL.md). A separate Codex or Claude session reads the change cold and reports material findings. Higher-risk changes also get an adversarial pass from a different model. We verify the findings rather than applying them blindly.

Tests and conventional static analysis still run. For deeper security work, we use Vercel's [`deepsec`](https://vercel.com/blog/introducing-deepsec-find-and-fix-vulnerabilities-in-your-code-base). Static matchers locate security-sensitive files, coding agents trace the relevant data flows, and a second pass revalidates the findings. We maintain separate scopes and threat prompts for finance, authentication, money paths, observability and the other parts of the system.

One of the more important steps was building our browser-verification harness. It starts the real application, signs in, exercises the changed workflow and checks both browser errors and data writes. Before-and-after screenshots or a short video show the change in use. That evidence makes the intended behaviour easier to understand. If it cannot be produced, the pull request stays unready.

Every pull request begins with the original signal: who encountered the problem, what they were doing and why it mattered. It states the change, then shows the evidence. Review results are tied to the current commit; a new push makes previous confidence and browser evidence stale.

The evidence may support a merge, a recut, a hold or closing a change that solves the wrong problem. Closing clean code is useful if the reason informs the next decision.

**Figure: Quick context on a change**

An illustrative retention change brings together tests, static analysis, security findings, independent review and browser evidence. Before-and-after screens, a recording, console checks and data writes support the merge decision. A new push invalidates that evidence until the checks run again.

### Bottleneck 5. Feeding the factory

By June, the factory could work through inbound feedback quickly, but much of that feedback arrived later than it needed to. Signals already existed in [Sentry](https://sentry.io), server logs, support threads and customer conversations. A person still had to notice them and assemble the context before they became work.

We began connecting those signals to the same intake systems. In-product reports can arrive with the current screen, recent navigation, a Sentry replay and scoped server-error context. A feedback sweeper triages the resulting Linear cards and routes accepted work to isolated workers.

The factory also looks for work. A daily regression scan produces a repair queue, while browser crawls test product flows against written intent. These checks help us notice UX issues, mismatched functionality and bugs without waiting for someone to encounter and report each one.

A finding still needs judgment. It may point to a defect, a misunderstanding of the workflow or a choice we need an adviser to explain. Finding it automatically gives us a question to investigate, not an instruction to produce more code.

Closing the loop means returning to the original signal. The reporter needs to know what changed and why. Their next response can confirm our understanding or expose another gap, giving the team and the factory something more useful to work from.

**Figure: Loops all the way down**

Product feedback returns to intake alongside daily regression scans, daily browser crawls, weekly sentiment scans and continuous Sentry errors. Foreman triages, builds and verifies the work, then ships changes back into the product to begin the next feedback loop.

## What we'd tell anyone building one

The models, harnesses and orchestration tools changed throughout this work. These principles helped us keep the system useful as the tools changed:

### Give each stage one outcome

When agents work across too many stages or processes at once, critical thinking and adversarial judgment can get lost.

We have found that agents work best with clear responsibilities, but they should treat instructions from other agents with a grain of salt. An agent trying to be helpful can pass on an overconfident assumption that the next agent treats as an instruction rather than checking. Review agents can then pull a change into an AI-slop spiral. Explicit instructions to push back and stay pragmatic help prevent over-engineering.

Each stage has its own instructions, context and evaluations. When something fails, we can improve that stage without rewriting the whole factory. Clear boundaries also let developers take over a step without interrupting the rest of the work.

### Keep the state declarative

Linear records what should be built: the original signal, gathered context, triage verdicts and unanswered questions. Anyone on the team can add missing context directly. If that changes the decision, the card goes back through triage.

GitHub records the active change. Labels and attached evidence show what has run, what passed and what needs attention. That state stays visible outside the agents' conversations, so a person can steer, stop or take over the work without reconstructing it first.

**Figure: Pull request state**

Five illustrative pull requests show how labels record checks, review, browser evidence and readiness to merge. The visible state lets a reviewer see what has passed and what still needs attention without reconstructing an agent session.

### Put engineering judgment into the system

Models, runtimes and orchestration tools are available to other teams too. Choosing them does not settle which customer problem to solve, how to model a construction workflow or what evidence is enough to trust a change.

Our engineers build the parts shaped by those decisions: the triage rubric, domain context, risk checks, verification and evaluations. When a failure reveals a missing check or a poor instruction, fixing the system lets that judgment influence later work as well as the change in front of us.

This is engineering work alongside building the product, not a replacement for it. It takes people who understand both well enough to decide what should be automated, what needs a question and what should remain a human call. The factory gives their expertise more reach.

### Let it work on itself, carefully

The factory can open cards against its own failures and propose changes to its tools. It could improve its own machinery indefinitely: code is an easy output to measure, and a self-healing harness will always find problems to fix, inserting slop where pragmatic judgment is needed.

Factory code also has a wider blast radius if left to be fully autonomous. A bad change to the rubric or review system can alter how every later piece of work is selected, built or judged. We treat the product values, risk boundaries and definition of acceptable evidence as invariants. This is where human judgment and taste matter most.

## Results

The pieces began operating together as a factory in May. From May through August, the release timeline records 97 major releases across Win, Pay and their shared platform, out of 118 through the end of August. They included estimates, takeoffs, procurement, progress claims, variations, retention, forecasting, month-end close and accounting connections.

More than 3,000 pull requests had merged into the shared codebase's main branch by the end of August. The share of merges linked to a card from a builder, the team or the factory itself rose from under 10% in May to nearly two thirds in July. These counts describe delivery and traceability, not a measure of product quality.

The feedback pipeline came online in June. From then through 2 September, more than 1,300 cards arrived from customers using the product, our team, industry advisers and the factory's own monitoring. More than 60% were resolved: 45% shipped, with the rest closed as duplicates or declines.

The small team could take on more work while continuing to learn the domains it was building for. The factory helped bring missing context and unanswered questions into view, rather than requiring the engineers to remember every detail across every change.

## Keep the learning loop open

As more work moves through Foreman, keeping the team's understanding current becomes harder. A passing check or a merged pull request does not tell us whether we understood the original problem correctly. We still need feedback from the people using what we build.

Our next improvements need to make that feedback easier to connect to earlier decisions: what we believed, what we changed and what we should do differently. Automating more of the workflow is useful when it gives the team room to work on those questions.

We want to finish a run with working software and a better understanding of the problem. The next run should start from there.