Pricing Models for ConTech
An insider’s take on how GC’s pass tech costs to clients and the pros and cons of pricing models.
This guest post was written by an industry insider who has chosen to remain anonymous given the the topic. Their perspective draws on direct experience with ConTech pricing models.
Pricing for construction tech startups is often talked about and seldom loved.
At best construction companies grumble as they pay your invoice and look for ways to stretch their usage (e.g. sharing logins).
But at worst it can break your startup.
Given this level of complexity, it’s surprising that there is no established playbook or answer on how construction companies wish to pay for software.
It’s likely due to the fragmentation of the industry where small construction firms (99.94% of US construction companies have fewer than 500 employees) have very different budgets and expectations to the ENR 400.
And the latter have long sales cycles making iterating on pricing a lengthy affair. You need to get it right as early as possible to showcase traction and raise capital from venture capitalists.
I’ve seen it all.
I’ve worked in and run innovation teams for big name general contractors and been an advisor to multiple early stage construction startups you’d have heard of before.
My opinion is that this challenge stems from a misunderstanding of how the construction industry buys software and allocates this cost to their clients. Understanding this dynamic is critical for optimizing your pricing structure and aligning your revenue model with how your customers want to pay.
Usually I’d openly state who I am when penning my thoughts, but in this case, as I am providing a peak under the hood at what I’ve seen and ‘gray’ tactics GCs use to reduce their software pricing risk, I’d prefer to stay anonymous.
Let’s dive in.
Contents
How GCs pay for technology
Option 1: Individual Line items
Option 2: Develop a blended rate
Standard Pricing Models
Per Seat
Revenue based
Project based
Non conventional pricing strategies
How GCs pay for technology
When a GC adopts a new technology, they want to include this in the cost of construction (e.g project budget) or pass it through to the client in the contract.
It’s easy to do during the piloting or trial phase as the technology cost can usually be allocated to an aligned project or funded by a dedicated innovation budget overhead.
The challenge becomes at the enterprise level.
It is because when GCs develop an organization-wide agreement, they need to determine how to allocate this cost to each project / client and recover it from the client. Construction software providers like Procore, Autodesk or CMiC aren’t going to individually bill every single project, only the enterprise.
Therefore they need an internal pricing strategy and rate that they can charge every project, based on the pricing model they are charged and then pass this cost on to the client.
So before we explore the software pricing models, let's first explain how GCs pass their technology costs to clients.
Option 1: Individual Line items
Each technology which is to be used on the project can be included in the proposal as a separate line item.
Calculating this line item price can be challenging as if the GC has an enterprise wide agreement, they need to apportion the pricing model to the project.
For example if it is per seat, then they would allocate the pro-rata cost of the seat multiplied by the number of people. Or if it is revenue based pricing, they can allocate this proportionally to the project size.
A challenge is that by having each individual software listed, a client may state that you don’t need some of the solutions and force you to remove it from the contract either making you eat the cost or impacting delivery and standard procedure.
Option 2: Develop a blended rate
What GCs prefer to do is to set up a blended rate for their standard technology stack.
They combine all the costs into one rate and add this into the general conditions section of the contract in their bid. If the client accepts it then the technology is included in the cost of construction.
The challenge is normalizing the cost correctly and determining what % of the software cost they want to recover from the client.
Now we understand how the cost is allocated, let's look at each pricing model in more detail, first looking at the standard ones and then the non-standard.
Standard Pricing Models
Each pricing model in the industry has its pros and cons and there are 3 main types:
Per Seat
Revenue based
Project based
Per Seat
This pricing model is the oldest and ‘original’ one. It’s now generally only seen in design software like Autodesk and Revit.
The problem with this model is that while you can make it seem cheap, including everyone in the project results in an exponential price increase. It creates an incentive to gatekeep the technology and selectively choose who can use the system.
We want everyone on the project team from Trade Partners to the Design Team to be able to access the software.
This model could gain in popularity with the rise of AI which is normalizing per usage or token based pricing. Customers may increasingly expect pricing which reflects how often software is used, not just whether they have access.
Revenue Based
This model scales based on the size of the project or enterprise (though a discount is provided on the latter) as it’s a calculation of volume.
While this model appears to make the most sense and is pushed by VCs, there are a number of important risks to consider as a GC:
Inflation Risk
During COVID, builders saw the price of the materials rapidly increase.
It meant that if a project was budgeted at $100M, it could easily cost $120M due to increases in the cost of materials. This additional $20m is only in additional costs and often the GC doesn’t gain any additional profit or improve their margin in this scenario. The project doesn't become any more complex than it was, the cost of materials just rapidly increased, so why did the software cost go up the same?
With revenue based pricing models, they now pay more for the software despite no improvements or increases in features. It meant they lost buying power.
The reason why is that for enterprise revenue contracts, GCs have to project revenue over multiple years.
For example they may pay upfront predicting $150m in revenue across 15 projects in the next 3 years. But due to inflation they can now only allocate software to 13 projects and have to pay more which would diminish their margin.
Market Risk
The nature of construction is that it is cyclical and impacted by macroeconomic forces. For example commercial construction projects have a correlation to movements in the interest rate.
This means that a GC can never quite accurately predict their revenue over a multi-year period. There is a risk that, even if their construction backlog is strong, project starts are pushed or delayed (e.g surprise tariffs).
And as GCs have to pay upfront for enterprise software contracts based on muti-year revenue projects which are subject to market risk, they are incentivized to underestimate revenue.
To go through an example, a GC may pay $250k for a software licence based on a $250m revenue projection over 2 years.
Unfortunately for them, in year 1 the market is impacted by trade tensions and they end up only doing $200m in revenue over the 2 year period. They’ve already paid $250k in software costs upfront and can’t go back and increase their blended technology cost in their project bids to recover the software cost.
But if they had a great 2 years and made $300m in revenue, the software provider would have asked for an extra $50k in overages at the end of the 2 year contract.
They normalize revenue upward, but don’t refund or lower costs if revenue falls short.
It creates an incentive to underestimate revenue to derisk the situation and pay the additional software cost later (and only if the software provider realizes you went over the revenue estimate).
Project Based
The last standard pricing model is project based pricing.
This model is typically applied in one of two ways:
Uniform pricing
A flat rate regardless of project size (sometimes sold in packages or bundles e.g 10 projects)Tiered buckets
Pricing based on project revenue ranges (e.g. $0–$10M, $10–$50M, $50–$100M, $100M+)
Some startups allow per project, per month pricing which allows for flexibility to only pay for the software as you use it.
This monthly cost model can benefit general contractors (GCs) under enterprise agreements as they may prepay for a set number of projects within specific revenue tiers. The prepaid licenses can be billed when a project kicks off helping to reduce exposure to inflation and market volatility.
Align the pricing model with the industry
While the above standard pricing models each have their pros and cons, the general challenge is that software costs don’t work with how construction operates and generally pays.
When GCs pay Trade Partners, they do so once they have completed work and based on how much work they actually did. As an industry, construction generally doesn't prepay.
An example of this model is how construction insurance is billed.
If a GC secures $1 billion in coverage with an underwriter, they don’t pay the full premium upfront. Instead, they pay as projects start, and only in proportion to each project’s insured value. The total coverage amount sets the rate tier they’re quoted.
So if they end up enrolling only $800m in projects, they’ll still pay premiums for those individual projects but at the rate associated with the $1 billion program expectation. This rate might be lower but insurers consider:
Minimum Earned Premium (MEP) provisions
These make a certain percentage of the projected premium non-refundable to cover administrative and risk costs.True-up provisions
This is where an insurer reconciles the projected construction value to the actual enrolled value and aligns the premium with actual exposure if there is a significant discrepancy.
This works great as the GC only pays for insurance as they use it and need it. As you know the difference in rate, once you hit the total amount can re-up with a new agreement. This transparency and pay as you go pricing model is a principle the software industry could learn from. It’s uncommon to pay on signing and they prefer to be billed when the solution is actively used and generating value.
Under current models, software costs are often misaligned with the risk profile. Vendors earn revenue regardless of market conditions, even when GCs margins are under pressure.
This misalignment can be addressed through alternative pricing strategies or the use of Letters of Intent (LOIs).
With an LOI, a GC commits to a target number of projects and agrees on a billing rate, but the project is only sent a purchase order once the project kicks off. While not legally binding, LOIs offer startups a signal of future demand providing validation they can use to attract investors and raise their next funding round.
Non conventional pricing strategies
The desire is growing for non conventional pricing strategies which help software costs be more accurately included into the cost of construction.
One challenge general contractors now face is how these costs are represented in their proposals. When they include the blended technology stack rate under the General Conditions section, this line item often appears higher than competitors’ bids.
When clients review proposals, they often review the General Conditions as the other sections of the bid such as materials or labor are seen as more fixed or less negotiable. This can put the contractors at a disadvantage, despite the long-term value that technology delivers.
This can be overcome by having startups invoice the Trade Partner directly. It allows software costs to be included into the cost of construction, rather than being isolated in overhead making the bid more competitive and enabling solution adoption.
It's reasonable to ask Trade Partners for this if they directly benefit from tools like Procore, ACC, Openspace or DroneDeploy, then it’s fair they share in the cost. Once they are directly invoiced, the cost becomes included in the cost of work and removed from the General Conditions section.
To say the quiet part out loud, big numbers spread out across multiple lines appear as a small number.
It also helps to correct a flawed aspect of how many construction tech companies charge today. In many cases, both the GC and Trade Partner are billed for the same revenue.
For example, a GC might pay on their $200M in revenue, while a Trade Partner is separately billed based on their revenue of $50M. But in reality, a portion of the GC’s revenue (e.g. $20M) was simply passed through to that Trade Partner. It gets counted twice, even though it’s the same dollars flowing through the project.
This model, where software costs are invoiced to those who use and benefit from it, ensures the client doesn’t double pay and aligns cost with value.
There’s no single formula for pricing in ConTech.
Each model carries trade-offs and every contractor has their own way of allocating costs. What matters is finding an approach that reflects how their clients manage projects and recover expenses, while giving startups the consistency they need to grow. And the closer pricing gets to matching how value is created and recovered in construction, the more sustainable adoption becomes.