Considering BuildOps? Five alternatives, and what its own contract says about your data.

BuildOps positions itself as management software for commercial contractors, and the whole product argument rests on the word commercial. Its own homepage draws the line explicitly: the platform was built from day one for the complexity of multi-trade service and construction, as opposed to what it calls other platforms retrofitting residential tools for commercial work. The five trades it names are HVAC and mechanical, electrical, plumbing, fire and life safety, and refrigeration.

That positioning matters more than it sounds. A residential dispatch product optimizes around a homeowner, a truck and a same-day visit. A commercial contractor lives on service agreements, recurring preventive maintenance, multi-visit projects with retainage and change orders, and asset histories that outlive the technicians who wrote them. Software built for the first shape and stretched to cover the second is where most of the operational friction in this category comes from, and BuildOps is selling against exactly that friction.

The company also runs three separate front doors by business type: a small business page, an enterprise page, and a private equity page selling one operational backbone across every operating company in a portfolio. That third door is the interesting one for anyone reading this from a roll-up, and it is covered further down.

OpsAI is the AI layer. BuildOps splits it four ways and the published capability list is specific rather than atmospheric. OpsAI for Field briefs foremen before the crew arrives, captures visit notes by voice, optimizes the dispatch board and summarizes past daily reports. OpsAI for Service fills an asset record automatically when a technician photographs a nameplate, and summarizes the full service history before anyone opens the panel. OpsAI for Finance generates invoice summaries, matches bulk payments to open invoices, and pulls line items from purchase order photographs. OpsAI for Sales reads completed visit notes and flags repair, replacement and upsell work that has already been observed on site.

Two lines of their own framing are worth quoting, because they are the honest parts. The first is the product philosophy: "Not a chatbot. Not a bolt-on." The second is the authority model: "OpsAI recommends, your team approves. Nothing moves without a yes." A vendor that commits in writing to a human confirmation step is describing a narrower and safer product than the agentic systems now being sold into professional services, and that is a point in its favor rather than against it.

Where does the value actually sit? In the nameplate capture and the visit-note reading, both of which turn something a technician already does into structured data without asking the technician to do more typing. That is a well-chosen problem. It is also, notably, a problem defined by your own field data, which is the same asset a commissioned build would work from.

Before the criticism, the fair read. BuildOps publishes a service level agreement, a security policy and a support policy as standing pages on its own site, and in a category where the norm is a marketing page and a demo form, that is genuinely unusual. All three were read in full on August 10, 2026.

The service level agreement commits to 99.9% uptime measured monthly across database, application and web servers, excluding third-party platforms. Scheduled maintenance is capped at five hours a month and confined to what the document calls non-peak hours, generally between midnight and five in the morning Eastern. BuildOps commits to forty eight hours of notice before planned maintenance and notification within thirty minutes of an unplanned outage. Most importantly it publishes an actual remedy table rather than a promise: 5% of the prior month's fees credited between 99.5% and 99.9%, 10% between 99.0% and 99.5%, 15% between 98.5% and 99.0%, and 20% between 98.0% and 98.5%. Four consecutive months at 98.00% is declared a material breach the customer may terminate on. Credits must be requested within thirty days of the month ending, which is the kind of clause that quietly expires if nobody owns it internally.

The security policy names Amazon Web Services as the infrastructure and describes the program as "a SOC 2 Type I certified program". It sets out encryption at rest and in transit, unique authentication per user with multi-factor enforced, least privilege access, quarterly access reviews with immediate revocation on departure, logged and auditable access activity, annual penetration testing by independent assessors and additional testing after major platform changes, a formal incident response plan, and business continuity and disaster recovery plans with backups tested annually for integrity.

One distinction inside that paragraph is worth pausing on, because buyers routinely miss it. SOC 2 Type I attests to how controls are designed at a point in time. Type II attests to whether they operated effectively across a period, usually six to twelve months. Type I is a real audit and it is not nothing, but it answers a smaller question than most procurement checklists assume it does. If a Type II report exists, ask for it and read the exceptions section. The published security page also makes no claim to ISO 27001 or FedRAMP, and the Terms of Service state that the service is not intended to meet HIPAA requirements and that BuildOps is not a business associate. For contractors doing work inside hospitals, that last sentence is a scope question worth raising early. The wider list of questions to ask sits in the security questions worth asking before any AI build.

None of what follows is hidden. All of it is published on buildops.com. It is simply published in the documents nobody reads before a demo, and each item changes a number in your business case.

1. There is no price anywhere, and the license is per seat.

The pricing page loads normally and carries no dollar figure of any kind. No per-user rate, no per-technician rate, no starting figure, no tier values. What it publishes instead is a process: a discovery conversation within one business day, a demo configured to your trades and your ERP, then a custom proposal built around crew size, the modules that fit, and the integrations the back office depends on.

The licensing shape is knowable, just not from the pricing page. The Terms of Service require the customer to ensure that the number of authorized users does not exceed the number of user licenses purchased under the applicable Order Form. That is a per-seat model, stated in the contract and withheld from the marketing. Three add-on modules are also named on the platform navigation, Fleet, Payments and CRM, each carrying a plus sign that in practice signals a separate line item. Whether OpsAI itself carries its own line is not published either way.

The practical consequence is that you cannot model this purchase before a sales conversation, which is the point of the design. When you do get a quote, ask for the platform cost and the AI cost separately, get the add-on modules priced individually, and ask what happens to the per-seat count when you acquire a company. The general arithmetic on subscription costs at scale sits at the real cost of off-the-shelf AI at scale, and the home services numbers specifically at what AI work costs a home services operator.

2. Your data trains their models unless you say otherwise.

The AI Features section of the Terms of Service is unusually explicit, and the default runs toward the vendor. BuildOps may use Customer Data, including input or output, "to train its local version of the AI or machine learning models so long as Customer has not opted out". The same clause then adds the consequence: some features may not be available to customers who have opted out.

Read that twice, because it is a two-part term. The default is training on your data. The escape hatch exists, and using it may cost you product. That is a materially different posture from a vendor that trains on nothing without written consent, and it is a question your quote should answer in writing rather than in a demo.

Two neighboring clauses belong in the same conversation. The terms disclose that output may not be unique across users and that the AI features may generate the same or similar output for other customers, which is a candid acknowledgement of how these systems work and a reason not to treat generated pricing language or scoping text as proprietary. And the customer is barred from using inputs or outputs to develop, train or improve any other AI or machine learning model, which is a clause worth noticing if part of your long-term plan is to build something of your own on your own operational history. Why that matters is the whole argument in why code handoff matters.

3. The exit is a thirty day window that requires you to act.

Ownership is not the problem here. The Terms of Service state that input and output, excluding BuildOps intellectual property, are Customer Data, and that as between the parties the customer owns all right, title, and interest in input and output. That is a better answer than several vendors in adjacent categories give, and BuildOps should be credited for putting it in writing.

Custody is the problem. On expiration or termination BuildOps may immediately deactivate the account, and it will make Customer Data available for export only if it receives written notice within thirty days of the effective date. After that period, in the document's own words, BuildOps "will have no obligation to retain Customer Data". A decade of asset histories, service agreements and job costing sits behind a thirty day clock that starts on a date your finance team may not be watching. The word renew does not appear in the published Terms of Service at all, so the subscription term and its renewal mechanic live entirely in the Order Form you have not seen yet. Ask for both, and put the export obligation somewhere with a calendar reminder attached to it.

Every pricing page below was opened and read on August 10, 2026. The pattern is consistent enough to be useful during a buying process, because it tells you which conversations will start with a number and which will start with a discovery call.

• BuildOps. No figure of any kind. The page publishes a three step sales process and a form. The Terms of Service establish per-seat licensing.
• ServiceTitan. Three packages named Starter, Essentials and The Works. The page describes the model as per-technician pricing and puts a Request Pricing button under all three tiers. No figure.
• ServiceTrade. The page is headed "Simple, transparent field service software pricing" and contains no number. It does explain the model: pricing is driven mainly by the number of technicians supported, plus one of three suites, Select, Premium or Enterprise. Worth noting for an AI evaluation, the AI-powered features start at the Premium suite rather than the entry tier.
• Simpro. A base plan plus a catalogue of add-ons including digital forms, data feeds, a maintenance planner and takeoffs. Request Pricing throughout. No figure.
• Procore. Custom quote, no figure, but a genuinely different shape worth understanding: unlimited users, unlimited data and 24/7 support are the headline, with a footnote that the field productivity product is priced on full time equivalents. A platform that does not charge per seat prices growth differently from one that does.
• Jobber. The exception, and it sells to a different customer. Full public pricing: Core at 49 dollars a month, Connect at 139 and Grow at 199, each for a single user, with annual billing bringing those to 29, 99 and 149 after a promotional first year. Jobber serves smaller residential shops rather than commercial contractors.

The regularity is hard to miss. Products sold to owner-operators publish a price. Products sold to commercial contractors do not, and the AI-bearing tier is reliably the one without a number attached. That is a negotiating fact rather than a scandal, and it is the reason a three year comparison beats a monthly one. The method for running that comparison is at off-the-shelf AI versus a commissioned build.

The clause that decides where a build conversation starts.

Buried in the support policy is the sentence that settles more architecture arguments than any feature comparison. BuildOps support covers platform functionality and configuration, troubleshooting and defect escalation, access and connectivity, supported integrations and standard import and export utilities, and clarification of new behavior after a release. It then states that support does not include custom development, scripting, or modifications to the service or customer systems, including custom integrations.

That is a completely reasonable boundary. Every SaaS vendor draws it somewhere. But it is also the exact line where the platform stops being an answer and starts being a dependency, and it is drawn well inside the territory most contractors assume they are buying. The moment your operation needs something the product does not already do, you are scoping and funding a project regardless of who builds it. The only open question is whether you own the result.

Pair that with the third-party integration terms, which say BuildOps does not control and has no liability for third-party integrations, does not warrant that any specific integration will be provided, and reserves the right to change the available list. A dispatch workflow that depends on a connector to your ERP is a workflow with a dependency you do not control and cannot price.

This is why the useful evaluation question is not whether OpsAI is good. On its published scope it looks well chosen and honestly framed. The question is what happens to the part of your operation that no platform covers, and whether that part is where your margin actually lives. Only you can answer that, and the answer is usually specific rather than general: one quoting method, one renewal motion, one reporting view that nobody has packaged because nobody else needs it in that shape. The pattern of what happens when nobody asks the question in advance is documented at why mid-market AI rollouts stall in month four.

One more clause worth reading before you sign.

The restrictions section prohibits the customer from publishing benchmarks or performance information about the services, or facilitating third parties to compile performance measurements about them. Meanwhile BuildOps reserves the right to use usage data for its own analytics, benchmarking and capacity planning, and states it will not publish usage data unless anonymized and aggregated.

That asymmetry is standard in enterprise software and is not evidence of bad faith. It is worth understanding anyway, because it shapes what you can ever prove about the product publicly, and because it explains where the marketing statistics come from. The headline figures on the homepage are a 76% increase in revenue per technician, an average of 2.6 tools replaced and 80% more work handled without more overhead, all attributed to a BuildOps benchmark report. The OpsAI page adds a 50% reduction in admin work, a 73% cut in billing time and a 75% quote approval figure.

To their credit, the population is disclosed rather than implied: the benchmark webinar page states that BuildOps "benchmarked 1,500+ contractors across nine core KPIs" including days sales outstanding, revenue per technician and win rate, publishing the result as Torque 26. That is a genuine sample, not an invented one. It is also a vendor study whose full report is gated behind a registration form, measuring customers of the product against a baseline the vendor defined. Treat every one of those numbers as a vendor claim, which is what they are, and ask what the baseline was before you put any of them into a payback model.

When BuildOps is the right answer.

Often. A commercial mechanical or electrical contractor running on a residential product, a shared inbox and three spreadsheets does not have an AI problem, and buying a platform designed for service agreements, recurring maintenance and multi-visit projects is the correct first move. Custom software layered over that mess would inherit the mess. Put the system of record in first.

It is also the right answer when your trades and workflows are genuinely standard, when the integration list you need is already on their published connector set of QuickBooks, Sage, NetSuite, Viewpoint Spectrum and Viewpoint Vista, and when your seat count is small enough that per-seat licensing is cheap against the administrative headcount it removes. In that situation the honest recommendation is to buy the platform and revisit the question in a year.

The situation where commissioning wins is narrower and more specific. It is the operation that has already bought the platform, already has the data flowing, and has hit the boundary the support policy draws. It is the roll-up with four operating companies on three different systems that needs one view before it can report to a lender. It is the contractor whose quote-to-close advantage comes from a pricing method nobody has productized. That is what our home services offering is built for, and the honest framework for choosing between the three routes is at build, buy or commission.

How to run this evaluation properly.

Ask for the quote broken into platform, modules and AI, with a worked example at your real seat count rather than a headline rate, and ask what a seat costs when you acquire an operating company. Ask for the Order Form language on subscription term and renewal before you negotiate the price, because the published terms are silent on both. Ask whether the AI training opt-out is available to you and precisely which features you lose by taking it. Ask for the SOC 2 report itself rather than the certification line, and read the exceptions. And write the thirty day export notice into your own calendar on the day you sign, not the day you leave.

On the build side, the useful sequence is to name the single workflow costing you the most, measure what it costs today, and only then decide whether a platform feature, a point tool or a commission is the right instrument. How we work sets out the sequence and pricing shows the fee bands. The AI maturity assessment takes about ten minutes and tells you whether the data underneath any of this is ready. The buyer checklist for this vertical is at how to choose an AI consultant for a home services operator, and operators comparing firms rather than software should start at AI consultants for PE-backed home services platforms.

What is BuildOps, and what is OpsAI?

BuildOps is management software for commercial contractors, sold to multi-trade service and construction businesses in HVAC and mechanical, electrical, plumbing, fire and life safety, and refrigeration. Its own positioning is that it was built for commercial complexity from the start rather than adapted from a residential product. OpsAI is the AI layer inside it, and BuildOps describes it in four slices: OpsAI for Field, for Service, for Finance, and for Sales. Published capabilities include briefing foremen before the crew arrives, capturing visit notes by voice, summarizing past daily reports, filling an asset record from a photograph of a nameplate, generating invoice summaries, matching bulk payments to open invoices, pulling line items from purchase order photographs, and reading completed visit notes to flag repair and replacement opportunities. The framing on their own page is that OpsAI recommends and the customer approves.

How much does BuildOps cost?

BuildOps publishes no price. Checked on August 10, 2026, the pricing page loads normally and contains no dollar figure of any kind: no per-user rate, no per-technician rate, no starting figure and no tier values. What it publishes instead is a process. A discovery conversation within one business day, then a demo configured to your trades and your ERP, then a custom proposal built around crew size, the modules that fit, and the integrations the back office depends on. The Terms of Service tell you more about the licensing shape than the pricing page does, because they require the customer to keep authorized users at or below the number of user licenses purchased under the applicable Order Form. That is a per-seat model with the seat price withheld until you are in a sales conversation.

Does BuildOps train its AI models on my company data?

By default yes, and the opt-out has a cost. The Terms of Service state that BuildOps may use Customer Data, including Input or Output, to train its local version of the AI or machine learning models so long as the customer has not opted out, and the same clause notes that some features may not be available to customers who have opted out. That is an opt-out default with a feature penalty attached, which is a different posture from a vendor that trains on nothing without written consent. Two related clauses are worth reading in the same sitting. Output may not be unique across users, so the same or similar output may be generated for other customers. And the customer is barred from using inputs or outputs to develop, train or improve any other AI or machine learning model.

Who owns the data and the AI output in BuildOps?

The customer does, and BuildOps says so plainly, which is more than many vendors in this category bother to address. The Terms of Service state that input and output, excluding BuildOps intellectual property, are Customer Data, and that as between the parties the customer owns all right, title, and interest in input and output. The ownership section repeats the point for intellectual property generally. The caveat is not ownership but custody. Following expiration or termination BuildOps may immediately deactivate the account, and it will make Customer Data available for export only if it receives written notice within thirty days of the effective date, after which it has no obligation to retain the data at all. Owning your records and being able to collect them are two different rights, and the second one runs on a clock.

What does BuildOps publish that its competitors do not?

Three documents, and they deserve credit for it. A service level agreement policy commits to 99.9% uptime, caps scheduled maintenance at five hours a month inside a stated overnight window, promises forty eight hours of notice before planned maintenance and notification within thirty minutes of an unplanned outage, and publishes an actual service credit table running from 5% of the prior month's fees to 20% as availability falls. It also states that 98.00% uptime across four consecutive months is a material breach the customer may terminate on. A security policy names AWS as the infrastructure, describes encryption at rest and in transit, multi-factor authentication, least privilege access, quarterly access reviews, annual penetration testing by independent assessors, and an incident response plan. A support policy sets out what support covers. Most field service vendors publish none of this.

Which commercial field service vendors publish a price?

Checked directly on August 10, 2026: almost none of the ones aimed at commercial contractors. BuildOps publishes no figure. ServiceTitan presents three packages, Starter, Essentials and The Works, describes the model as per-technician pricing, and puts a Request Pricing button under all three with no number. ServiceTrade heads its page Simple, transparent field service software pricing, explains that pricing is driven mainly by the number of technicians supported plus the suite selected, and then asks you to request pricing for each of Select, Premium and Enterprise. Simpro shows a base plan and a catalogue of add-ons behind a Request Pricing button. Procore quotes custom, though its shape is different because it charges for unlimited users rather than per seat. The contrast is Jobber, which serves smaller residential shops and publishes the whole card: Core at 49 dollars a month, Connect at 139 and Grow at 199, each for one user, with lower annual rates. The pattern across the category is that the further up market a product sells, the less likely the price is to be published.

What does the BuildOps support policy exclude?

Custom work, and this is the clause that decides where a build conversation starts. The published support policy covers platform functionality and configuration, troubleshooting and defect escalation, access and connectivity, supported integrations and standard import and export tools, and clarification of new functionality after a release. It then states that support does not include custom development, scripting, or modifications to the service or customer systems, including custom integrations. Read alongside the third-party integration terms, which say BuildOps does not control or warrant third-party integrations and that the list available is subject to change, the boundary is clear. Anything the platform does not already do is your project to scope, fund and own, and the vendor's support desk is not the route to it.

What are the real alternatives to BuildOps and OpsAI?

Five, and they are not interchangeable because they answer different questions. Stay on BuildOps and switch OpsAI on, which is cheapest because the data is already in place and no migration is involved. Move to another commercial-capable platform such as ServiceTrade, ServiceTitan or Simpro, which changes the vendor without changing the shape of the purchase or the per-seat economics. Run the project side on a construction platform such as Procore if the operation is project-weight rather than service-weight. Add narrow point tools where the platform stops, accepting that each one is another integration and another subscription. Or commission a build that reads the data BuildOps already holds and owns one workflow end to end. The first question is not which AI is better. It is whether the system of record moves.

When is BuildOps the right answer for a commercial contractor?

More often than a firm that sells custom software would like to admit. If you are running a commercial mechanical, electrical, plumbing or fire operation on spreadsheets, shared inboxes and a residential product that was never shaped for service agreements, multi-visit projects and asset histories, buying a platform built for that work is the correct first move and no amount of custom software substitutes for it. The same holds if your trades and workflows are standard, if your back office is small enough that a per-seat license is cheap relative to a headcount, and if your integration list is already covered by their published connectors. Commissioning becomes the better question after the platform is in and working, when the remaining bottleneck is specific to your operation rather than common to the category.

Should a private equity backed platform standardise on BuildOps across operating companies?

BuildOps sells directly to that buyer and publishes a dedicated page for it, promising one operational backbone across operating companies and financial data flowing into Sage Intacct, NetSuite or Vista. For a platform rolling up commercial trades, the case for one system across the portfolio is real and the reporting argument is the strongest part of it. Two questions decide whether it holds. First, the diligence question: a per-seat license multiplied across every acquired operating company is a cost that grows with the thesis, and the price is not published, so model it with real seat counts before signing a portfolio-wide agreement. Second, the data question: if the platform's own value is a single view across operating companies, confirm in the agreement how that data leaves the system, because the published exit path is a thirty day written notice window.

Related reading.

More on the field service AI field: what we build for home services platforms, five things PE platforms get wrong about ServiceTitan AI, and AI for PE-backed home services platforms. The integration paths for the adjacent platforms are documented at the ServiceTitan AI integration playbook, the FieldEdge playbook, the Housecall Pro playbook and the Workiz playbook. If the vocabulary is new, start at what AI commissioning means and what a mid-market engagement costs. Operators willing to contribute data can also see the 2027 home services platform AI benchmark, and the rest of this series sits on the comparisons hub. To size your own numbers first, the home services calculator takes a few minutes.