Skip to content
HMRC CIS return month ending 5 Aug · due Wed 19 Aug 12 days
CIS return due Wed 19 Aug 12 daysCDM 2015, RIDDOR and the compliance registers, built in rather than bolted onUnlimited users, every module, £0 per helmet30+ modules, one login, and the 15-app stack retiredQuickBooks, OneDrive, WhatsApp and email, wired into the jobGlove-friendly field app, QR-first, timed by the server not the phoneExpired subcontractor insurance drops a firm out of approved status overnightFree migration from whatever you run todayUK built, UK support desk, UK hours30-day free trial, no card, no obligation
Start the 30-day trial
Book a demo→
Implementation

You are not starting
from a blank page.

Most business software projects begin by asking you to describe everything you need. Unibuild begins by showing you a system that already runs a contracting business, and then working out what is different about yours. Reacting to something real is a task busy people can do well. Writing a specification from nothing is not.

Start with a demonstration → See the pricing
go live in stages migration included training in a sandbox development is part of it
Why these projects fail

You have probably been
through one of these before.

The pattern is remarkably consistent, and none of the steps in it are anybody's fault individually.

Month one
You are asked to specify, in advance and in writing, exactly what you need.
Nobody has time
The answers
People describe the process they think they follow rather than the one they actually follow.
Wrong from the start
Months two to seven
A long silence. Nothing to look at, nothing to react to, nothing to correct.
Six months gone
Delivery
The system matches the specification rather than the business, so people work around it.
Shelfware
Data
History is left behind, so the business runs two systems and trusts neither of them.
Double entry
The quiet part
The administrator who built the spreadsheets was never consulted, and keeps running them.
Nothing changed
The root cause Asking a busy business to imagine software that does not exist Rather than react to one that does
What we do instead

Six things that make this
a different kind of project.

Start from
working software

01

The platform exists and is in daily use. From the first conversation you are reacting to something real rather than trying to specify it in advance.

  • Configured and demonstrated in short cycles
  • With your own data in front of you
  • Risk retired before you commit
  • The uncertainty is confined to the tailoring
The specification problem disappearsMethod

Go live
in stages

02

The modules that cause the most pain go first. You get the benefit of the first while the second is still being configured.

  • Nothing depends on one large switchover date
  • Value arrives before the project finishes
  • Adding a module later is routine, not a project
  • 879 orders in five months proves that in practice
Phased is the normal routeMethod

Built around
your paperwork

03

Your certificates, reports and orders are reproduced with your branding and your layouts, so your own clients see documents they recognise.

  • Your logo, colours, typefaces and accreditation marks
  • Your terms and conditions, your clause wording
  • Your document numbering, continued from where you are
  • A design step, not a logo upload box
It becomes your systemMethod

Your data,
brought across properly

04

Reference data comes with you. We will also tell you plainly what is not worth migrating, which most suppliers will not.

  • Clients, sites, projects, staff and training records
  • Asset registers, suppliers, subcontractors with expiry dates
  • Price lists, rate cards and open orders
  • Historic transactional detail usually archived, not migrated
Included in the engagementMethod

Training in
the flow of work

05

Office and site staff learn differently and are trained separately, on your configured system rather than a demonstration one.

  • Role by role, in the screens they will actually use
  • In a sandbox that mirrors your live database
  • Nothing they do while learning reaches a real record
  • Refreshed from live in one action when it fills up
Practise without fearMethod

The relationship
continues

06

Your business will change. The platform changes with it, because development is what we do rather than something that stops at go live.

  • The breadth exists because a real business kept asking
  • New modules land in running businesses routinely
  • Your gaps become the next piece of scope
  • Not a change request queue behind other clients
Why the platform is this broadMethod
The shape of it

Six stages, and we will not
put a week number on them
before we have met you.

Any timescale quoted before a scoping conversation would be invented, and we would rather set a date we can meet than one that sounds good in a proposal.

  1. 01

    Demonstration

    Your worst problem firstOn a live systemNo obligation
  2. 02

    Scoping

    What is differentNot what you requireGaps priced openly
  3. 03

    Configure

    Your rolesYour documentsYour approval routes
  4. 04

    Migrate

    Reference dataRegisters and expiry datesAgreed cut off
  5. 05

    Train

    In your sandboxRole by roleOffice and site apart
  6. 06

    Go live, in phases

    Worst pain firstThen the nextThen the rest
Who you need A decision maker, whoever runs operations, and the administrator with the spreadsheets That last person knows things nobody wrote down
The part nobody asks about

Your staff learn in a full
copy of your own system.

This matters far more than it sounds, and it is the difference between a system people use fully and one they use timidly.

What the sandbox is
A copy of your live database that training runs against. The same screens, the same permissions, the same realistic data. Nothing anyone does while learning reaches a real order, a real client, a real supplier or a real account. When it has filled up with training entries, it is refreshed from live in one action.
Why it changes adoption
The usual reason staff avoid part of a new system is that the only place to practise is the live one. So a new administrator learns purchase order approval on real orders, timidly, and a supervisor never opens the valuation screen at all. Adoption stalls at the modules people feel safe in, and nobody can say why.
What else it is used for
Trying a process change before adopting it. Checking a release before it reaches your live records. Showing a prospective client of your own a system full of realistic data rather than an empty one.
One caution we will state
Refreshing a sandbox from live copies real personal data, including pay rates and absence reasons, into an environment that may have wider access. Whether your sandbox should be anonymised on refresh is a decision worth taking deliberately at implementation rather than by default, and we will raise it with you rather than wait to be asked.
Two people reviewing plans at a desk
879Orders in a module's first five months
34Configurable role definitions
88Portal pages, granted per person

The purchase order module went live in a running business in February 2026. Phased adoption is not a theory.

Migration, honestly

What comes with you,
and what should not.

A migration that faithfully imports years of inconsistency is worth less than a clean start with accurate reference data, and we would rather say so than charge you to move data nobody will open again.

Migrates well

Clients, sites and contactsProjects and open commercial valuesStaff records and rolesTraining and competence recordsAsset registers with serial numbersSuppliers and subcontractorsCertificates and insurances with expiry datesPrice lists and rate cardsOpen orders and retention balances

Usually better archived

Years of individual timesheet linesClosed job transactional detailHistoric invoices from your accounts packageOld certificates as scanned PDFsUnnamed photographs from a shared drive

Does not migrate

Handwritten site diariesAnything that only exists on paper without structureEmail history from your old systemNotifications and alerts, which are events rather than data
The one thing we will push back on

Bulk migration of a decade of unnamed images, or of every renewal certificate since 2014, is almost always more effort than it is worth. What we would migrate is the current certificate for each person and each qualification, and archive the superseded ones. The system keeps the most recent date per person per qualification automatically, so loading a renewal later does not require deleting the old one. If you genuinely need a historic archive inside the platform, say so at scoping and we will price it rather than guess.

What we will not do

Four promises we are
not going to make.

These are the four places implementations get oversold, so here is our position on each before you ask.

01
We will not quote a go live date today
It depends on how many modules you start with and how much tailoring you need. Any number quoted before a scoping conversation would be invented, and a date that sounds good in a proposal and slips by two months costs more credibility than the honest answer ever would. What we can say is that the core already exists, so the work is configuration, tailoring and migration rather than construction.
02
We will not present a Gantt chart
A week by week plan produced before anybody has seen your process is false precision, and both parties know it. You get a sequence, agreed after discovery, with the modules that hurt most first.
03
We will not promise self-service rebranding
Your branding, your document artwork, your notification recipients and your integration addresses are applied during implementation rather than from a settings screen you drive yourself. That is honest and it is consistent with a tailored engagement, and it is not the same thing as a rebranding panel. We would rather you knew which it was.
04
We will not claim adoption happens by itself
It needs supervisors to expect it for the first fortnight and the paper route closed rather than left running alongside. We help you plan that, and the platform helps by showing the office who has actually submitted and whose phone has granted notification permission. But no software substitutes for a manager insisting on it in week one.

Everything else on this page is how the two live deployments were actually built. These four are where other suppliers make it sound easier than it is.

Questions

Asked by people who are
already interested and are
looking for a reason to hesitate.

How long does implementation take?+
It depends on how many modules you start with and how much tailoring you need, so any number quoted before a scoping conversation would be invented. What we can say is that the core platform is already built, so the work is configuration, tailoring and migration rather than construction. We agree a realistic programme with you after discovery, and we would rather set a date we can meet than one that sounds good in a proposal.
Do we have to move everything across at once?+
No, and we would advise against it. Phased adoption is the normal route and we start with whatever is costing you the most time or money. The evidence that this works is that the purchase order module was introduced into a live deployment in February 2026 and carried 879 orders within five months. Adding a module to a running business is routine rather than disruptive, and one of the two systems has had modules added steadily for ten years without a rebuild.
Who needs to be involved from our side?+
Less time than you fear, but from the right people. A decision maker, whoever runs operations, and critically the administrator who currently holds the business together with spreadsheets. That last person knows things nobody has ever written down, and they are usually the single most valuable person in the project. Any content about implementation that treats them as an obstacle has misunderstood who they are: their knowledge is what makes the configuration good.
What happens to our existing data?+
Reference data comes with you: clients, sites and projects, staff records and training history, asset registers, suppliers and subcontractors with their compliance documents and expiry dates, price lists and open orders. Historic transactional detail is usually better archived than migrated, and we will tell you honestly which is which rather than promising a complete transfer and delivering a messy one.
How do our staff learn it without breaking anything?+
They learn in a full copy of your own system. Unibuild can run a sandbox that mirrors your live database, so training happens on realistic data, in the same screens, with the same permissions, and nothing anyone does reaches a real order, a real client or a real account. When the sandbox has filled up with training entries, it is refreshed from live in one action.
What if the system does not do something we need?+
Then we build it. That is the business we are in, and it is worth saying that the platform is as broad as it is precisely because a real contracting business kept asking for things and getting them. Your gaps become the next piece of scope rather than a change request sitting behind other clients in a queue.
What about a data processing agreement?+
Migrating staff, client and subcontractor personal data requires a lawful basis and appropriate handling, and the processing terms should be agreed before any migration begins rather than after it. That is a prerequisite of the engagement and not a formality, and it is a conversation we would have with you at scoping. The list of third parties data can pass through is published on our integrations page so your data protection adviser can start from it.
Next step

The first conversation
costs you nothing.

Why it is worth an hour You will see the system running rather than described Which is more useful than any brochure
Arrange a demonstration → Compare your options
Phone · UK hours
+44 7587 557546
Email
[email protected]
Your systems
Integrations
Demo calendar
unibuild.co.uk/demo