How to Validate an AEC Startup Idea Before You Build It
One of the biggest mistakes I see founders make is starting with the product. They have an idea. They can already picture the software. The dashboard. The features. The AI assistant. The integrations. So they start building. I think that's backwards.
If you're building a company for architecture, engineering, construction, or design, your first job isn't to build the product. Your first job is to prove that the problem deserves a company. I've built companies in this industry, raised venture capital, talked to countless firms, and made plenty of mistakes along the way.
If I were validating an AEC startup today, this is how I would do it:
1. Start with the problem, not your solution
2. Find 20 people experiencing the same problem
3. Look for existing behavior
4. Find out who actually pays
5. Ask what they're already paying for
6. Sell before you feel ready
7. Build the smallest thing that tests your biggest assumption
If you're building an AEC, architecture-tech, design-tech or vertical SaaS company and need help pressure-testing the idea, positioning or product strategy, explore my Founder Strategy Sessions.
1. Start with the problem, not your solution
Don't ask: “Would you use software that does X?” You've already introduced your solution into the conversation.
Instead ask:
How do you handle this today?
Who is responsible for it?
How often does this happen?
What happens when it goes wrong?
What have you tried to fix it?
How much time or money does it cost you?
You aren't looking for compliments. You're looking for evidence.
Example: A common idea I hear is "architects waste hours manually taking off quantities from drawings." True. But the validating question is: how many hours, at what billable or loaded cost, and who currently owns the budget for that pain? If a project architect can tell you "this costs my studio 15 hours per project at roughly $85/hour," you have the beginning of a business case. If they just shrug and say "it's annoying," you have a feature request, not a company.
“Your first job isn’t to build the product.
Your first job is to prove that the problem deserves a company.”
2. Find 20 people experiencing the same problem
Founders coming out of architecture school or a design studio tend to validate ideas inside their own network — classmates, former coworkers, people who are polite by training. That's the fastest way to get false-positive validation.
Go find 20 people who have no reason to be nice to you: principals at firms you've never worked for, GCs you found on LinkedIn, structural engineers at a firm three states away. Cold outreach is uncomfortable and it is also the single most reliable signal generator in early-stage AEC startups. One frustrated architect doesn't make a market. Talk to 20 potential customers. If you're building for architecture firms, don't only speak to your architect friends.
Talk to:
firm owners
principals
project managers
operations leaders
designers
finance/administrative teams where relevant
You're trying to understand whether the problem repeats across organizations.
3. Look for existing behavior
One of my favorite signals is that someone has already created an ugly workaround. A spreadsheet. A giant Notion database. A collection of Slack messages. A manual weekly meeting. A person whose unofficial job has become keeping everything together.
That tells you something important: The problem is painful enough that people are already spending resources solving it. That's much more interesting than someone saying your idea sounds cool.
AEC problems are workflow problems. If you can't sketch the current process on a whiteboard — who touches the file, in what order, with what handoffs and what breaks — you don't understand the problem well enough to build for it yet. This is also usually the moment founders realize the "obvious" fix ignores three stakeholders who will quietly kill adoption later (the insurance team, the IT department, the field super who has to actually use the tool on a jobsite with gloves on).
4. Find out who actually pays
The user and buyer are often different people in AEC. A project manager may desperately want your product. But the principal may control the budget. Or operations may evaluate the software. Or IT may need to approve it.
Understanding this early changes everything about how you build and sell.
5. Ask what they're already paying for
What software are they using? What does it cost? What would they replace? Would your product become another subscription—or replace something they already have?
This begins telling you whether you have a product people admire or a product people will buy.
“Finding out an idea doesn’t work after 20 conversations is cheap. Finding out after 18 months of building is expensive. ”
6. Sell before you feel ready
Eventually, stop asking: “Would you use this?”
Ask: “Would you pay for this?”
There is an enormous difference.
Try to get:
a paid pilot
a deposit
a design partnership
a signed LOI
or some other meaningful commitment
Money isn't the only form of validation. But enthusiasm without commitment is weak evidence. If you can't get a prospective customer to tell you a rough number they'd pay — even a hypothetical one — before you've built anything, that's a signal, not a delay tactic. AEC buyers are used to being sold enterprise software with long procurement cycles. Getting even directional pricing validation early tells you whether you're building a $99/month tool or a $50K/year enterprise contract, and those are two entirely different companies.
7. Build the smallest thing that tests your biggest assumption
Your MVP doesn't need to look like the company you eventually want to build. It needs to answer your most dangerous unanswered question. Maybe that's: Will architects actually change this workflow? Test that. Not 40 other features.
Your validation artifact should be embarrassingly small: a clickable Figma prototype, a Google Sheet that mimics the output, a manual "concierge" version where you personally deliver the service behind the scenes. I've watched founders spend a year building a full platform before finding out the market wanted a much narrower wedge. A scrappy fake front-end that gets three firms to commit to a pilot is worth more than three months of engineering.
The standard I would use
Before spending months building an AEC product, I would want to know: Is the problem frequent? Is it painful? Does it happen across multiple firms? Are people already trying to solve it? Is someone willing to pay? Can I realistically reach that buyer?
If you can't answer those questions yet, you're probably not ready to build. And that's okay.
Finding out an idea doesn't work after 20 conversations is cheap. Finding out after 18 months of building is expensive. Building less at the beginning can dramatically increase your chances of eventually building something that matters.
Why this matters more in AEC than almost anywhere else
In consumer software, you can ship, learn, and iterate in public. In AEC, procurement is slow, trust is earned over years, and a bad first impression with a GC or a firm principal travels fast in a small, relationship-driven industry. Getting the validation phase right isn't about moving cautiously for its own sake — it's about making sure the one shot you get with each firm counts.
According to Construction Dive's coverage of 2025 built-environment funding, construction tech investment has more than doubled year-over-year, with the sector attracting $3.7 billion in venture capital through the first three quarters of 2025 alone. Capital is flowing into this space — but investors are increasingly funding startups with demonstrated demand, not just a compelling narrative. Validation isn't a "nice to have" step anymore; it's table stakes for raising.
Further reading
ConTech Funding Report 2025 — Last Week in ConTech's annual breakdown of where capital is flowing
Cemex Ventures Q3 2025 Contech Industry Insights — data on deal volume and stage distribution in construction tech
Y Combinator's Startup School — general-purpose but excellent on customer discovery mechanics