For the second issue of this series, I had the pleasure of speaking with Onur Ekinci, co-founder of Calctree. In this conversation, he walks us through how to find the right pain points, prototype fast, and earn trust in an industry where change moves at a glacial pace. Let’s dive in.
About Onur
As the Co-Founder and CEO of CalcTree, a platform that connects engineering workflows by seamlessly integrating designs, calculations, and reporting, Onur’s career spans diverse product leadership roles across EdTech, HealthTech, FinTech, PropTech, and now ConTech. Driven by a passion for leveraging technology to tackle complex, real-world challenges, he firmly believes better tools lead to better outcomes for those shaping our built environment.
Introduction
“If someone would still rather wrestle with the pain than pay for the fix, drop it.”
Onur, co-founder of Calctree
The Architecture, Engineering, and Construction (AEC) world loves projects: scope them, deliver them, close the file, and move on. Software doesn’t play by those rules. Code wants to be nurtured, tweaked, and lived in. When AEC teams apply their familiar “deliver and walk away” rhythm to digital tools, the result is often a half-finished app nobody enjoys using.
I recently spoke with Onur from CalcTree about what it takes to build products in a space where spreadsheets are sacred and risk aversion runs deep. Below is the conversation boiled down, but still raw enough to feel the splinters. It’s not a manual, but an invitation to a discussion we desperately need.
Is the pain worth solving?
Finding a problem in AEC is easy. Finding one that engineers are willing to pay to solve? That’s a different beast. “For us, it wasn’t just about finding a problem,” Onur explained. “It was about finding a frequent, intense problem people were actively trying to solve. But even then, the killer question is: ‘Are they willing to pay to make it go away?” To answer that, the team conducted numerous interviews, often 30 to 60-minute one-off talks with engineers, followed by three or four follow-up discovery calls to delve into problems, ideate solutions, and validate wireframes. “We took notes about the pain points that they described around the engineering workflows,” he said, and then scored each theme on how often it came up “once a week, once a day” and how intense it felt: from “annoying, but they’re happy to live with it” to “really annoying and I’m looking for a solution.” Only when a pain point passes the “willingness to pay” test does it become worth building; it is then that users choose a new tool over the familiar frustration. This crucial “willingness to pay” threshold is something Onur emphasised repeatedly, noting that
“You’ll often find that people would rather deal with the pain point or the way things currently are than pay for a solution. So you need to kind of cover all those bases.”
Overcoming this reluctance to pay isn’t just about budget; it’s about inertia. The comfort of the known, however clunky, often outweighs the promise of the new. To overcome that inertia, you need to show engineers not just that your solution is better, but that it’s worth the effort to switch. This reminds me of how Loom, when it pivoted to its current product, found that the simplicity and immediate value of asynchronous video communication overcame users’ resistance to change. They didn’t just solve a problem; they made the solution feel effortless.
Overcoming the spreadsheet reflex & building trust
But making a solution feel effortless is only part of the battle in AEC, because as Onur reiterated,
“You’re not just fighting inertia; you’re up against decades of trust built into tools like Excel. That subconscious click ‘new file, new spreadsheet’ is tough to break.”
He described this as an almost subconscious behaviour, deeply ingrained in engineering workflows. Breaking that cycle requires more than a slick interface; it requires patience and a profound understanding of why those old tools stick around. It requires shadowing users in their actual workflows to reveal the subtle rituals and workarounds that rarely emerge in interviews. Only by solving one high-intensity problem, whether it’s automating a tedious calculation or surfacing hidden data dependencies, can you create a pull so effortless that it overcomes deep-seated habits.
A good example of this targeted approach can be seen in how Airtable didn’t try to replace Excel outright; it started by solving specific use cases (like lightweight project management) that Excel wasn’t optimised for. Over time, it built trust and expanded its footprint.
Trust, in AEC, isn’t given; it’s earned, slowly.
“They’ll watch you from the sidelines for a year or two,”
Onur reflected on the industry’s cautious approach. “They need to see you’re going to stick around, that you’re not going out of business, before they invest their company knowledge into your platform.” This “time in the market,” as he put it, is a critical factor many startups underestimate. Can you withstand the scrutiny long enough to become a trusted partner rather than a fleeting experiment? Onur’s point about “time in the market” is a reminder that you’re not just selling a product, you’re selling reliability, longevity, and a commitment to the industry.
Navigating the enterprise maze
Building those early relationships and proving you’ll stick around paves the way to selling inside AEC firms. But how do you approach these large organisations?
“Forget rolling out company-wide initially,” Onur advised. “That’s an old IT sales model, and it’s anti-agile. It’s more like cellular reproduction. Find one person, or one small team, deliver value quickly, and let it spread.”
This targeted, organic approach, rather than a top-down global rollout, is often smarter, allowing success stories to build momentum within pockets of an enterprise.” He emphasised starting with SMEs where possible, as “it’s easier to get something up and running, whereas enterprises can take one to two years before they even decide to trial you.”
Given these long timelines, especially in larger firms, you need to identify early adopters who love your product and can advocate for it within their organisations. These champions are the anchor of any bottom-up adoption strategy. They’ll push for roll-out within their teams, share success stories, and help navigate internal politics. What is also true is that you need many of them, because the politics and governance in corporations can kill the enthusiasm of these early adopters.
Even within large firms, the strategy is to go small.
“You need a two-pronged strategy,”
Onur suggested, “Top-down, getting influencers and decision-makers to buy in, and bottom-up, where the engineers enjoy the product and get immediate value.” This often means navigating what has been called the “double chasm” a reference to Geoffrey Moore’s “Crossing the Chasm,” where a product must first cross the gap from early adopters to the early majority within the user base, and then, particularly in enterprise AEC, cross a second, internal chasm from user acceptance to managerial, IT, and procurement approval. Each step is a hurdle in its own right. It’s a long game, and the initial excitement of a few users can quickly get bogged down. Onur confirmed this deceleration, admitting that “As soon as it hits that cycle of broader company decision-making, it all kind of slows right down,” Onur admitted.
Avoiding the Frankenstein product: focus, prototypes, and timing
With so many potential users and use cases, how do you prevent your roadmap from turning into a patchwork?
“It’s easy to become a Frankenstein product,” Onur admitted.
“We even hid certain features that we used to have so we could focus on improving the ones that matter for our core personas.” They doubled down on their initial segment, “chasing after the use case they have in common before trying to branch out into other markets,” ensuring they weren’t diluting their offering. It’s so easy to get distracted by edge cases or requests from vocal users, but the best products succeed by solving one problem exceptionally well for a specific group of users. This principle is evident in how Superhuman focused on making email faster for power users before expanding to a broader audience. They even turned away users who didn’t fit their ideal customer profile early on to maintain focus
The antidote, he stressed, is ruthless prioritisation through rapid, tangible learning cycles. “Just go and prototype, create a mock, build a proof of concept, skip the endless meetings and debates about which idea is better,” Onur said. “Come back, test each other’s PoCs, see which one feels like the winning solution, and then go for that.” Every team member is empowered to spin up quick prototypes, whether that’s a Figma wireframe, an AI-driven mock in Mirror, or a lightweight build of the core feature. By lowering the barrier to experimentation, you tap into diverse perspectives and uncover creative solutions you’d never reach in a boardroom.
As these PoCs emerge, document every piece of feedback “anything that bugs you about the platform,” as Onur puts it and capture it in a shared backlog. Look for recurring themes in that backlog to identify your highest-leverage improvements. This continuous loop of “build, test, collect themes, and reprioritise” ensures you’re always focused on solving the most pressing pain points and prevents your product from bloating with every good idea that comes along.
Onur’s Henry Ford reference, “People don’t want faster horses; you have to give them a car”, is a powerful reminder to hop beyond incremental fixes and aim for truly transformative solutions. In AEC, where teams are often entrenched in outdated workflows, the challenge is to uncover the root pain and deliver a feature that feels nothing short of magic. When a user requests a new capability, don’t stop at “what”; dig into “why” and explore the underlying problem they are trying to solve.
Once you’ve sketched such a potentially transformative (“car” vs “faster horse”) idea, validate early: share your proof-of-concept with a small group of trusted engineers to gauge their reaction before you invest heavily. Their feedback will help you determine whether you’re heading in the right direction or pursuing the wrong path.
And timing matters as much as vision. Onur advised, “If it’s quite early with the product, don’t make it public… share it with the right people at the right times based on confidence in the product.” In the AEC world, releasing a half-finished project can erode trust and slow down progress. If you manage who gets to see your work and when, you can build up some confidence within the team. That way, when you do decide to share it more widely, you’ll be doing it from a strong position.
By going through this process of being super creative, asking the right questions, getting feedback early on, and picking the right moment, you can come up with a core solution that tackles one big problem really well, rather than diluting your impact with a messy “Frankenstein” suite.
The failure question – the culture conundrum: why we don’t talk about failure?
Building great products means failing fast and learning from mistakes. But AEC doesn’t work that way. So I’m asking every builder I talk to the same question: why is failure such a taboo topic in our industry?
I asked Onur, “Why is failure such a taboo topic in AEC?” His answer cut to the core:
“The ultimate fail here is a building collapsing or a bridge collapsing. That fear permeates into everything. If a startup talks about their failures, it spooks people. They worry it’ll bleed into their project’s safety.”
This fear, as Onur highlights, directly connects product development mistakes to catastrophic real-world structural failures, and it has a profound point. It stands in stark contrast to the tech industry, where failure is often celebrated as a badge of honour, proof that you’re pushing boundaries and learning quickly. Startups like Slack, Airbnb, and Stripe all have stories of early failures that ultimately led to their success. Those failures became part of their origin story and a testament to their resilience.
In AEC, mistakes get buried and then repeated. Without a safe space to admit, “We tried this, and it didn’t work,” teams can’t experiment or innovate. This fear suppresses innovation because teams are afraid to admit missteps, let alone share them publicly.
“We’ve failed at every step, learned, and iterated,” Onur insisted. “That’s how good tech products get built.”
By sharing our errors loudly and honestly, we can break the cycle of silence and accelerate progress in an industry where there’s too much at stake to stay quiet.
Conclusion
Building digital products for AEC isn’t glamorous. It’s slow, meticulous work, more like pouring a foundation than launching a rocket.
It demands more than just good code; it requires a deep understanding of a complex, risk-averse culture, a willingness to play the long game, and an almost fanatical devotion to the end-user’s unstated needs. It’s about those small things, brought together, patiently, until something extraordinary and genuinely useful emerges. And perhaps, it’s also about starting the conversations, even the uncomfortable ones, that will help us all build better.
Start small. Listen hard. Trim until what’s left is essential. In a field where every extra click can feel like friction on rebar, clarity is kindness, and kindness wins customers.