The problem
Australian construction operators sit on a documentation problem. Standards compliance, induction records, SWMS, project documentation, certifications, and team workflows live across PDFs, shared drives, email threads, and individual operator memory. The compliance burden is real (AS/NZS standards, WHS obligations, contract documentation requirements, builder licence conditions), and the cost of getting it wrong is not academic. Failed audits, contract penalties, insurance disputes, and in the worst case the loss of a builder's licence.
The off-the-shelf options don't fit. Generic project management software doesn't model construction-specific obligations. Enterprise construction platforms assume a tier-1 builder with tier-1 budgets. Document management systems store the files but don't model the compliance state on top of them. Operators end up paying for several tools, integrating none of them, and still running the compliance load through a spreadsheet on someone's laptop.
The Australian construction operator who hires Bedstone for a system like this is typically a mid-sized builder, a federated construction group, or a project management firm running across multiple sites. They have real revenue, real compliance obligations, and real workflow pain. They need a system that fits their operation, not a system that asks them to fit a tier-1 process.
The brief
The brief that produced the platform was concrete: build us a system that holds our standards, attaches them to the right projects, surfaces what's due, what's expiring, what's missing, and lets our team work through compliance items without leaving the platform. Multi-tenant from day one, because we are several entities under one roof. AU data residency. Audit-trail by default.
That brief is the shape of most useful internal-tools work. Not a moonshot, not a reinvention. A system that does specific, well-scoped operational work better than the current mess of spreadsheets and document folders.
What the platform does
The platform is the system of record for construction standards and compliance documentation, with workflow on top:
- Standards library. A versioned library of standards (AS/NZS references, builder-specific procedures, client-imposed standards) that can be assigned to projects, teams, or individual workflows.
- Project-attached compliance. Every project has the list of standards that apply to it, the documentation status of each, and the responsible operator. Status changes are timestamped and auditable.
- Document control. Versioned documents (SWMS, induction records, certifications, contract documents) attached to projects, with expiry tracking, revision history, and reviewer sign-off.
- Team workflows. Tasks, approvals, and reminders flowing through the same platform that holds the documentation. Operators don't need to leave the system to do the work the system is meant to track.
- Multi-entity tenancy. Federated construction groups can model multiple entities (companies, joint ventures, project-specific entities) under a single account with shared or partitioned data depending on the relationship.
- Audit trail. Every meaningful action timestamps and attributes. Compliance reviews and external audits can be answered from the platform rather than reconstructed from email.
This is not a slide-deck feature list. Every item above is in production today in v1 and is being rebuilt with cleaner foundations in v2.
The approach
This is a long-running engagement, not a single-sprint build. The approach matches that:
- Operator-first model design. Bedstone modelled the data around the way construction operators actually work, not around the way construction software thinks they should work. The result is a data model that maps cleanly to project paperwork, induction logs, and standards documentation as the operator already keeps them.
- Multi-tenant from day one. v1 began as a single-tenant deployment for one operator. The model was designed knowing additional tenants would land. v2 rebuilds the tenant boundary explicitly, with row-level partitioning and per-tenant configuration so federated construction groups can model their structure properly.
- Ship the smallest useful slice, then expand. The first usable version had the standards library, project attachment, and document control. Workflow, approvals, expiry tracking, and multi-entity tenancy landed in waves once the foundation was in production.
- Operate, not just deliver. Bedstone stays on the bridge. We run the production instance, monitor it, ship updates, and triage issues. The operator who hired us did not want to take ownership of running production software, and we built the engagement model around that.
- v2 rebuild on cleaner foundations. v1 carries the scars of its history. v2 is a clean rebuild on Australian-region infrastructure with a stricter data model, modern authentication, hardened transport security, and per-tenant data isolation hardened from the start. v2 is shipping through 2026 with a controlled cutover from v1 rather than a hard switch.
The stack
Built on the same foundations we run across client work, with construction-specific extensions. What matters commercially rather than what the parts are called:
- Hosted in Australia, on infrastructure the client controls. Data residency is a settled question rather than a caveat, and the account is theirs.
- Tenant isolation enforced below the application. One client’s data cannot be reached from another’s session, and that is guaranteed at the data layer rather than by careful coding in every screen.
- Documents versioned, encrypted and audited. Every upload keeps its history, and that history is part of the audit trail rather than a separate system.
- Single sign-on and email login out of the box. Per-tenant SSO available where a client’s IT requires it.
- A fast operator-facing interface. Built for people using it all day on site and in the office, not for a demo.
- Boring where boring is correct. We chose proven, operable components over interesting ones, because this platform has to run for years with a small team behind it.
We do not publish the component list. Under NDA we will take your technical people through the architecture in full.
What we deliberately did not build
The platform is opinionated about what it isn't, and the opinions matter:
- It is not an enterprise construction platform. The platform doesn't try to compete with the tier-1 enterprise platforms on their own features. The target operator does not need tier-1 features and would not pay tier-1 prices.
- It is not a generic project management tool. The workflow primitives are construction-shaped (standards, documents, approvals against compliance requirements) rather than generic (boards, tickets, sprints). Generic project management tools already exist and are excellent at being generic.
- It is not a document storage system pretending to be more. The compliance state is modelled as first-class data, not inferred from filenames. A document store with a clever folder structure is not this.
- It is not a builder-licence shortcut. The platform doesn't help an operator skip the compliance work. It helps them do the compliance work without losing track of it. That distinction matters legally and we are explicit about it with every customer.
How the engagement is structured
This is the model engagement for the way Bedstone prefers to work with mid-market AU operators:
- Fixed-fee build for the first usable version. Scope locked, price locked, milestone-paid. The operator knows what they get and what it costs before any code is written.
- Embedded operate-mode after launch. Bedstone runs the production instance under a monthly retainer that covers infrastructure operation, feature work, customer support escalation, and the security and compliance posture of the platform.
- v2 rebuild as a separate, scoped engagement. When the v1 architecture started to feel its scars, we scoped the rebuild as a fresh engagement with a clean budget and a controlled migration plan. We didn't sneak the rebuild in under operate-mode and we didn't try to retire v1 before the rebuild was ready.
- Customer-facing role. Bedstone is the engineering operator. The product owner is the operator who hired us. Customer relationships, commercial decisions, and the product roadmap sit with the product owner. We execute, we recommend, we don't replace the operator.
What the platform is delivering today
What we are comfortable publishing about the operational state, with the client's consent:
- v1 is live and operating in production with an active customer base of Australian construction operators.
- The platform serves federated construction groups (multiple entities under a single tenancy) and single-entity builders.
- The v2 rebuild is in development with cutover scheduled through 2026.
- Bedstone runs production, ships updates, and is the operational owner of the deployment. The product owner is the operator who commissioned the build.
- The audit trail covers every meaningful action in the platform and has been used in real compliance reviews.
We are deliberately not publishing specific revenue figures, customer counts, or efficiency-gain metrics. Where the client has not approved those specifics for publication, we leave them out rather than approximate them. If you're evaluating Bedstone on a real engagement, we can arrange a reference call with the product owner under appropriate confidentiality.
What this engagement says about how Bedstone works
This engagement is a useful reference because it shows the shape of how we operate, not just a single deliverable:
- We model the operator's actual work. The system reflects how construction operators already handle compliance and documentation, with software removing the friction rather than replacing the model. This is the same approach we bring to every client engagement.
- We stay on the bridge. The build is one phase. Operating the system is the longer phase. Bedstone is structured to do both rather than build-and-walk-away.
- We rebuild when the architecture stops carrying its weight. v1 to v2 is not a marketing exercise. It is the recognition that the foundations needed work and the engagement structure that lets us do that work properly.
- We are honest about scope. The platform is what it is and isn't what it isn't. We don't oversell. The operator who hires us for one shape of engagement is not pushed into a larger one to inflate the contract.
- We pick boring infrastructure that works. Proven, operable components chosen so a small team can run them for years, and we do not publish the list. Not because we can't pick something more interesting, but because boring infrastructure operated properly is faster, cheaper, and more reliable than novel infrastructure operated badly.
Want a reference call?
If you are evaluating Bedstone for a similar shape of engagement (multi-tenant SaaS for an Australian operator, compliance and documentation workflows, build-and-operate model), we can arrange a direct conversation with the product owner under appropriate confidentiality. Start a brief and we will scope the right reference for your situation.
Related reading
- Custom software development. How Bedstone scopes and builds engagements like this one
- AI for construction. Broader Bedstone work in the Australian construction sector
- Our approach. How we operate inside client engagements
- Pricing. Fixed-fee builds and embedded operate retainers
- What to bring to the first call
- All case studies