Two property developers connect Letsbuild to Ziggu so snagging and aftercare points reach the homebuyer, with a daily sync and a report-level decision about what the buyer sees.
Letsbuild and Ziggu sit on opposite sides of one defect list. The building team works that list in Letsbuild. The homebuyer follows their own points in Ziggu. Joining the two is the job of the Letsbuild integration.
Letsbuild, known for years as Aproplan, is site management software used widely across Belgian construction. One of its functions covers site reports and the preliminary handover report, which is where most snagging points are first written down.
That report is also where the two lists start to drift, because the building team organises by trade and the buyer wants one thing: is my point fixed yet.
Vesta Development took on the connection to remove the follow-up work sitting behind every resolved point. Mathias Nolf, project manager at Vesta, puts the reason plainly.
“Time savings was the key. We were already using Letsbuild to document outstanding items during preliminary handovers, but there was still a lot of follow-up work needed afterward.”
“Through Letsbuild, contractors can indicate they've resolved an item. But is our client satisfied with the result? Client managers had to contact clients repeatedly.”
That is the gap. A contractor closing a point in Letsbuild says the work is done. It does not say the buyer agrees, and finding out meant a phone call per point.
“Thanks to the integration, client, developer and contractor are always in sync. Every item added in Letsbuild automatically appears in the Ziggu client portal.”
What the buyer sees is the state of their own unit: which points still need attention, which a contractor has resolved and are waiting on their approval, and which are finished.
“Even after handover, clients can still report an item if needed. They immediately see its status in their portal. That brings peace of mind.”
Nolf credits Stratokit, Letsbuild's integration partner, for the implementation: “We learned from each other and could improve certain workflows on both sides.” On the wider case for digitalisation at Vesta: “We want to quickly respond to new developments that offer clear efficiency advantages. We did the same calculation for Ziggu: the platform helps our team avoid mistakes. The cost per unit is quickly recovered.”
ION Develop Different went in with one goal: stop entering the same status twice. Cederic Veryser, head of digital at ION, describes what it used to cost.
“The goal was to minimise duplicate work. Previously, a client manager had to manually update every item in Ziggu based on the status in Letsbuild.”
Veryser names two gains. The first belongs to the buyer: an overview of the points they reported or that were noted at preliminary handover, with a description, the photos and the status. The second is work the customer advisor stopped doing.
“Previously, when clients requested updates on these items, client managers had to invest significant time. First searching in Ziggu for what the client reported, then checking status in Letsbuild, then summarising this back in Ziggu for the client.”
His third point is architectural, and it is the one that tends to outlive a change of tools.
“From a software architecture standpoint, I find it important that there's now a clear single source of truth. For aftercare, this is Letsbuild, and that remains possible thanks to the data flow with Ziggu.”
“For ION, this is the future. Time savings for our people and higher customer satisfaction. The ROI of this project is unquestionable.”
The change reads best as two columns: the same five moments, once without the connection and once with it.
| Moment | Without the connection | With Letsbuild connected to Ziggu |
|---|---|---|
| A point is recorded at preliminary handover | The advisor copies it into the client portal | The point arrives with the daily sync |
| A contractor resolves a point | The advisor checks Letsbuild, then updates the portal | The new status arrives with the daily sync |
| The buyer asks where their point stands | The advisor searches both systems and writes a summary | The buyer reads it in the portal |
| The buyer reports a defect after handover | The advisor retypes it into the site system | The advisor sends the report through to Letsbuild |
| Where the truth lives | Two lists that drift apart | Letsbuild for aftercare, mirrored to the buyer |
Nothing in that table takes a person out of the process. It takes out the retyping.
The connection is not a firehose. A team member on the developer's side decides, per report, whether the homebuyer gets to see it at all.
Points sync from Letsbuild once a day. They land in Ziggu against the right unit, and they are not visible to the buyer until someone publishes the report. That single decision is where the judgement sits. Internal categories, working notes and half-finished trade lists stay with the building team.
After a report is published, the buyer keeps receiving it. Updates that sync into that same report reach them without any further action in Ziggu. One decision at the start, and the report keeps itself current.
That is what separates this from a shared folder. A shared folder gives the buyer everything or nothing. Publishing per report lets the developer draw the line once, in the right place.
After handover the direction reverses. A buyer who finds a hidden defect reports it in Ziggu, against their own unit, with a photo. The advisor reads it, decides whether it belongs with a contractor, and sends it through to Letsbuild. The list carries on across the handover date instead of restarting as an email thread.
Two developers, the same conclusion. Vesta counts it in follow-up calls that no longer have to happen, ION in the typing that stopped. For a developer running handover and aftercare as one workflow, this connection is what keeps both halves of the list pointing at the same thing.
