The birth of Revit

Charles River Software was born. October 31, 1997, Newton, Massachusetts — two developers out of PTC with a license in their pocket and an idea inherited from fifteen years of others' attempts. If you have read the article on Sonata, you already know this part.

But a company is not yet a product.

Three years pass between its founding and the moment the world first hears the name "Revit." Three years that, in most accounts of how the software we use every day was born, vanish into a single line: "they founded the company in '97, they launched Revit in 2000." As if nothing happened in between — as if the product had come out already formed, with the same name, the same logic, the same promise we know today.

That is not how it went. And the interesting part — the one no one tells — is precisely the one that lies in between.

Because having the right technology in hand (Raiz and Jungreis brought it with them from PTC) does not mean you have yet understood what to build on top of it. Sonata had proven it years earlier: the engine alone is not enough. You need someone to decide what it must do, for whom, and — above all — who finds a way to say it in a single word.

That word would come, but first there is a technical problem to solve that no one, up to that point, had ever truly solved.

The three invisible years (1997-2000)

The first difference compared to Sonata is seen immediately, and it is not technical — it is structural. Ingram had built it alone, in an attic, with a bank loan. Raiz and Jungreis did not. Charles River Software was born with real capital behind it already: Atlas Venture and North Bridge Venture Partners financed the project from the start, and that money was used for one precise thing — hiring. Developers, but also architects, brought into the team not as external consultants but as part of the software design process itself.

It is a choice that already says much about the strategy: if the problem with Sonata was that the power of parametric design remained locked inside a programming language, understood only by those who wrote it, then the new software had to be born with architects in the room from the very first day — not added later to "validate" a product already decided.

In 1999 the structure grew even stronger: Dave Lemont arrived as CEO, and the board was joined by Jon Hirschtick, founder of SolidWorks, and Arol Wolford, founder of CMD Group. It was no longer just a technical team writing code in C++ on Windows — it was, for all intents and purposes, a startup preparing for a real commercial launch, with people who had already brought a CAD product to market before.

But the part that really counts, the one that justifies three years of work instead of three months, is technical — and this is where Revit stops being "Sonata with more money behind it."

Sonata, as we have seen, already knew how to update views when the model changed. But the parametric modeling that ran in the mecCAD of the time — the one Raiz and Jungreis worked on before, on Pro/Engineer — was variational and history-based: the model remembers the sequence of operations that built it, and every change must be recalculated by retracing that history. It works well for an isolated mechanical component. It becomes a computational nightmare when the "component" is an entire building, with thousands of elements that depend on one another in real time.

The real work of the three invisible years was to build something different: a context-driven parametric propagation engine — capable of updating every view, every section, every schedule of the model the very moment you change a single parameter, without having to recalculate the entire history of the object. Not a "deferred" update like in Sonata. An instantaneous and bidirectional update — you change the section, the floor plan updates itself; you change the floor plan, the section responds in the same instant.

It is the difference between a model that knows how to update itself and a model that does it while you watch it.

The name as a manifesto

An engine that updates the model in real time, in every view, at the same instant you modify it: that is a huge thing, technically.

But a company about to launch a product doesn't sell an engine; it sells a promise in a word. And here the story of the name has a twist more interesting than it seems from the version that usually circulates.

The most widespread legend says that "Revit" is an acronym designed at a desk: Revise vit — or rather, Revise Instantly. Elegant, consistent, perfect to recount in a slide. The problem is that it didn't exactly happen that way.

The original name chosen by the team was not Revit. It was Perspective — until they realized it was already registered by another software. At that point, Charles River Software hired an external communications agency to find a new one. Among the proposals on the table were names that today sound almost comical because they are so far from what we know — Archadia, Estuary — until Revit emerged: an invented word, chosen on purpose because in the mind of whoever hears it, it evokes revision and speed together, without being technically an acronym for anything.

Yet the "Revise Instantly" legend is not an error to be corrected — it is the real point. It does not matter if the name was born as an acronym or as an invention of a branding agency: what matters is that the company itself let that reading spread, because it is exactly the message it wanted to convey. A name that does not describe a category of software (like "AutoCAD," automated CAD), but declares an immediate benefit, almost a slogan disguised as a product name.

And it is consistent to the end with what the team had just spent three years building in the previous block: not a more powerful software, but a software faster to respond. The context-driven parametric propagation engine is not a changelog detail — it is the raison d'être declared from the very name on the box.

Sonata had the technology and no slogan. Revit arrives with both, in the same package.

The launch and the first reception

Before Revit truly arrives on the market, there is a step that almost no one talks about: the software is not born already finished; it comes out in the hands of a few first. Charles River Software released two private, non-public versions — "Early Adopter 1" in November 1999 and "Early Adopter 2" in January 2000 — placed in the hands of a restricted group of real firms, even before the product had a definitive name on the market. It is not a bureaucratic detail: it is the proof that the architects "in the room" we were talking about before were not there only in the design phase; they remained inside the process until the last mile, to test what would then become public.

Revit 1.0 was officially released on April 5, 2000. And it arrived with a commercial choice as little talked about as it was radical: it was not sold as a perpetual license for thousands of dollars per seat — like AutoCAD, like practically all CAD software of the time. It was sold by monthly subscription, payable by credit card, activated and deactivated at will. In 2000, twenty years before Microsoft 365 or Netflix made subscriptions the norm for any software, it was almost a gamble.

The logic behind it is not ideological; it is market-based: the majority of American architecture firms at the time had ten people or fewer. For them, the entry cost of a traditional CAD was a real barrier. The subscription lowered that barrier — consistent, once again, with the underlying idea: not a tool for a few specialists with large budgets, but a product designed to be within reach of anyone who does this job.

The reception, however, was not an immediate explosion. It was a slow adoption, decided by individual firms willing to bet against the current. One example above all: in New Zealand, the firm HMOA adopted it in 2001 — among the first in the world outside the United States — and colleagues in the sector, according to what one of the founders says today, thought they were taking "an enormous risk." They were not entirely wrong: in the same period, the software went from version 2.0 to 4.1 in less than two years, a sign of a product still in full evolution, corrected and refined almost in real time on the basis of feedback from those already using it in the field.

There is a thread that closes here, and it is the one with Eastman. In '75, his idea of a single, integrated database for building design was theory — an academic vision, published in a trade journal, without a product that made it real. Twenty-five years later, Revit was the first time that theory became something that a firm of ten people could buy with a credit card and use the next day. It is no longer an article to read. It is a software to test.

A year after HMOA's adoption, in 2002, Autodesk arrived. It bought Revit Technology Corporation for 133 million dollars, and from there the story changed scale — it stopped being the product of an independent startup and became part of a software giant.

But that part of the story — the dynamics of the acquisition, the cannibalization with AutoCAD, the slow global adoption that followed — I have already told, with all the space it deserves, in the article on Eastman. If you haven't read it, you can find it here.

What interests this article is what happens before that 2002 — and it is already all told. It only remains to close the circle.

From then to today

Let's return for a moment to 2000: the promise of Revit, declared in the name itself, was revise instantly — a change that propagates instantly through every view of the model, without you having to do anything to make it happen. At the time, that promise concerned an architect sitting in front of a screen, moving a wall and watching everything else in the project update by itself.

Today, half a century after Eastman's intuition and twenty-five years after that first Revit 1.0, the same philosophy is spreading to a different actor. With the MCP integration announced for Revit 2027, the model does not just update while you watch it — it becomes something that even an artificial intelligence system can observe and query in real time. I will not go into the technical detail here — I have already talked about it in Inside the Machine — Episode 02 — but the point I am interested in closing is another.

The instantaneous change of 2000 and the observable real-time model of 2026 are not two different eras. They are the same idea, carried forward step by step, in different hands — from Eastman theorizing it on paper in '75, to Ingram trying with the wrong hardware in '86, to Raiz and Jungreis finally finding a way to make it accessible to everyone in 2000.

Each generation in this story solved the same problem with the tools it had at its disposal: ensuring that the model stops being a static drawing and becomes something alive. The question that remains open, today, is no longer whether a model can update itself. It is who — or what — will be observing it, the next time it happens.