Audio article narrated by OpenAI
Amar’s path from Co-CEO of Autodesk to founder of a 50-person startup is not a story about reinvention. It is a story about permission: who had it, when it was removed, and what he did with the decade that followed. The thesis behind Motif, a cloud-native AEC design platform, was alive inside Autodesk in 2016 under the name Project Quantum; it was blocked by the structural priorities of a public company managing investor pressure and subscription conversion; it eventually shipped as Autodesk Forma, without him. Amar is the rare AEC founder who understands exactly why the incumbent cannot rebuild from inside: he was the person who tried. What follows is a conversation about the specific decisions, failures, and technical convictions that separate seeing what is broken from being allowed to fix it.
About Amar Hanspal
Amar Hanspal is the CEO and co-founder of Motif, a cloud-native AEC design platform that raised $46M from Redpoint and CapitalG to challenge Revit’s 27-year hold on building design. Before Motif, he served as Co-CEO and Chief Product Officer at Autodesk, where he spent nearly three decades and led the company’s transition from desktop to cloud, managing a product organisation of over 3,000 people. He co-founded Bright Machines, a manufacturing robotics company that raised $200M, before returning to the building industry to build what he calls the “north face” of AEC software.
—
“It’s probably been 25 years since I saw somebody use an AEC tool and their eyes light up. Most of it is like, oh my god, I’ve heard the word torture.” Amar Hanspal
—
The $17M MBA
Before Motif, before Bright Machines, before Co-CEO of Autodesk, there was RedSpark. In 1999, Amar left a senior position inside Autodesk to co-found what he describes as a product lifecycle management platform for the web, an idea that was technically coherent and commercially premature. Two and a half years later, after burning through $17 million, it was over.
He has called this experience his most expensive MBA: not because of what it cost, but because of what it taught him. The lesson was not about product management or technology. It was about what selling is.
“The thing about selling is that you end up describing the value of what you’re trying to create to a customer and see if they find it attractive enough. It’s like telling somebody: I came up with this amazing new medicine. You very quickly discover whether customers say ‘I have this pain’ — or not.”
This is the distinction that separates a complaint from a validated problem: not whether the customer recognises the pain, but whether the pain is sharp enough to fund a solution. Willingness to pay is not a commercial detail; it is the only honest test of whether you are describing something real and of value. The RedSpark failure, at its core, was a lesson in the difference between a problem customers will discuss and one they will fund.
This same test surfaces in the conversations I’ve had with AEC founders. When Onur Ekinci was building CalcTree, he arrived at the same framework through a different route: score pain points on frequency and intensity, then ask the one question that resolves everything: are they willing to pay to make it go away? Pattern Breakers puts it sharper still: “If your insight is correct, you should be able to find specific people who are desperate for you to build a product implementing that insight.” The right customer is not the median user. It is the person for whom the current solution is already unbearable.
What makes Amar’s version distinctive is the personal context: he spent the decade before RedSpark inside a large company, three levels down, protected from the full weight of the commercial question. “The big difference was being inside Autodesk three levels down, and then suddenly being at no levels and understanding how customers think about these things.” The RedSpark experience did what twelve years of seniority could not: it made the customer signal unignorable.
Why buildings, not robots
Between Autodesk and Motif sits Bright Machines: a manufacturing robotics company Amar co-founded in 2018 that raised nearly $200 million and explored what becomes possible when computer vision, then advancing rapidly from autonomous driving investment, is applied to factory assembly. The technical problem was genuinely interesting. The business surrounding it grew into something different.
“At some point the business around it became really difficult. Customers want a fully functioning assembly line and so all of the other things surrounding that core vision technology became disproportionally bigger and bigger — It became less about configuring robots and assembly lines and more about managing supply chains, integration with conveyer belts and picking systems, the temperature of the welding gun etc. All these things became more important than the software side of the problem.”
The phrase “I wasn’t the best guy to run a services company,” said about Bright Machines once the hardware-services complexity overtook the software thesis, is not a deflection. It is a precise diagnosis. Amar knows what he is good at: the software problem, the product problem, the question of what customers will fund. When the most important problems became procurement, configuration, and physical calibration, the match broke.
The contrast with buildings is revealing because it is not strategic. It is emotional.
“Buildings are beautiful. The people who work in this industry are super interesting people. There’s an emotional connection I have with AEC that’s stronger than what I had with manufacturing.”
He names the buildings: hospitals, schools, airports, shelters. The problem pulled him back not because he had run a rigorous market analysis, but because the resonance was real. This distinction matters: founders who return to a problem out of intellectual obligation tend to make different decisions than founders who return because the problem has them. The emotional anchor is not decoration. It is the reason the hard moments get resolved toward building rather than stopping.
This changes everything about how Motif was started.
Six ideas, one winner
After leaving Bright Machines in 2021, Amar and his co-founder Brian Mathews did something methodical. They did not return to a thesis waiting in their heads. They brainstormed six project areas (IoT, construction costs, bidding, design, and others) and called 20 people they knew in the AEC industry. One answer kept coming back.
“Every customer kept saying: why don’t you guys take a look at the design problem. And what’s really interesting honestly was it’s actually a really hard problem.”
Design, specifically building a better design system, rose to the top consistently. Amar and Mathews were initially hesitant. The idea had an obvious optics problem: two former Autodesk executives returning to compete with Autodesk’s core product. “It did sound like — well, you guys were at Autodesk, you did all of this, now you want to do it again. We were like, that’s why we had put it low on the list.”
There is a thread Amar left open in the conversation, not a disclosure but a trace. Reflecting on the Revit complaints he had been hearing since around 2014, he says: “So there’s a little bit of that that was in my head from 12 years ago.” He does not name it further. Project Quantum, the cloud-native design initiative he ran at Autodesk, which eventually shipped as Forma without him, was that prior mark. The hesitation, in other words, was not really about optics. It was about carrying something that couldn’t be named publicly, unfinished business that had been waiting for the right structural conditions to act on.
What broke the hesitation was not competitive conviction. It was the technical challenge. The other ideas on the list, IoT, occupancy sensing, construction bidding, were solvable. “Technically not that hard: sensors, get data, occupancy. It’s so solvable.” Design was different: browsers with memory limitations, buildings weighing 80 to 100 gigabytes, real-time performance requirements. “The technical challenges were what got our brains rolling.”
This is worth noting as a signal in itself. When experienced founders are drawn to a problem not by the market opportunity alone but by its genuine difficulty, that signals the moat is real. The same customers who asked for a better design system were implicitly confirming that the problem’s hardness was protective: anyone who could solve it would not be easily replicated.
But technical difficulty alone does not explain a return. Amar had already named what pulled him back: the 25-year silence in which nobody had watched someone use an AEC tool and had their eyes light up. The hardness of the problem was protective; restoring that joy was the reason it was worth protecting.
The validation structure Amar used at the genesis of Motif is the same one RedSpark taught him: do they have pain, and will they pay to fix it? This time, he ran the test before committing. The twenty customers asking for design were not delivering new information; they were confirming what Amar already carried in from the inside.
The geometry-first diagnosis
Revit was released in 1998. The complaints Amar started hearing from customers around 2014 were not the usual requests for additional features: curved railings, better section views. They were more fundamental.
“It was literally like you’re telling somebody the engine in the car doesn’t work anymore. It was no more about ‘I need a cup holder’ — it was the engine is not working.”
Nine-minute file opens. Models that had to be broken into smaller pieces to be manageable. Coordination that happened almost entirely outside the software itself. The a16z analysis of the AEC software market describes this precisely: “Collaboration happens almost entirely outside of the Revit system — everyone saves their model locally, syncs it to a master file, and spends time reconciling the conflicts that accumulated. It’s the construction equivalent of finance professionals emailing Excel files back and forth.”
Amar’s technical explanation of why this happens is precise and worth staying with:
“Revit is slow because it’s a graph database which means it understands all these connections — door is connected to a window, window is connected to a wall, wall is connected to a floor. When you make an edit, the reason Revit goes to sleep is because it’s looking through the entire database and figuring out all those connections and solving them one at a time. It’s almost like if in Microsoft Excel you change one formula and it looked through every cell in the spreadsheet to figure out if it had to change it.”
This is not a performance problem caused by age. It is a performance problem caused by architecture. The graph is resolved serially, one dependency at a time, because the system was designed for a single machine, running locally, in 1998. Google Docs showed that async dependency resolution is possible: changes are resolved slowly in the background, non-blocking. Elastic Compute Cloud means that what used to run on a single desktop processor can now be distributed across many cores. Modern databases support late binding: objects do not need to be declared as a specific type until much later in the process. Revit’s object model, built in the C++ era, requires every object to be declared from a class hierarchy: families, types, instances, all the way up. That inheritance chain was state-of-the-art in 1998. It is a constraint today.
“We have had the benefit of 27 years of technology since Revit was invented. Now you’ve got the entire cloud, which has elastic compute. You can really think of things in a very different way.”
The a16z framing is apt here: “Nobody replaced SAP by building a better ERP. They built around it until SAP became the plumbing nobody touched.” Motif’s data model is deliberately “looser” than IFC and Revit’s object model: objects do not have to be declared until later, fields can be added on the fly, and the geometric constraints that limited 1998 software are treated as optional rather than structural. Twenty-seven years of architectural advances, applied to a problem the building industry has been circling since the engine stopped working.
What product-market fit looks like in AEC
Motif’s current product set does not include an authoring tool. It is a companion: Sheet Review, live 3D streaming from Revit and Rhino, AI visualisation, design presentation canvases. The companion-first strategy is deliberate; trust must be earned before the authoring case can be made, and the signals Amar is watching to know whether the companion is working are worth understanding precisely.
There are two types: quantitative and qualitative.
Quantitatively, the signal is daily active users rising. “If you watch that every day, your number keeps rising — you know you’re doing something right. There’s a reason you come to Google every day, or use Zoom, because it’s working for you.”
The qualitative signal is harder to manufacture and harder to ignore:
“If you take this away I won’t be happy… that’s the signal. You cannot do this to me, I’m reliant on you.”
The “can’t take this away from me” moment, where users become angry if the product stops working rather than merely inconvenienced, is what separates habitual use from dependent use. Habitual use can be replaced. Dependent use is structural.
Beyond that, Amar identifies what he calls acts of love. The first is invitation: “You’d never invite someone to a restaurant you didn’t like. When someone invites two people I’ve never met to use the system, that is a very good signal of love.” The second is spontaneous social posting. “When somebody posts something socially without you asking — ‘look at what I created’ — that’s a sign of love.”
These signals appear in Pattern Breakers in a different register: the right early customer is “desperate” for you to build the product — already living in the future that your insight describes. The architecture firms that were already breaking Revit models into smaller files and losing hours to nine-minute load times were not waiting for Motif. They were waiting for anyone who could fix the engine. The acts of love are evidence that some of them have found what they were looking for.
Amar is explicit about where Motif sits today: the current customer is the architect. But the ambition extends across the full project team; engineers and contractors are the next frontier, and reaching them requires more than the same product with a different interface. Engineers need deeper capability, more precise language, the kind of detail their workflows demand. Getting there without fragmenting what architects already rely on is the central tension.
The same dynamic surfaces on the other side. When Ekinci was building CalcTree, the team deliberately hid features they already had, cutting back to serve the core persona rather than chasing breadth too early. The instinct maps exactly onto what Amar puts it: “You don’t want a jigsaw puzzle where everyone’s piece is one thing, but it doesn’t all come together.”
The floor before the flight
AEC does not grant startups patience. The industry’s project cycles, procurement rhythms, and institutional memory of prior failed tools mean that trust compounds slowly. Motif’s authoring bet is not a two-year play; it is a minimum of five years before meaningful parity. The companion-first approach is not positioning; it is arithmetic.
“We’re doing this along the way just to survive. We’re trying to basically do things and find smaller problems to solve along the way.”
Amar puts the window more starkly when pressed: building credibility in AEC takes eight to ten years. No startup survives that horizon on vision alone, and the industry will not accelerate to meet them. The companion products are not a hedge against the authoring bet failing; they are what makes the bet survivable.
The word “survive” is precise. It is not positioning language. It points to the structural reality that Will Meurer articulated in conversation about Assemble: “You can’t build a skyscraper from left to right. You have to build it from the bottom to the top.” The floor-before-flight principle in AEC is not a strategic preference; it is a survival constraint. The authoring bet is five years from parity. Without a companion product generating revenue and trust in the interim, there is no five years to spend.
The risk Amar names alongside this is the companion-phase ceiling: the possibility that firms come to value the collaboration layer precisely because it does not threaten the Revit investment they have already made. An architecture firm that uses Motif for Sheet Review and presentation but continues authoring in Revit is a customer, not a convert. The transition from companion to authoring platform requires something more than accumulated trust. It requires a customer moment in which the authoring limitation becomes the bottleneck: staying on Revit costs more than the switching cost of moving to Motif.
The Sam Carigliano insight from SkyCiv applies here: “They’ll watch you from the sidelines for a year or two before they invest their company knowledge into your platform.” In AEC, trust is compound interest, not a marketing campaign. The companion phase is not a concession; it is the only honest path through an industry that structurally resists incomplete products.
Why startups out-innovate, and what gets lost when they merge
The structural explanation Amar gives for why startups innovate faster than enterprises is worth staying with, because it is not a culture argument. It is an information architecture argument.
“Small company: it’s about survival. Large company: it’s about alignment. That changes where you push your energy.”
Three mechanisms: first, a startup has one thing to focus on. At Autodesk, Amar estimates he spent more than 65 percent of his time on alignment alone, connecting finance, product, marketing, sales, and legal around a shared priority. A startup eliminates that tax entirely. Second, communication speed is categorically different. “If I talk to a customer and they tell me something, it takes me less than half a day for the entire company to learn that. In a large company it would take half a year.” Learning velocity is the competitive advantage, and it is structural rather than cultural. Third, survival concentrates everything. When getting it wrong means the company ceases to exist, prioritisation becomes automatic.
The irony is that large companies have exactly the thing startups lack: customer relationships. “A sales guy at a large company can call 800 customers. I can call eight.” The ideal, Amar says, is a clear division of labour:
“The ideal combination someday would be: small companies build products, large companies distribute them.”
The danger in any merger that tries to combine those advantages is something Amar watched directly when smaller teams were absorbed at Autodesk. “The moment a little group that is more nimble and agile is plugged into an enterprise, it’s going to be absorbed by all the political things. The flat structure is gone and that’s where the risk is.” This is not a new observation: The Illusion of Innovation makes the same argument from a different angle, that innovation cultures large companies acquire tend to be metabolised rather than sustained. The advantage of a startup is not a cultural property that survives acquisition; it is a structural property that depends on the absence of the very things large companies provide.
This is the structural reason Project Quantum could not be completed within Autodesk. Not a failure of will or vision, but a failure of structural compatibility: the small, survival-oriented decision velocity that Motif now has was unavailable inside a public company managing 7,000 people and a subscription transition.
What the permission to act finally looked like
Motif emerged from two to three years of stealth not to hide from competitors, but to answer a question Amar did not want to answer publicly until he had the evidence in hand.
“Before we claim we’re going to go do this new design product, let’s be sure we can.”
The stealth period was technical validation. Amar had looked at other startups attempting cloud-native BIM during that period and found them unconvincing: “When I looked at what they had tried to do on the cloud, I was like: that’s not really a design system.” The stealth resolved technical doubt, not competitive fear.
Solving the technical question required assembling the right team first. Amar describes it the way a coach thinks about a squad: you do not need the eleven best people, you need the eleven that play well together. Three specific skill sets drove the hiring. CAD and geometry expertise, sourced through network hiring with roughly a 60 percent conversion rate among people approached. Cloud-native engineering, where the Twitter implosion created an unexpected availability window. And ML for 3D, which was the hardest of the three and took the longest to staff. Amar’s own contribution in that period was not technical direction on foundation models or data structures; it was integration, prioritisation, and communication: keeping the pieces connected and the next three decisions clear.
The permission to act, in the end, was self-granted but earned. It required RedSpark and taught what customers will pay for. It required the manufacturing chapter that clarified what kind of problem he is equipped to solve. It required the technical months of building confidence that the engine could be fixed. And it required the recognition, clear-eyed and not romantic, that he was carrying a sentence that had been left unfinished.
That team is what a16z’s analysis identified as the most credible direct attack on the Revit architecture. Not the most likely. Not the best-funded. The most credible: in AEC, that means the most specific understanding of why the incumbent is vulnerable and the most disciplined plan to exploit it.
The unfinished sentence
There is a closed loop in this story that becomes visible only when all three legs of the journey are held together. RedSpark provided the validation discipline: not whether customers recognise pain, but whether the pain is sharp enough to fund a solution. Bright Machines clarified the limits of fit, sharpening exactly what kind of problem deserved a return. The Autodesk years delivered the specific technical and political understanding of why the incumbent cannot rebuild itself; knowledge only available to someone who sat inside the room when the blocking decision was made.
Amar and Motif are not separable in this account. The company is the accumulation of the person’s permissions. The joy gap, the 25-year silence since someone last used an AEC tool and had their eyes light up, is not a market opportunity in the venture capital sense. It is an unpaid debt to the people who design hospitals and schools and airports. That debt was never going to be paid from inside Autodesk. What Motif represents is not a fresh start but a finishing: the specific kind of action that only becomes possible when everything that blocked it has already been lived through.