By Claire Wilson, Siteline

Ten to 15 years ago, buying construction software looked very different than it does today. Most construction companies were focused on finding a single “system of record” that could handle accounting, job costing, and basic project management. If that system worked well enough, the fact that it didn’t connect to much else often felt like a minor inconvenience.

Fast-forward to today, where the technology landscape has changed dramatically. The market is now filled with highly specialized (point) solutions that solve specific problems: billing automation, lien rights management, document control, scheduling, field reporting, and so on. But if those systems don’t talk to each other, each new tool quietly adds complexity.

Furthermore, many construction teams are discovering that their long-standing, legacy system doesn’t integrate well (or at all) with newer tools, leaving teams stuck manually transferring data or creating spreadsheet workarounds.

All of this puts integration capabilities front and center in today’s software-buying decisions. The questions you ask during the demos—the extra details you press for—can really help you determine whether a tool will speed up or slow down your team.

Not All Integrations Are Equal

One of the most common misconceptions is that an “integration” is a binary concept: either a system integrates or it doesn’t.

In reality, when a vendor says their software “integrates,” they could mean several very different things:

1. File-Based Integrations

This is the most basic form of integration. In fact, I’d barely count it as an integration at all. Data is essentially exported from one system (often as a CSV or Excel file) and imported into another. Sometimes this process is automated on a schedule. Sometimes it’s manual.

Though simple to set up, this type of integration is just slightly more efficient than manual data entry. It often requires reformatting files and ongoing oversight, creating more opportunities for errors and delays.

2. Pre-Built (Native) Integrations

Pre-built (native) integrations are connections between two separate software platforms that are developed and maintained by the vendor(s). These integrations allow defined data sets—like customers, jobs, invoices, or payments—to sync automatically between systems without custom development.

Native integrations are pretty dependable and fairly easy to set up. But because they’re pre-built, they’re often not that flexible, so it’s worth making sure they move the right data, in the right direction, at the right time.

3. API-Based Integrations

An API (application programming interface) allows different software systems to communicate directly with each other in real time. When a vendor provides an open API, it means your team—or a third-party partner—can create custom integrations when a pre-built option doesn’t exist.

While API-based integrations require more technical resources, they’re often a sign that a platform was designed with long-term connectivity and scalability in mind.

4. Custom One-Off Integrations

Custom integrations are built specifically for a single customer, usually by a vendor’s professional services team or an outside consultant. They can address very specific workflow needs, but they’re typically harder to maintain over time. As either system changes, the integration may need to be reworked, which can add time, cost, and complexity.

Integration Questions Every Subcontractor Should Ask

Once you get past the integration buzzwords, the real work begins. Vendors may advertise a long list of integrations, but that doesn’t tell you what actually connects or whether those connections support your day-to-day workflows.

These questions are designed to help you understand what data moves between systems, how it moves, and whether the integration will hold up as your business grows.

1. What specific data flows between the systems?

“It integrates with accounting” doesn’t mean much on its own. You want to know exactly which data elements sync—customers, jobs, cost codes, invoices, payments, change orders, vendor records, and so on.

The vendor should be able to clearly list the data fields involved. If they use vague language like “key data” or “most information” without further specifics, proceed with caution.

2. How does the data flow between systems?

This question gets at the type of integration. Is it a native connection, file-based, or an API? This will help you understand how stable and hands-off the integration is likely to be.

For instance, if the explanation involves spreadsheets or frequent manual uploads, you’re probably looking at a fragile setup that may add more work rather than eliminate it.

3. Is the data transfer batch-based or real-time?

Batch-based syncing moves data on a schedule (hourly, nightly, etc.). Real-time syncing moves data as it’s created or updated.

Neither approach is inherently better—some processes can function well with scheduled updates, while others may depend on more current information. The key is confirming the sync timing aligns with how your team actually operates.

4. Who builds and maintains the integration, and what are the costs?

Ask whether the integration is built and supported by the vendor, a third-party partner, or requires custom development. You’ll also want clarity on who is responsible for updates and troubleshooting, and whether there are any upfront or ongoing costs tied to setup, maintenance, or changes.

5. What happens when one system updates?

Software changes constantly. Ask how the vendor handles updates to connected systems, their timeline for fixing broken integrations, and whether any integrations are being deprecated.

A mature vendor will have clear policies and a track record of maintaining integrations through system updates.

6. How do you validate that data is flowing correctly before go-live?

Before your team depends on an integration during their day to day, you should understand how the vendor tests and confirms that the right data is syncing as expected. Ask whether validation happens using real project and accounting data, who is involved in the process, and what happens if issues are uncovered during setup.

Think in Terms of Ecosystems, Not Tools

Today’s reality is that no single platform will solve every operational problem well. Growth happens by layering specialized tools over time. The difference between a stack that supports that growth and one that blocks it comes down to integration.

When you evaluate software through an ecosystem lens—how it fits with what you use today and what you may need tomorrow—you reduce risk, preserve flexibility, and avoid painting your business into a corner. Ask better integration questions up front, and you give your company a much better chance of scaling on your terms.

About the author: 
Claire Wilson is the co-founder and COO of Siteline , a billing software for subcontractors. Previously, she was a project manager at Tishman Construction in New York City, where she worked on major projects like Hudson Yards and JP Morgan’s Corporate Headquarters. She is
an active CFMA San Francisco member, serves on the Bay Area Subcontractors Association board, and has spoken at numerous regional and national construction conferences. Claire holds a BS in Civil Engineering from Bucknell University.