Construction document management, free for Property Developers.

We built the hard part first

Where Visibuild started

When Visibuild was built, we did not start with document management. The industry was already reasonably well served by document management platforms. What was not well served was construction quality management, the execution layer, the inspection and test plans, the defect tracking, the commissioning workflows, the audit trail that proves work was done right.

That is where we started. And building quality management properly meant building the infrastructure that underpins it: rigorous permission controls, structured data models, revision logic, and audit trails. Not as features bolted on top, as the foundation the platform runs on.

Why document control followed naturally

Document control is a core part of that foundation. You cannot manage quality without knowing whether the team is working from the right drawing. The permission infrastructure that controls who sees what on a construction site is the same infrastructure that controls who can upload, distribute, and supersede documents in a register.

We built that infrastructure first because that is where the harder, less-solved problem was. Having built it, extending it to the pre-construction document problem is straightforward. Which is exactly why there is no point charging for it.

The pre-construction document problem is structural

How documents are managed today

Ask any property developer or external project manager how they manage documents before construction starts, and the answer will be some variation of the same story.

• DA drawings are in one place
• Consultant packages are in another
• Authority submissions are in someone’s inbox
• The structural engineer sent the latest revision last Tuesday and nobody is certain it reached the architect
• Each consultant uses whatever file-sharing platform suits them, some SharePoint, some Dropbox, some Google Drive, some WeTransfer links that expired a week ago

The fragmentation is not carelessness. It is a rational response to a cost problem. Implementing a proper document management system for a project that has not yet committed to a construction platform is difficult to justify. Enterprise document control platforms carry licensing costs and implementation overhead that make no sense in a pre-construction context. So most developers and project managers default to the cheapest available option: shared drives and email.

The downstream cost of fragmentation

The consequence is predictable. Documents go through numerous revisions, and at each revision, a slightly different set of people receives the update through a slightly different channel. By the time a project reaches tender, no single person has a complete and current picture of what exists. Someone has to go and collect it. Work out what is current. Consolidate what exists across half a dozen platforms. It takes weeks, and it is entirely avoidable.

For an external project management firm running this process across a dozen concurrent projects on behalf of different clients, the problem multiplies. Each client has a different consultant network. Each project is at a different stage. Each generates its own volume of revisions, its own fragmentation, its own consolidation task. Without a consistent, controlled environment, every project becomes a different workaround.

Why everyone waits, and why that makes it worse

The fragmentation described above is not simply a matter of bad habits. It is the predictable outcome of three compounding reasons to do nothing.

Reason 1: The handover assumption

In most developments, the appointed head contractor takes ownership of the document environment once construction begins. Design coordination becomes their responsibility, and it makes sense for it to run on a platform their team knows and uses. Developers know this. So committing to a document platform before a builder is appointed can feel premature, why set something up that the contractor will likely replace or run in parallel anyway?

Reason 2: The funding logic

Developers work hard to ensure that project costs sit inside the construction financing facility rather than as pre-construction soft costs. A document management subscription paid before the project is funded, or before the procurement outcome is known, is difficult to justify. It is a real cost with an uncertain return.

Reason 3: Timing uncertainty

If the construction start date is not confirmed, and in planning and design development, it rarely is. Spending money on project infrastructure feels like a bet on an outcome that has not yet been decided.

What waiting actually costs

The rational response to all three is to wait. Use shared drives and email. Keep the file links flying. Defer the decision until the builder is appointed and let them sort it out.

The problem is that by the time the builder arrives, they inherit months of accumulated document chaos. Revisions scattered across platforms. No single source of truth. Weeks of consolidation before construction can properly begin. And the developer, who in many cases actually wants to retain ownership of the document environment for data security reasons, has lost the window where establishing that ownership was easiest.

The free tier removes all three blockers simultaneously:

No cost means no soft cost justification. No lock-in means the handover assumption is irrelevant, if the builder wants to run their own environment, documents export cleanly. And no time pressure means starting before the construction date is certain carries no financial risk.

The problem is not revision control, it is permission infrastructure

What most platforms charge for

Here is something that often gets overlooked in conversations about document management: revision control itself is not technically difficult. Tracking that a drawing is at Rev D and superseding Rev C is a straightforward problem.

What is genuinely hard, and what most platforms charge significant money to provide, is the permission infrastructure underneath it:

• Who can upload documents.
• Who can view them.
• Who can share them externally and under what conditions.
• What state a document needs to be in before it can be distributed to a tenderer.
• Who gets notified when a revision is issued.
• What happens when someone tries to access a version that has been superseded.

What Visibuild already built

That is the infrastructure Visibuild already built, for a harder problem than document management. Extending it to a pre-construction document register is not a new engineering challenge. It is the same system, applied earlier in the project lifecycle.

Which means what we are offering is not a simplified or cut-down version of document management. It is the same permission-controlled, revision-tracked environment that runs quality management on complex construction projects, available from the first day a project has a name.

What documents with Visibuild actually does

Visibuild Documents is not trying to be the most powerful document management system on the market. There are platforms with hundreds of functions that do that well. What most developers and project managers need pre-construction is considerably simpler:

• A single place where consultants can upload their documents into a controlled environment
• Revision control that automatically supersedes earlier versions
• A document register that can be populated and used to manage basic document control
• Permission-controlled sharing so a tender package goes to every tenderer at the same revision, at the same time, with a clear record of who received what
• Milestones or gateways that define what documentation needs to be in place before a project moves to the next stage

That is what Visibuild Documents provides. Nothing more complicated than the problem requires.

Who benefits most

For a property developer running a single project, that is a clean, controlled environment replacing scattered shared drives. For an external project management firm running document processes across multiple concurrent projects on behalf of different clients, it is a repeatable, consistent system that replaces a different ad hoc process for every engagement.

The tender use case

The tender use case is where it becomes most tangible. Sending a drawing package to four builders and knowing that every one of them received the same revision, at the same time, with a complete distribution record, that is not a complicated thing to need. It is just not something email and shared drives can reliably deliver.

What this means when construction starts

When a head contractor comes on board, they inherit the document register already in place.

1. The consultant packages are there, revision-tracked and organised.
2. The tender drawings are there with a full distribution record.
3. The planning submissions are there.
4. Everything the builder needs to orient themselves to the project is already in the platform they will use to run the job.

That handover matters. A builder who walks into a clean, current document register has a real head start over one who spends their first weeks consolidating files from five different shared drives. And because many of the builders and subcontractors who work on these projects are already Visibuild users, the platform is not foreign to the project. It is already familiar.

Getting information out is also worth saying directly. One of the principles Visibuild is built around is that data should be easy to export in a structured format, because the platform does the organising, getting a clean export is straightforward. If a project proceeds and the developer or their builder chooses a different platform after construction commences, the documents are theirs to take. There is no lock-in.