Custom SaaS development: a construction management system built to sell

A company wanted to sell a construction management system

BuildBuy is a custom build. A company wanted to bring a construction management system to market —the budget, the site’s requests, the suppliers’ quotes and what reaches the site, all in one workflow— and asked us to design and build it. It has been in production since September 2026. That’s what building a SaaS with us looks like: the client brings the industry and the idea, and we turn it into a product it can sell. To validate it, we brought in a pilot builder that runs several sites at once: it contributed its real catalog, its rules and a review of every module; the client, the product vision and the go-to-market; and we, the design, the development and going live.

The problem the product had to solve

Before writing a line of code we had to understand how a builder buys, because that’s the problem the product would solve for every customer. A building project is budgeted once and executed over months. The budget comes from a takeoff —how many square meters, how much material per meter, how many people, how much equipment— and then it sits in a spreadsheet while the site keeps moving. The request came in over WhatsApp and Purchasing copied it into a spreadsheet. To get prices, one email per supplier; to compare, every reply into another spreadsheet; to buy, the order typed in again. The delivery note arrived as a photo and nobody checked it against the order. And every site bought on its own: two sites needing the same rebar in the same week ordered it separately. Mid-project, nobody could answer the simplest question: how much have we spent against what we estimated?

What we designed: one workflow, from the budget to the site

The product doesn’t change how a builder buys: it puts it in one place. The budget is built from recipes —how much material, labor and equipment each unit of work takes— and the approved version is frozen. Everything else flows from it, each step from the one before: the site’s request, the request for quote, the comparison, the purchase order and the delivery. People decide where a decision is needed: Purchasing chooses which suppliers to ask and who to award, and Management approves the budget. The system does the rest: merging requests, building the comparison, issuing the order from what was awarded and drawing down the budget with what arrives.

Everything that was added, month by month

BuildBuy started as a tool to order materials from the site and pool purchases across sites. Month by month we added what the client asked for —the budget, the catalog, the roles, the suppliers— and what we added ourselves so the product could be run and sold to any builder. The biggest change came from the pilot builder: start with the materials catalog and the budget, not with the request. And a rule she set herself: no data from an automated source touches the budget until a person has validated it. What the timeline marks as “We added” wasn’t requested by anyone: we put it in because a product sold to many companies needs it.

How it’s run: every company and every role with its own part

Five profiles use the platform, and each person sees what their role calls for. The site manager orders from a phone. Purchasing works on a board with every site’s requests in three columns: pending, in progress and received. Each supplier logs into its own portal, quotes, talks to Purchasing inside the request and accepts the order. Management sees each site’s progress against its budget and is alerted if someone bought at a higher price than another offer. And on site or at the warehouse, what arrived is recorded against the order. Because the client sells it to many builders, each one only sees its own data and sets up its own roles: groups with their permissions and access by site. Someone who is on one builder’s team and also sells to another signs in with the same account.

What we added: what a SaaS needs in order to sell

A system one company uses isn’t yet a product sold to many. We put in that difference ourselves, without anyone asking: each builder sees only its own data, the client can run the product and give support without touching code, it knows how the product is used and it has what it needs to sell it.

• MCP connectorBuildBuy can be run from Claude or another AI assistant, as a person, with their company and role.
• Usage analyticsWhich screens are used, where people get stuck and what they search for without finding it, without exposing sensitive data.
• Assistant and guidesIn-app help, tested with real user questions.

Under the hood: every material with its history, document by document

BuildBuy is a web app in React and TypeScript, with its database on Supabase (PostgreSQL) and deployed on Vercel: it runs on a computer or a phone, with nothing to install. It’s multi-company from the database up: every builder the client signs up has its data kept apart by the database itself, and each supplier only sees what concerns it. The client runs the product from its own back office —companies, demos, licenses and analytics— and more than 4,400 automated tests run before every change. What used to be a WhatsApp chat, a spreadsheet and someone typing is now a row: the material, the budget line it came from, its status and its history, from budget to delivery note.