Australian Construction SaaS Case Study

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 (Asana, Monday, ClickUp) doesn't model construction-specific obligations. Enterprise construction platforms (Procore, Aconex) assume a tier-1 builder with tier-1 budgets. Document management systems (SharePoint, Dropbox) 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 AWS in ap-southeast-2 with a stricter data model, modern auth (Google OAuth and email-and-password as the primary paths), HSTS, 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

The platform runs on the stack Bedstone runs across most client work, with construction-specific extensions:

Compute and orchestration: EC2 in ap-southeast-2 (Sydney) with PM2 for process management. Boring, predictable, easy to operate.
Database: Amazon RDS PostgreSQL, multi-AZ for v2. Prisma as the ORM layer with hand-tuned SQL where Prisma's query shape doesn't fit. Per-tenant data partitioning enforced at the model level.
Storage: S3 for documents, with KMS-managed encryption at rest and versioning enabled on the document buckets. Every document upload is versioned and the version history is part of the audit trail.
Auth: v2 ships Google OAuth and email-and-password as the supported flows, with per-tenant SSO available as a paid extension. v1 user data is migrated into v2 on cutover.
Web: A modern React frontend (Next.js where SSR helps, static otherwise) with a clean component system and pixel-tested layouts. The interface is operator-facing and the operator is not technical, so it has to be fast, obvious, and forgiving.
Email and notifications: SES for transactional email, with templated reminders for expiry, approvals, and review cycles. SNS for internal alerting on operational events.
CI/CD: Bitbucket Pipelines with scoped IAM user access keys for deployment. Per the Bedstone delivery pattern: no app passwords, no shared credentials, deployment IAM scoped to the specific app and region.
Observability: CloudWatch for logs and metrics, with alerting on the operational signals that actually predict customer-impacting failure modes (queue depth, auth error rate, document upload failure rate, slow query rate). Not alerting on every CPU spike.
Backups and disaster recovery: Automated RDS snapshots, S3 versioning, off-region snapshot copy for the critical buckets. RPO and RTO targets documented and tested.

The stack choices follow Bedstone's general principle: pick the boring, well-operated option that AU-region inference and AU-region data residency support, run it competently, and resist the temptation to swap in something more interesting just because the swap looks good on a diagram.

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 Procore on tier-1 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. SharePoint 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.
v2 rebuild is in development on AWS 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. EC2, RDS, S3, SES, PM2, Prisma, Postgres, ap-southeast-2. 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.

Australian construction SaaS. Standards, operated as software.