- Bricks & Bytes Bulletin
- Posts
- Why Pilots Fail Between the Starting Line and Scale
Why Pilots Fail Between the Starting Line and Scale
Owen Drury
November 12, 2025 • Estimated Reading Time: 18 minutes
Want to get your message in front of 2,104 highly engaged innovation leaders? Check out our sponsorship offers.
INDUSTRY INSIGHTS
Why Pilots Fail Between the Starting Line and Scale
Joshua Weyand's System for Moving Pilots Into Enterprise Adoption
You landed the pilot. Your champion signed off, funding was approved, and you started shipping software to a real project. The team was motivated. After a span of six weeks, the process of adoption came to a complete standstill. Your champion has become silent. The project has reached its conclusion. The pilot has been put on hold.
This happens more often than anyone admits in construction tech. Not because the product failed or because your champion lost faith, but because something else occurred between that initial commitment and the scaling conversation. Momentum died in the middle.
Joshua Weyand spent years as Director of Emerging Technologies at Suffolk Construction, managing 90 active pilots simultaneously across the company. Of those, roughly 40 were unique products. When his team approached project teams about piloting new technology, they saw about a 60 per cent willingness rate to actually try something new. The pilots started. The pilots got funded. Yet plenty of them died somewhere between completion and enterprise adoption.
"The problem isn't the pilot," Josh told us. "The problem is what happens after the pilot ends."
This is the gap nobody talks about in construction tech. It's costing deals.
Joshua Weyand, former Director of Emerging Tech at Suffolk Construction, managed 90 active pilots and learned why most stall.
TL;DR
Most construction tech pilots don’t fail because of the product. They die after the pilot.
Joshua Weyand (ex–Suffolk) ran 90 pilots and found the problem: momentum dies between pilot and scale.
His 3-step system:
Embed early. Don’t hand off the pilot. Stay close, learn the real constraints.
Run a second pilot. In a new region or project type to prove repeatability.
Pre-plan rollout. Map IT, Legal, Risk, and Union hurdles before scale.
Key metric: Pilots that transition, not just start.
Why vendors fail:
Treat pilots as sales wins
Poor comms on product changes
Ignore on-site constraints
Bottom line: Don’t pitch features. Pitch your pilot process.
That’s how pilots turn into enterprise deals.
Why One Pilot Isn't Enough
Most companies run pilots the same way: land a champion, deploy on their project, collect feedback, measure ROI, decide to scale or kill. It's linear. It's simple. It works fine for buying a piece of software that does one thing in one way.
Construction is different. Union rules that prevent facial recognition in New York don't apply in Arizona. A solution perfect for a new build might fail catastrophically on a renovation because the crew structure, timeline, and coordination challenges are entirely different. Market dynamics shift between pilot start and scaling. What seemed like a perfect strategic fit at month two becomes complicated by month six. Political winds shift. Priorities realign. Budgets get redirected toward more urgent initiatives.
Josh realized that most companies never account for this complexity during the pilot itself. They run one pilot, see success, assume it'll replicate everywhere, and wonder why scaling stalls. They treat the pilot as the finish line when it's actually just the beginning.
The vendors who understood this built the systems to handle it. The ones who didn't watch deals die in the middle.
The Three-Stage Framework
Josh developed a system that turns pilots into enterprise adoption. It's not complicated, but it requires intentionality at every stage.
Stage One: The Initial Pilot
This is where most vendors make their critical error. The sales team closes the deal and moves on. The solutions engineer disappears. Suddenly the customer owns the entire implementation, running it blind while trying to understand how the software fits into their actual workflow.
What actually needs to happen is different.
"If I can lean on them and say, 'Hey, what were some roadblocks you noticed when you did a rollout at another company?' that's unbelievably valuable," Josh said. "If I can avoid a mistake you've already made, then I'm going to have a better chance of rolling out."
The vendor's job in Stage One isn't to sell. It's to embed. Stay close. Run the pilot with the team. Learn what actually happens on a real project with real constraints. You are collecting data to determine if your product functions effectively in their specific environment, which includes their actual processes, political dynamics, and union regulations, rather than in a theoretical setting.
This stage answers one question: does your product work here?
Stage Two: The Second Pilot (The Critical Stage)
This is where most construction tech deals collapse, and it's also where most companies skip their most important step.
Josh's insight was to run a second pilot in a completely different context. Different project, different region, different constraints. Why? Because construction isn't uniform. A new build in Texas operates under completely different union rules, labor dynamics, and project complexity than a renovation in New York. A pilot that succeeded brilliantly in one context might fail entirely in another. If you run one pilot, see success, and assume it scales everywhere, you're gambling with your customer's money and your credibility.
Different region, different rules. One pilot isn’t enough.
What actually matters is the postmortem analysis. After the first pilot ends, sit down and assess three things: what worked, what didn't, and what you learned that contradicted your assumptions. Then go into the next pilot with those lessons embedded in your approach. You'll discover whether friction is decreasing, whether your implementation process is improving, whether you're building repeatable case studies that work across different contexts rather than lucky one-offs.
Each iteration should produce less friction, better processes, and more confidence about what will and won't work in their organization. You're not just running pilots. You're building a repeatable playbook. You're turning one success into a pattern.
"You're continuing to build out best practices and SOPs and lessons learned," Josh explained. "That makes it easier to scale through an organization, whether you're going the natural swell or you're doing a planned scale."
This stage answers whether your success was repeatable or a one-off.
Stage Three: Pre-Rollout Planning
Only after you've validated across different contexts are you ready for enterprise rollout. This requires mapping every stakeholder involved in the implementation: IT teams who handle integration, Legal teams managing data protections and contracts, Risk and Compliance reviewing sign-off, Field teams preparing for training, and Union leadership where applicable to your regions.
Josh calls this "negotiating success early." Map the obstacles before they become obstacles. Solve the problems during planning so they don't derail rollout when you're trying to move fast.
"The more pre-planning you can do, the better the rollout," Josh said. "If I can imagine all these different use cases and things that might happen before I scale, I'm going to have a better time."
This stage answers whether you're actually ready
The Real Metric That Matters
Founders track pilots that start. The innovation leaders who actually close enterprise deals track pilots that successfully transition.
Of Josh's 90 active pilots, 40 were unique products. Why the difference? The best pilots ran across multiple projects in different geographies because the first one succeeded and needed validation across constraints. That's not failure. That's strategy.
If you're losing deals between the initial pilot and enterprise adoption, the question to ask yourself is simple: are you staying embedded through Stage Two? Are you documenting frameworks and best practices after each iteration? Are you building a case for why this works, not just that it works?
The metric: what percentage of your pilots that show success in Stage One successfully move into Stage Two with different constraints?
Where Vendors Get It Wrong
Josh saw the same patterns repeat across dozens of vendors, and they fall into three clear categories.
Most vendors lose deals here, not because of the product, but the process.
The first mistake is treating pilots as a sales closure. The deal closes, the champion says yes, and the vendor checks the box while moving on to the next opportunity. But pilot success isn't actually about closing. It's about staying engaged throughout the validation period. Embed your best people through Stage Two. Let solutions engineers become internal advocates who genuinely care about whether this works. They need to be in the postmortem analysis. They need to learn what went wrong so the next pilot improves.
The second mistake stems from inadequate communication around product change. New features get released without proper notice. Customers discover them through random interface changes and feel blindsided. Josh's approach is fundamentally different: changelog documentation, admin toggles for new features that allow controlled testing, and a collaborative rollout strategy that lets customers feel they maintain control of their own adoption timeline.
The third mistake is skipping the incentive conversation entirely. Your product might be technically brilliant, but it may conflict with GMP contract structures or clash with existing project management methodology. Union rules prevent implementation in certain regions. Most vendors never explore these constraints during discovery because they assume what works in their pitch deck will work on site. Josh would get them in front of superintendents, project engineers, and foremen and ask what constraints actually existed. Only then could he understand what the pilot would truly require to succeed.
The Peer Group Play
Josh leveraged something most founders overlook entirely: peer validation from competing contractors.
When a vendor pushed back on product requests, Josh would call up innovation leaders at competing companies and ask if they'd also requested similar features. If multiple contractors wanted the same thing, he'd go back to the vendor and say, "This isn't just us. Competitor A, Competitor B, and we all need this." Suddenly the vendor cared.
Peer validation turns feature requests into market signals.
A single customer request is a feature request. Multiple independent requests represent a market signal. Vendors respond to market signals because they indicate scalability and adoption possibilities. Peer groups, whether formal industry organizations or your own network in Slack give you proof that your request isn't isolated to your company. Use that leverage strategically during pilot expansion conversations.
What This Actually Means
If you're a founder pitching to enterprise construction, stop pitching your product features. Pitch your pilot process instead.
Tell them: we'll embed, run a second pilot to validate across your constraints, iterate, document everything. Construction companies aren't innovators. They're implementers. They want tools that fit their existing reality, not tools that require them to change how they work.
A pilot that succeeds in one region might fail in another because of union rules, labor dynamics, or project complexity. A contractor in Texas operates under completely different constraints than one in New York. The vendors who understood this fundamental reality got the enterprise deals. The ones who didn't watched potential customers disappear somewhere in the middle.
The vendors who win in construction tech aren't the ones with the flashiest demos or the cleverest pitch. They're the ones who understand that a great pilot isn't the end of the story. It's the beginning.
"If you set that expectation early, you almost negotiate the success," Josh said. "Come review time, it makes it easier to say yes."
Reply and tell us: What's one constraint you didn't anticipate in your first pilot? Union rules, project complexity, stakeholder misalignment, or something else entirely? We're building a community around what actually works in construction tech. Your insight helps everyone navigate faster.
Check out the episode with Joshua Weyand here 👇👇👇
WEEKLY MUSINGS
SpeckleCon, Talent Structure, The Severance Effect
Speckle is data, and everything else is a lie.
The AI challenge is internal transformation
Formulas that work brilliantly eventually lose steam
SPECIAL OFFERS
The GTM Bundle
Together, they give you the full GTM playbook for construction tech from building trust-first marketing to structuring your sales motion, pricing models, and land-and-expand strategy.
 |  |
Individually, each guide is $100. Today, you can get both for $150.
YOU MIGHT ALSO LIKE
Premium Insights
More Insights
Reports and Case Studies
Most Popular Episodes
Super Series
OUR SPONSORS
 | Aphex - The multiplayer planning platform where construction teams plan together, stay aligned, and deliver projects faster. |
 | Archdesk - The #1 construction management software for growing companies. Manage your projects from Tender to Handover. |
 | BuildVision - Streamlining the construction supply chain with a unified platform for contractors, manufacturers, and stakeholders. |