Construction Software in the Benelux: The Opportunity Behind Spotable’s Funding

Current investment focus: early-stage B2B and fintech in the Benelux, and Pakistani B2B products expanding internationally. Earlier articles remain dated analysis and may cover broader topics.

Construction software meets an everyday business problem

A contractor does not buy software because it has an impressive model. They buy it because preparing the next job becomes easier, the estimate is clearer or the team can respond to a customer with greater confidence. That is why construction software interests me as an operator and early-stage investor: the value has to survive contact with real work.

A fresh Belgian funding announcement provides a useful reason to examine this market. Spotable reports a €4 million seed round to develop its product and expand internationally. Its software helps contractors turn building information into measurements and quotations. The company’s announcement is dated 30 September 2026.

The round is a reported financing event, not independent proof of profitability or product performance. My interest is the business question it raises for other founders in Belgium, the Netherlands and Luxembourg: can a narrow construction task become a repeatable software business? The following is my proposed evaluation framework, rather than a judgment on Spotable’s internal results.

The quotation is a commercial decision

Start with a hypothetical roofing business receiving a request for a price. Before offering a figure, somebody needs to understand the job, identify assumptions, estimate materials and labour, and decide what margin makes the work worthwhile. A polished PDF at the end is only the visible output. The important product may be the process that makes its contents dependable.

I would ask a founder to follow one quotation from the first request to the final invoice. Where was information entered twice? Which assumptions changed after a visit? Which costs were missed? Who approved the final price? This exercise should identify a specific failure that software could address, without assuming every contractor works in the same way.

A useful first product might prepare a draft estimate while leaving commercial approval with the contractor. That is a clear boundary: help a person understand and prepare the work, then make it obvious which decisions remain theirs. A founder does not need to promise complete automation to demonstrate a valuable improvement.

Show the difficult jobs, not just the clean examples

In a demonstration, I would want to see an awkward case as well as a straightforward one. What happens when imagery is incomplete, the building has changed or a requested material is absent from the catalogue? Can the user correct an assumption and understand its effect? A fast answer that conceals uncertainty can be harder to trust than a slower, transparent process.

The proposed pilot should include a defined mix of ordinary and difficult jobs. Compare the draft against the contractor’s own reviewed estimate, document disagreements and have a competent person decide what the differences mean. This is a suggested evaluation method, not a claim that an AI estimate can replace site assessment or professional responsibility.

I would also look at how corrections are stored. A correction should improve the current job without silently changing unrelated projects. Keep the original input, the edited version and the approval understandable. For a small business, this history can be more useful than a technically elaborate explanation that nobody has time to interpret.

Measure value beyond minutes saved

Time spent preparing a quotation is a sensible starting metric, but I would not stop there. Measure the time needed to review and correct it, the number of requests abandoned, and whether a user can retrieve the assumptions later. Compare similar jobs. Otherwise, the easiest requests can make a trial look better than the work the business actually needs help with.

A higher acceptance rate is not automatically a commercial improvement. A quote that wins because it overlooks costs may create a problem later. I would ask the customer which outcome matters: quicker response, more consistent estimates, fewer omissions or a clearer handover to the people doing the work. Agree the metric before reviewing results.

For the startup, connect that outcome to pricing. Would the customer prefer paying per user, per completed quote or through a subscription? Test the proposal with a real buyer. An expression of enthusiasm is useful feedback; a willingness to pay and continue using the product is a different kind of evidence.

A supplier relationship can help, but incentives matter

My retail perspective makes distribution particularly interesting. A hypothetical construction-software company could reach contractors through a supplier they already know. That might simplify introductions and product education. It also raises questions about whose interests the software serves and how recommendations are presented.

If a tool includes material prices or product suggestions, I would ask how the information is maintained and whether commercial relationships are disclosed clearly. Can the contractor understand alternative choices? Who handles a price that changed between the estimate and the order? A useful connection should not leave the user guessing about the source or freshness of information.

Investors should examine the economics of the channel as well. Count training, support, partner compensation and integration maintenance. A large distribution agreement is not the same as active customers. I would rather see a modest channel with observable use than a long list of partners with no clear route to recurring revenue.

What should travel across the Benelux?

For expansion between Belgium, the Netherlands and Luxembourg, I would separate the core capability from the local implementation. Which parts of measurement or document preparation can be reused? Which depend on language, product catalogues, commercial conventions or local professional requirements? Those are questions to answer with customers and appropriate specialists, not assumptions to hide inside a growth forecast.

A practical milestone would be a second customer using substantially the same product without a second bespoke build. Track how much onboarding work decreases, what support remains and which exceptions still need attention. This gives an investor a clearer view of repeatability than a map showing future markets.

A focused invitation to founders and co-investors

For construction AI founders, the strongest introduction would show one real workflow, its current cost and the result of a reviewed pilot. Explain the limits as clearly as the gains. Our customer-workflow analysis offers a related starting point, while the investment page explains my wider focus.

I welcome conversations with Benelux founders building practical construction technology and with investors who bring relevant operating experience. Share your company or a co-investment idea, including what a customer has actually tested. The opportunity becomes interesting when useful work and a sustainable business model can be explained together.