Audio article narrated by OpenAI
This article is the second in the column called Change Order.
This operates as a separate monthly column on Last Week in ConTech, which readers can opt in to receive here.
This conversation is with Joachim Viktil CEO of Reope.
About Joachim Viktil
Joachim Viktil is CEO of Reope, an Oslo team of about 12 architects who code, building bespoke automation and Revit and Rhino tooling for architecture and engineering firms including KPF, BIG, and Heatherwick Studio. He is an engineer by training and spent around 12 years at Ramboll in design management, then as a department head and a director across three countries, before an MBA and a short role at an AI startup outside the built environment that ended when its investors replaced him. He joined Reope, founded in 2017 by Håvard Vasshaug, as its CEO in 2024. He has spoken about the importance of Human Judgment in a world of AI at Autodesk University and will be on stage at the AEC Tech Symposium in New York this year to talk about Deterministic AI in AEC.
—
“It’s not like each hour we spend is the same unit of value. If I’ve encountered this problem a few times before, I can spend five hours delivering immense value. If it’s my first time, maybe I need a full week and the value is still immense, but the time is eight times as much.” Joachim Viktil
—
The perversity
Finish the model. Set the parameters. Press run.
Three thousand drawings output, views created, elements tagged and a fortnight of work done in seconds.
Those are the tools Jochim’s team builds.
“The two weeks saved time; if you’re on a time and materials contract, the outcome is that you have fewer hours on the project, slash revenue.”
The problem is that while you did the work better, you invoiced less for it. In theory, the freed fortnight goes straight back into the pipeline. A faster firm can sell more jobs, but only if there are more jobs in the pipeline. The freed capacity still needs to be sold.
That means that as the firm gets faster, it can get poorer, as time and materials have always paid for duration over results.
McKinsey warned this year that “AI will reduce the amount of labor hours needed in an industry that often charges clients based on time spent working” with value accruing to whoever holds proprietary project data, the workflows where decisions get made, and “the ability to charge for outcomes rather than hours.”
It’s not a new thought.
Clients have always cared about the outcome, but we billed them for the journey. It’s an insight Joachim saw first-hand and he realised:
“Billing by the hour doesn’t make any sense at all.”
But when asked about whether their commercial model is ready to move towards outcome-based pricing, he states:
“Outcome-based is, I think, quite hard to do. I haven’t quite wrapped my head around how you could actually truly do outcome-based.”
For those of us in the industry, we are now balancing a fine line. On one side is the erosion of the traditional billable model. On the other are outcome-based or fixed-price contracts which, done incorrectly, drastically increase risk by capping upside while leaving potentially unlimited downside.
This is the story of how Joachim found a way to thread the needle with Reope.
The perversity
Finish the model. Set the parameters. Press run.
Three thousand drawings output, views created, elements tagged and a fortnight of work done in seconds.
Those are the tools Jochim’s team builds.
The two weeks saved time; if you’re on a time and material contract, the outcome is that you have fewer hours on the project, slash revenue.
The problem is that while you did the work better, you invoiced less for it. In theory, the freed fortnight goes straight back into the pipeline. A faster firm can sell more jobs, but only if there are more jobs in the pipeline. The freed capacity still needs to be sold.
That means that as the firm gets faster, it can get poorer, as time and materials have always paid for duration over results.
McKinsey warned this year that “AI will reduce the amount of labor hours needed in an industry that often charges clients based on time spent working” with value accruing to whoever holds proprietary project data, the workflows where decisions get made, and “the ability to charge for outcomes rather than hours.”
It’s not a new thought.
Clients have always cared about the outcome, but we billed them for the journey. It’s an insight Joachim saw first-hand and he realised:
Billing by the hour doesn’t make any sense at all.
But when asked about whether their commercial model is ready to move towards outcome-based pricing, he states:
Outcome-based is, I think, quite hard to do. I haven’t quite wrapped my head around how you could actually truly do outcome-based.
For those of us in the industry, we are now balancing a fine line. On one side is the erosion of the traditional billable model. On the other are outcome-based or fixed-price contracts which, done incorrectly, drastically increase risk by capping upside while leaving potentially unlimited downside.
This is the story of how Joachim found a way to thread the needle with Reope.
The lights
Twelve years ago, Joachim was working out of a project office in a large historic building. The engineers and architects were like oil and water, each segregated on different sides of the floor.
Walking through the engineering side, every light was on and everyone sat at their screens. On the architecture side, everyone was on their screens but all the lights were off. He asked why are you sitting in the dark?
What are you talking about? I’m sitting here in the daylight.
Same building, same floor, same hour, two irreconcilable descriptions of the same room. He realised it wasn’t that one side was wrong; it’s that “this is a different mindset. It’s completely different.”
Joachim is an engineer, starting in structures and then moving into design management, working twelve years at a large consultancy as it grew from 12,000 to 18,000 employees and finishing as a director across three countries.
Then he joined Reope: a shop of architects who code, founded by Håvard Vasshaug. He describes that culture as
a little gritty, trying to solve things in a quick, efficient way, smart, not too much process and bureaucracy.
He came in as the CEO from outside to run a company he didn’t found — Håvard Vasshaug, the founder, had already left for Anker, staying on only as chairperson of the Reope board.
The reversal
When he joined, his belief about impact was to grow headcount. Get to 150 people, build a big organisation and work on big jobs. It wasn’t naivety; it was a read of how the industry operated, where capacity and revenue were interlinked. But that changed.
But now I’m more like, wait. I don’t need 150 people to do great work. I need, you know, 15 to 20 people maybe. If their talent density is really high.
The condition is that the 20 people must be the right ones, helping each other with AI-assisted coding supporting them. His formulation of the upside is non-linear: “the right people can have 200 people impact. It also means that with the right support structures, we don’t need to linearly scale the number of people designing and engineering.”
This now begs a question on commercial models. If a tenth of the people can produce the same output, selling quantity of hours is no longer linked to the quantity of output.
Before, more people meant more impact, meant more income and revenue, meant larger absolute profits. But now we can maybe disconnect this link between hours we spend and the value we contribute.
That led to experimentation with pricing models, but he realised that before he did, he first had to ensure he had the best 20 people, because AI doesn’t replace experience.
It isn’t the AI
Some of his team have spent a decade automating workflows, developing Dynamo, Grasshopper, C# and Python plugins for Revit and Rhino. What accumulates over that time is the accident log: the things that break, configurations that interfere, failures that reproduce nowhere else.
There’s all these operational experience things that you get over the years.
That’s Joachim’s answer to the argument that everyone can code now.
If you picked up Claude today and you created a Revit add-in, that’s fairly simple. Many people could do that. It doesn’t automatically then give you the knowledge and experience of, okay, how will this Revit add-in perform over many years and how will it serve the needs of many users, and how do we scale, distribute it.
His most interesting finding was the growing number of people applying to leave in-house teams and join Reope.
A lot of them find themselves fairly isolated. You’re one of the one to three people who work on making tools for other colleagues. And then you’re not necessarily the most important person in that organisation.
The person building the tools is, in his words, “a little bit on the support sidelines.” The team spends its week adding functionality or operating the tool for people with neither the time nor skill to run it themselves. The pain is real and demand is there, but the perceived value is low.
Reope’s structure is the antithesis of that.
Everyone codes in design and BIM software every day. The Slack channels are busy, and there are internal rituals around getting better at making design and BIM software. People don’t feel alone. Plus, there’s a density of talent, including Dimitar Venkov, the author of Spring Nodes, one of the most used Dynamo packages in the world. People apply saying they have followed his work for years.
Even if we’re only 12 people, you will struggle to find a similar group of 12 people with the same shared context and history.
This inverts the wisdom about in-house tooling. A firm with 20,000 engineers may have 50 people doing similar work, scattered across regions and who haven’t worked together for long. Their remit is mostly process and platform, while Reope, in his description, focuses on “more implementation.”
That talent density and shared context provide the team with an edge. Salar al Khafaji, the founder of Monumental, a robotic bricklaying company, said in his self-description that it “wasn’t really a SaaS company”; the money simply followed embedded expertise solving a specific problem.
Reope has no platform to sell. What it has is twelve people who have spent years building and rebuilding tools and can redeploy whatever is needed to the next client without requiring a roadmap.
What he sells instead
If we go back to the case of 3,000 drawings output in seconds, what if 20% of them are wrong?
With the state of AI tools today, this is likely. Someone still has to go back and fix them by hand.
It’s faster than the old workflow, but the result is mixed: the drawings exist, yet a fifth of them are wrong, so no one can say cleanly whether the outcome was actually delivered. That’s the real problem — quality attribution is not a pricing detail; it is the precondition for pricing at all. This creates a challenge for outcome-based pricing. It requires an immediate, automated “verification event” (e.g., a ticket resolved or a test passed). AEC rarely has this moment.
Instead, an architect or engineer signs off on a coordinated set of documents, and whether those documents were actually correct may only become clear much later, when the project is built, approved, or something goes wrong. A signature transfers responsibility; it does not prove the work is correct.
The second problem in this scenario is one of ‘casual distance.’
The outcome that architects are selling to developers is that their drawings will get approved by the council, at which point the land is worth considerably more. This is several steps removed from software execution and no software vendor can conclusively demonstrate that their tool makes approval more likely.
And the third is a broader problem called the Sequence Trap.
While generative AI is providing value to businesses, firms don’t know how to measure the improvement because their existing KPIs don’t track it. If AI cuts a task from 10 hours to 2, the firm has released 8 hours of capacity. But unless those 8 hours turn into additional billable work, revenue, or some other measurable outcome, they largely disappear from the P&L. The productivity gain is real, but the economic value is difficult to attribute.
And to negotiate an outcome-based fee, firms must prove historical value baselines. But deploying automated tools under legacy hourly contracts shrinks revenue before a new pricing agreement can be validated.
The industry advice offered by McKinsey, which is to update commercial models in parallel with AI deployment rather than after, as “waiting until clients can clearly see productivity gains may hinder pricing renegotiation,” you have a sequence that eats itself. You have to reprice before you can prove the gain, and you cannot prove the gain without having repriced.
So Joachim follows a different approach. He prices the relationship.
Most of Reope’s work runs on retainers: a fixed monthly fee, “a little bit like a Netflix subscription”, cancellable on a month’s notice. There are three tiers and buys; a bigger one adds those; the largest one means, in his words, “we move really fast.” There’s no measurable outcome as in this industry, often there isn’t.
The tiers therefore aren’t a pricing ladder. They are an instrument, differentiated by speed, capacity, and access.
It’s not just, can you afford working with us or not? It’s more, which part of each package is valuable to you.
When a client says their budget is the middle package but wants one specific thing pulled down from the large one, it tells him that, for this firm at this moment, speed is worth paying for. This is where outcome pricing becomes diagnostic. It forces you to understand what the customer actually values, rather than simply pricing the work based on how much effort it takes to deliver. This decouples revenue from hours without needing unmeasurable outcome metrics.
What he protects
If you cannot charge for the outcome, you defend the things that stay valuable whether or not the fee ever changes. And there’s three of them:
1. The ability to fix code by his own hand.
The systems stay modular, he says, “so that we don’t have to rely on AI — if something happens in one job, we can go in and fix it there.”
If you have Claude set up to just go in and change your whole codebase all the time, you end up with a very connected system that’s really hard to work on without an AI assistant.
It’s important because token prices are currently discounted.
Maybe we’ll have cheap tokens for another five, ten years. But it might also all come crashing down and the tokens are 10 times as expensive.
If your entire design capability runs through a language model talking to Revit over an MCP, and tokens get expensive, are you closing the business, or do you have another way to get the work done?
Other commentators like Dylan Patel would disagree: demand for frontier tokens is near-unbounded and the binding constraint is supply, not price — nobody wants the cheap old model.
He’s probably right about the market but he’s answering a different question. Joachim isn’t hedging the token bill; he’s hedging dependency. The bill has its own evidence regardless: in the same Australian session, an agentic pilot budgeted at eight cents per customer interaction but reached $1.60 once the agents started talking to each other. This meant a $16,000 projection became $320,000 of unforecast spend.
2. Distribution Infrastructure
AI-assisted coding makes the creating half of software close to free. Anyone can vibe-code a tool.
What is harder is paying customers and keeping the tool alive once they start using it. Practitioner-built tools are multiplying faster than firms can absorb them and capturing one small solution is a small part of the job. Almost no one builds the connective plumbing and deployment infrastructure, such as maintaining background installers, licensing obfuscation, and modular systems that hedge against rising token costs. Reope builds and maintains this across every client:
If you discover that this button says run and you wanted it to say done, we can change the code and redeploy. So next time you open Revit, it’s changed.
Making an add-in or some software is not valuable in and of itself. You have to actually have a user use it for it to be valuable.
3. Intellectual Property
When employees leave companies, they often take their scripts with them. It happened with one of their clients when they built a genuinely beautiful PyRevit toolbar. After an employee left, their competitor quickly had a similarly beautiful toolbar.
It’s super easy to take your Python scripts and just download that. Anyone can do it with no technical insight. And it’s sometimes hard to detect as well.
They moved to C# with proper licensing obfuscation, so a departing employee can’t reuse tools they built while employed.
The layer no one sells you
Reope has written MCPs for ~30 of its own Revit add-ins. When building these, architecture matters: each shouldn’t have redundant commands, and they should be built efficiently.
The architecture he sees is a set of specialised agents, one per tool: Revit, Rhino, Grasshopper and Dynamo, each good at creating geometry or documenting. Those are commodities. The orchestration above them is not.
At some level, you need a coordinating agent to kind of talk to all these specialised agents. Because the coordinating agent knows the context for your firm, for your project, that none of these other agents is fully aware of.
This coordinating agent is not something that you’ll just get from any of your software suppliers. It’s something that you have to develop or build yourself.
His reason has nothing to do with technical capability: nobody is going to hand a vendor every proprietary system they run and accept a personal agent back.
I don’t really think people trust the system that much.
In June I wrote “The layer nobody owns yet”, arguing that the most sustainable position in the transition to AI belongs neither to the vendor nor to the client, but to whoever controls the integration layer in between.
Joachim has been staffing the role since before it had a name. McKinsey QuantumBlack reached the same conclusion from the CFO’s side that same month, concluding that internal development now belongs in only three places, with the first being “proprietary ‘glue layers’ that connect enterprise-specific data and workflows”.
What’s needed is the harness. Not a code editor but everything wrapped around the model: the system prompts, tool wrappers, retry policies, the rules for when an agent keeps going versus stops and asks. They help connect a generic AI model to firm-specific design standards, local codes, and software APIs.
The example Joachim points to is Cursor:
Cursor is a harness. It’s just enabling you to use an LLM to code.
Set that fuller version up well, test it, build the feedback loops, and you can plug in Sonnet 5 or Opus 5 and then swap in whatever comes next. Francisco Maranchello reached the same conclusion from the services side: the model is largely interchangeable, and the durable advantage sits in the harness.
It’s a system they demonstrated at the team’s festival in Athens in May: a short design brief, then a meeting transcribed and turned into tasks by Gemini. The south column has to move 150mm north; floors and internal walls added. It was handed off to Claude, which used an MCP to make changes in Revit. The internal walls came out wrong and what fixed it wasn’t a new prompt. A human in the loop provided a quick hand sketch.
The example highlighted how small, talent-dense teams (15 to 20 people) act as this essential human oversight layer, refining and repairing edge cases. The lines of this human-AI layer are still being defined.
Some decisions need “these two people… to go out and figure out what we do here.” No agent touches those. Others aren’t decisions at all: every door is seven millimetres too short, and having a human open the family editor to fix each one “is a waste of human capacity”.
No bench
When you have 20 people aiming to produce the output of 200, you can’t have slack anywhere. People come to work, and it is “an alliance, then a commitment.” Joachim’s focused on building mutually beneficial relationships for two years or ten, not for life. He understands that career goals change, and for Reope, if two people leave in a quarter, it doesn’t leave a staffing gap; they take capability out the door with them. It’s better to build a good team and alumni around it.
Underneath it all sits what he is actually aiming for: ending the waste of talent in the industry.
Someone spends five years in education and five more learning the job and then, “ten years in, they’re still clicking around in the software 80% of the day.” He’s right that it’s a waste.
But he’s also honest that the competition for the tool that ends it “might be a very affordable intern who could do it manually.” That intern represents exactly the 500 hours of repetitive work he wants to abolish.
And that raises a harder question. A junior does not just perform this work; they learn from it. The repetitive tasks that Reope wants to remove are often where a junior develops the judgement needed to become a senior. If AI removes those tasks, the industry needs a new way to develop that judgement.