.png)
"OaaS" and "Cloud Manufacturing" - New business models, and can they work in AEC-tech? Pt. 3
Here we are for the last article in my 3-part series on new business models in AEC-Tech. In case you missed the first two articles, you can read Part 1 (Vertical AI roll-ups) here and Part 2 (Franchising and "Business-in-a-box") here.
In this last article, I'm going to cover "OaaS" (Outcome-as-a-service) and "Cloud Manufacturing". My colleagues Shub and Patric have already talked and written extensively about both (for example, here: 1, 2, 3, 4). Hence, while chances are you're already well familiar with both concepts, for the sake of completeness of this 3-part series, allow me to share those concepts once again with you.
Let's dive in!
Outcome-as-a-service explained
Well.. I'd say the name is self-explanatory. Outcome-as-a-service is a business model by which you're not selling a product (software -> SaaS; robotics -> RaaS; etc.), but rather an outcome.
But what counts as an outcome? It's a broad concept that encompasses any service or result customers (GCs, architects, etc.) are already buying, whether that's something "physical" like building a structure or manufacturing parts, or something more "digital"/"knowledge-based" like creating architectural designs or running engineering analysis.
Therefore, the idea here is that you're not building a technology company that sells the technology, but rather you're building an outcome delivery company that leverages proprietary technology as the tool/enabler to achieve guaranteed results. This means that OaaS functions as a delivery mechanism for technology that customers might otherwise not adopt directly for one reason or another (e.g., because of too high tech risk, they lack internal resources and are better off outsourcing the function, etc.). This creates an interesting dynamic by which technology penetrates the market not through direct adoption, but through embedded services, and by which customers can indirectly access the efficiency gains of automation without having to redesign their organizational structure around new workflows or tech.
In fact, one of the most compelling aspects of the OaaS model is how it handles risk. Traditional software or hardware purchases push all the (performance) risk onto the customers: customers buy the tool, and if it doesn't solve their problem well enough or there are issues, that's (mostly) their problem to figure out (obviously, there are implications for the startup developing the tech too). This risk component, particularly for disruptive hardware, has always been problematic in AEC, where the stakes are high and margins are thin, leading to some skepticism towards the adoption of new tech - in particular for hardware, for which the risk of investing in expensive, novel, unproven tech is just too high. However, OaaS providers assume this performance risk directly.
Let's take an example. When a contractor purchases a bricklaying robot (a very novel technology in the industry), they're betting that they can integrate it into their workflows, train their crews to work alongside it, maintain it properly, and achieve consistent productivity gains that justify the substantial capital investment. If the robot breaks down on job sites, requires specialized technicians that aren't readily available, struggles with the variability of real-world construction conditions, etc., the contractor has made an expensive mistake that could significantly impact their credibility and cash flow. However, if the robotics startup instead approaches the same contractor offering a bricklaying subcontracting service (e.g., by guaranteeing to deliver completed walls at a fixed price per brick laid), the technology risk shifts entirely to the startup: if their robot fails to perform, it's the company's own reputation and P&L that suffer, not the contractor's (or not, at least, to the same extent).
As you understand, for customers, this risk transfer is enormously valuable: you are presenting clients with familiar, outcome-focused value propositions. The technology becomes invisible to the end customer. What ultimately matters to the customer is that the outcome is better, faster, or more reliable (through technology) than what they could achieve by buying the service from someone else on the market (or doing it themselves).
Of course, delivering "physical" outcomes is exponentially more complex than delivering "digital" ones: you're committing to managing supply chains, coordinating with other trades, dealing with weather conditions, and handling all the unpredictable challenges that come with construction sites. That's why you'll want to focus on controlled and repeatable (-> standardizable) processes, as it's just too hard to guarantee outcomes if your delivery process is inherently variable and dependent on factors outside your control (since it's way harder to codify them in your tech).
Breaking out of the IT budget trap: selling what customers already buy
Now, why would (prospective) entrepreneurs building in AEC want to pursue an OaaS model?
It's fairly simple: buyer readiness. Instead of convincing prospects that your tech is better than the alternatives or new and disruptive, you're demonstrating that you can solve their specific problems more effectively than their current vendors or that they could achieve it themselves by insourcing the task. The proof is in the delivered outcome, not in feature comparisons or tech ROI promises. I've hinted at this point in a previous article with a focus on the Indian market, in which, for example, pure software solutions struggle to gain momentum (for many reasons).
The caveat, therefore, is that a critical success factor for any OaaS model is that it must target an outcome customers are already buying: you have to identify an existing, significant, and specific line item on you customers' P&L statement and deliver that more efficiently, reliably, and/or with higher quality. Given the nature of the AEC space, my readers would probably know that the industry is an exceptionally fertile ground for this approach and caveat. Due to the immense complexity, long duration, and specialized nature of projects, the entire industry is built on a foundation of subcontracting and outsourcing. For example, very few general contractors self-perform every task, but they are rather experts at orchestrating a network of specialists who are each paid for a specific outcome. This deeply ingrained procurement behavior means that the market is already primed to buy outcomes (-> governance and procurement processes are already in place).
This reality, in turn, has a profound implication for value capture.
Let's take an example of a SaaS ConTech startup: this company will compete with a plethora of other software solutions for the notoriously small IT budget, which in construction often accounts for a mere 1−3% of total project costs. An OaaS provider, by contrast, isn't targeting the IT budget at all. By selling an outcome, they are competing for the much larger budgets allocated to labor, materials, and subcontracted services (including design, engineering, etc.), which constitute the vast majority of project expenses.
This also means that OaaS completely changes the basis of competition. Traditional software competition focuses on features, user experience, and price. Service competition typically centers on expertise, availability, reliability, quality, and cost. Therefore, OaaS competition is fundamentally about outcome quality, reliability, and cost. Customers don't care what tech you use internally or how you organize your service delivery. They care about whether you can consistently deliver the promised results at the agreed-upon price point. Which also means that the most successful OaaS providers are those who combine deep domain expertise with sophisticated technological capabilities. Pure software companies don't guarantee complex outcomes (as previously said: it's up to the buyer of the tech to use it to deliver an outcome, whether the tech works perfectly or not), while traditional service providers lack the technological capabilities to deliver outcomes efficiently, at scale, and at the same price point of a tech-enabled player.
OaaS essentially takes the technological sophistication of software companies and the outcome accountability of service providers, then packages this combination in a way that aligns with how the industry already buys services: familiar procurement processes, predictable costs, and guaranteed results.
What it takes to win in OaaS
Most founders know the answer already: trust and track record. Trust remains the ultimate currency in the AEC industry, and OaaS models make it even more critical.
When customers are paying for guaranteed outcomes rather than just access to tools, they need absolute confidence in your ability to deliver, which places enormous importance on building a track record, customer relationships, and operational consistency. It's about selling certainty in an industry built on uncertainty. Clearly, building this trust requires a fundamentally different approach to customer acquisition and retention than SaaS businesses typically employ. Pro tip: early in your journey, it generally makes sense to keep a low profile and brand yourself like a traditional industry player, not a venture-backed tech startup - your AEC customers want reliable partners who understand their business and speak their language.
A rookie mistake an entrepreneur building an OaaS company might make is, therefore, assuming that they can operate with the same lower-touch, scalable models that work in software. The reality is that AEC customers need extensive human interaction and relationship building before they'll trust you with critical project outcomes. For example, when a general contractor commits to using your structural optimization service, they're betting their project schedule and potentially their reputation on your ability to deliver: this level of trust requires constant communication, transparency, and human touchpoints. The high-touch requirement extends to how you handle problems when they inevitably arise. In traditional software, customers might accept occasional bugs or service interruptions. In OaaS, any failure to deliver promised outcomes directly impacts customer projects and can cause significant financial damage. That's why you'll always have some humans in the loop in your service delivery.
The challenge of establishing credibility in a risk-averse industry is therefore significant. At the risk of being repetitive: AEC decision-makers are naturally skeptical of new approaches because project failures can be catastrophic. This means that your first few customer engagements are disproportionately important to your long-term success, and that the pilot project becomes a natural selling mechanism in this context (propose small-scale paid trials that demonstrate your ability to deliver quickly and tangibly, then scale). Early customers become investments in building market credibility: they become referenceable successes, case studies that demonstrate your capabilities and ability to deliver on your promises. In an industry where word-of-mouth and peer recommendations drive purchasing decisions, these early success stories become your most valuable marketing assets.
To summarize: you need high-touch relationships, extensive proof points, and pilot projects to demonstrate capabilities before customers will commit to larger engagements. It's harder, but it pays dividends long term: customers who have experienced reliable outcome delivery are likely to become advocates for your service and are often willing to expand their relationship to include additional outcomes or larger projects. What I am saying is not theoretical: I have heard customers of some of our OaaS portco companies genuinely rave about them, and initiating powerful referral chains (which come with pre-established trust, significantly shortening sales cycles). Ultimately, I believe that this track record will be the strongest long-term moat a company can build: the loss of a trusted relationship is a real switching cost!
Now, let's answer a key question: are OaaS companies not-so-attractive (especially when compared to SaaS) due to their low, service-like margins?
Unit economics and other operational considerations
If you're thinking that an OaaS company, being a service company, operates with traditional service margins, you are mistaken: I'm not interested in OaaS models that deliver unit economics similar to their non-tech-enabled competitors either. Indeed, the entire premise of technology-driven outcome delivery hinges on achieving dramatically superior margins through automation, productivity gains, and operational efficiency: technology should enable you to deliver outcomes at costs dramatically lower than traditional providers while charging prices that reflect the value delivered rather than the resources consumed. This spread between "value-based" pricing and technology-enabled delivery costs creates the margin profile (as well as the scalability that technology brings in inherently hard-to-scale, human-dependent businesses) that makes OaaS compelling as a venture-backable opportunity.
Consider the economics of traditional bricklaying versus an automated bricklaying company. A conventional masonry crew operates within well-established productivity constraints: skilled masons typically lay 300-500 bricks per day, requiring wages, benefits, and overhead costs that create predictable but fundamentally limited unit economics. The labor intensity means that scaling requires proportionally more skilled workers, and productivity gains are incremental at best. An OaaS provider using robotics can completely restructure these economics: when robots can lay more bricks than humans (say, 1500 per shift) while working 24/7 and having a one-time fixed cost comparable to a yearly salary of a human bricklayer, you understand that the productivity is an order of magnitude higher and the margin implications are significant. Projects that might be marginally profitable with traditional labor become highly attractive, since the OaaS startup captures this efficiency gain as margin expansion rather than passing it entirely to customers as cost reduction. Most importantly, the automated approach transforms the business from a labor-scaling challenge into a capital-deployment opportunity: instead of hiring and training more masons to grow capacity, the provider deploys additional robotic systems at a one-time fixed cost.
Mind you: I don't necessarily expect margins for an early-stage OaaS company to be better than its traditional peers from day one, particularly for "physical" outcomes (and specifically those involving robotics). Early projects subsidize technology development and process refinement, but as automation reliability improves and human supervision/human-in-the-loop requirements decrease (e.g., in the case of robotics, this means a single operator can handle multiple robots, operating with almost zero issues, simultaneously), the unit economics shift dramatically. The investment opportunity hinges on underwriting a credible path from the same/lower margins to eventual margin profiles that dwarf traditional alternatives. Year-one margins most likely won't be attractive. The question is whether the technology roadmap and market dynamics support achieving 60-70% (and higher!) gross margins once automation/tech reaches full capability.
That said, despite a fundamental technological foundation, successful OaaS companies are still operations businesses (particularly for "physical" outcomes). OaaS founders need to thrive on operational complexity rather than viewing it as a necessary evil. You're managing complex service delivery across multiple dimensions simultaneously: technology systems must function reliably under real-world conditions, human processes must scale while maintaining quality standards, supplier relationships (when needed, e.g. for "physical" outcomes) must deliver consistent inputs. Founders must understand how to optimize automated systems while managing human teams, build software platforms and/or hardware products while ensuring physical or digital outcomes meet specifications, and scale processes without sacrificing the reliability that customers depend on. The investment in operational excellence should become a significant focus (e.g., over just technical capabilities): the companies that can deliver outcomes predictably and efficiently will reap the most benefits.
Additionally, as you understand, an OaaS business delivering "physical" outcomes is generally more WC intensive compared to your traditional SaaS company: you need cash for materials, hardware, labor (human in the loop, etc.), and extending credit to customers. Unlike software, where additional users create minimal marginal costs, additional physical OaaS customers generally require proportional increases in operational capabilities and capital investment (e.g., investing in new hardware). This means you need sufficient capital reserves to bridge the gap between outcome delivery costs and customer payments. Even for digital outcomes, the scalability profile differs significantly from pure SaaS companies, as you still require human resources to manage outcome delivery, maintain customer touchpoints, and ensure quality control throughout the service process.
At the same time, the other side of the coin is that the most compelling aspect of well-structured OaaS models is their potential for earlier profitability compared to software businesses. While SaaS companies often burn cash for years building market share, successful OaaS providers can achieve positive unit economics and EBITDA (and even PBT) profitability relatively quickly by directly addressing major cost centers in customer operations. The key is building delivery systems robust enough to provide outcomes consistently and efficiently. This often requires significant upfront investments (tech, processes, etc), but once these systems are operational, the marginal cost of serving additional customers can remain manageable while value capture stays high, especially when your technology creates genuine productivity advantages over traditional alternatives.
Alright, enough with the theory. Let's look at a couple of examples of ConTech ventures operating through the OaaS model.
Early movers in OaaS: some examples
The first company, Monumental, represents the most straightforward interpretation of physical OaaS, and is an example I've mentioned multiple times in the article (I'm biased: it's a portfolio company). Rather than selling bricklaying robots to construction companies, they position themselves as a subcontractor who delivers completed walls. That's because buying built brick walls is an outcome already purchased as-is in the industry (or better: bricklaying is, paid by brick laid -> "piecework"). The operational complexity behind this simple value proposition is immense. Monumental's robots must navigate construction sites, adapt to varying conditions, and coordinate multiple units simultaneously while maintaining quality standards that match skilled human masons. Currently, their robots lay bricks at speeds comparable to human workers, but the company targets significant productivity improvements as the technology matures. The real advantage lies in their output scalability: deploying multiple robotic units simultaneously offers capacity expansion that's nearly impossible with scarce human labor. For construction clients, this model eliminates the substantial risks of adopting expensive, unproven robotics technology. If the technology fails to perform, it's Monumental's problem to solve: clients simply contract for wall construction and receive the outcome, with all technological complexity abstracted away.
SiteHub addresses instead a different but equally challenging operational domain: construction site logistics and management. They are the partner that actively steps into the construction site and assumes responsibility for everything that moves, the "client's man on site" managing the complex coordination tasks that typically fall between different contractors and create inefficiencies. SiteHub effectively replaces several traditional budget line items and processes within construction companies: instead of ad-hoc logistics management where different contractors handle materials independently, SiteHub centralizes and professionalizes the entire process. They eliminate the need for construction workers to spend valuable time on material handling, replace manual paper-based documentation systems with automated digital tracking, and consolidate separate waste management contracts into their integrated service. The company also takes over individual supplier coordination, creating a single point of contact for all deliveries and materials management. Perhaps most importantly in today's regulatory environment, they replace manual compliance reporting with automated CO2 measurement and sustainability documentation that meets emerging EU requirements. SiteHub's approach to technology risk exemplifies OaaS principles. Rather than requiring construction companies to implement and manage new systems, SiteHub handles all technology complexity through its integrated platform. They provide proprietary hardware, including sensors, cameras, and data towers for real-time monitoring, while their software platform integrates with existing construction technologies. Therefore, clients interact with outcomes and services rather than managing technology directly: construction companies don't need to worry about system integration, data management, or technical maintenance; they simply receive the benefits of optimized logistics and automated compliance reporting.
These represent just two examples from a growing ecosystem of OaaS companies. While, for obvious reasons, I won't share other emerging/stealthy ones, we're increasingly seeing founders embrace this tech-first service model (many of those are "digital" outcomes companies) with profitability as a core design principle from day one, which is genuinely exciting to witness.
Now, before we bring this home, I thought it was worth discussing "Cloud Manufacturing" in this article, too. I won't get into the nitty-gritty of it, hence I highly recommend you check the Practical Nerds and/or Bricks, Bucks & Bytes episodes on the topic for more details.
That said, let's quickly go through the concept!
Cloud manufacturing: OaaS meets industrial production
In a way, "Cloud Manufacturing" could be considered as a subset of OaaS: the outcome here is a finished product, delivered at the right time and at the right place (and potentially, with a service component attached to it, e.g. installation), manufactured across a distributed network of manufacturers that the company delivering it (supplier of record) doesn't own. This model demonstrates the same fundamental principle that drives all successful OaaS ventures: capturing value by guaranteeing outcomes while orchestrating complex operations (and networks, in this case) behind the scenes. Many of our portcos (such as Infra.Market, Metalbook, GreenFortune Windows and Doors) are successfully operating through this model.
A word of caution: some might confuse (managed) marketplaces with cloud manufacturing. Big mistake!
The cloud manufacturing model represents something far more sophisticated than just another B2B marketplace trying to connect buyers and sellers. The model works by providing manufacturers with predictable revenue streams (a huge value to them) and therefore securing guaranteed capacity from them at preferential prices, centralizing all the complex operational overhead through software, and maintaining an almost obsessive focus on maximizing existing asset utilization.
Why does it make sense? In building materials manufacturing, the landscape consists mostly of small to medium companies (talking with my Indian hat on here; this does not hold true for products in most western economies) that are, for the most part, un-branded, under-discovered (supply chain are notoriously "obscure" in that market), and under-utilized (it's key for this model to work): geographic constraints keep them regional and most critically, they suffer from very risky demand swings and production unpredictability. Cloud manufacturing platforms systematically dismantle these problems by providing visibility into future demand and assured utilization by aggregating projects across regions and customers. That said, the process generally goes through stages. At the beginning, a cloud manufacturer most likely simply aggregates manufacturers who have spare capacity. As it expands in scale, however, it can start securing partial capacity guarantees (e.g. 20-30%) at better rates; with time, it expands that further and further: the endgame sees the platform essentially becoming the primary customer for their manufacturers, contracting up to their entire production capacity. This complete control unlocks access to preferential pricing and favorable terms (essentially, "cost+").
Moreover, the real play here is the private label one, which still remains surprisingly underdeveloped despite its obvious potential. Indeed, private labeling becomes the ultimate trust-building mechanism in this model. By partnering with these unbranded, underutilized manufacturers, cloud manufacturing platforms can create their own brand that becomes synonymous with reliability, quality, and fair pricing. Mind you: it goes beyond just taking some fancier packaging and your nice logo and putting it on someone else's product. What you are doing here is standardizing quality across multiple manufacturers, creating predictable customer experiences, and building the trust that's essential for securing large enterprise contracts (which your suppliers are unable to do). The sooner platforms establish their private label capabilities, the better. In essence, the brand becomes the guarantee, transforming anonymous, potentially unreliable manufacturers into a unified, trustworthy supply network that customers can confidently depend on for their critical building material needs. A strong brand also unlocks higher multiples at exit.
Last point (there would be more, but I promised to keep it short): since the model works by maximizing the utilization of the supply side, it follows that the supplier strategy differs radically from typical marketplaces. Instead of maximizing the supply base, cloud manufacturing platforms should concentrate on a small, carefully selected supplier base. You want enough suppliers to avoid concentration risk but few enough that your volume meaningfully impacts each one's business. The goal is to direct sufficient business to substantially improve their utilization rates, creating a mutually beneficial relationship where utilization guarantees translate into favorable pricing and terms.
To summarize: the value creation comes from solving fundamental efficiency problems that plague both sides of the market. Manufacturers get more consistent utilization, access to projects they couldn't bid independently, and peace of mind with the freedom to focus exclusively on production rather than customer acquisition. Customers instead benefit from needing to manage a single, reliable supplier: the brand promise centers on delivery predictability and quality consistency.
Now, I know I promised this would be the last section of the article... But actually, there is a variation of the cloud manufacturing model worth discussing, so bear with me for a little more.
Cloud... "(sub)contracting"?
The same principles that make cloud manufacturing successful apply naturally to service delivery in construction, creating what we might call "cloud (sub)contracting": platforms that deliver project outcomes while orchestrating networks of specialized contractors to deliver them.
Let's take an example. A commercial renovation might need electrical work, plumbing modifications, HVAC adjustments, flooring installation, painting, and specialized equipment installation. Each trade operates on different schedules, follows different quality standards, uses different communication preferences, and requires different coordination approaches. Managing these relationships while maintaining accountability for overall project outcomes creates substantial overhead and risk. Project delays compound across trades, quality issues become finger-pointing exercises, and change orders multiply as coordination problems emerge. Cloud subcontracting platforms solve this by assuming complete responsibility for project delivery while managing the contractor network transparently (and through technology). Customers contract for specific outcomes: a completed renovation delivered by a certain date, a functioning system installation with defined performance parameters, etc., while the platform handles all contractor selection, scheduling coordination, quality control, and problem resolution.
Our portco MyGenie operates through this model. MyGenie, a pre-seed investment we led, serves India's booming retail industry by offering a turnkey solution for retail fit-out projects, solving for all pain points and obstacles getting in the way of retail brands’ expansion plans, utilizing its AI-powered tools to enhance the efficiency and quality of their delivered projects. MyGenie’s system analyzes historical data to identify issues and makes recommendations to fix them, resulting in efficient project management and cost-effectiveness. But their core business is still project execution, what they are selling is an outcome: a fit-out retail store/gym/restaurant/etc. delivered on time (and in advance, even!) and to specification. They do so asset-light through a network of dedicated and specialized contractors (there are many nuances under the hood here, but I'm keeping it short) that were previously underutilized, hard to find, and difficult to manage, in a true "cloud subcontractor" fashion.
The value proposition, therefore, mirrors cloud manufacturing but applies to labor orchestration rather than production coordination. Customers get access to specialized capabilities without managing complex relationships, predictable outcomes without operational complexity, and single-point accountability without losing access to best-in-class expertise. Contractors get more consistent workflow, reduced overhead for customer acquisition and project management, and the ability to focus on their core technical competencies. A specialized contractor might excel at their technical work but struggle with customer acquisition, project coordination with other trades, or managing customer communications. The platform handles these non-core activities while ensuring the contractor gets consistent utilization and can focus on delivering quality work.
This model works particularly well for outcomes that require coordinating multiple specialties but where the customer values simplicity and accountability over direct relationships with individual contractors, such as commercial fit-outs, system upgrades, etc.
Both cloud manufacturing and cloud (sub)contracting succeed by solving fundamental coordination problems that exist throughout AEC: fragmented capacity creates inefficiencies for both supply and demand sides of the market. Manufacturers and contractors struggle with inconsistent utilization, unpredictable revenue, and high customer acquisition costs. Customers struggle with relationship management complexity, outcome accountability challenges, and limited access to specialized capabilities. The platforms that succeed in these models aren't simple aggregators or matchmakers of supply: they actively orchestrate it to deliver superior outcomes.
Alright. Now, it's truly time to bring this article home!
Conclusion
Wrapping up this 3-part series on emerging AEC-tech business models, I see immense promise in both OaaS and Cloud Manufacturing.
The beauty of these models lies in their alignment with fundamental market needs. Rather than forcing customers to adapt to new technologies, these approaches embed innovation within familiar service frameworks. The early success stories from our portfolio (and beyond) demonstrate that this isn't just theory, but rather a proven path to building defensible, high-margin businesses.
Cloud Manufacturing holds particular promise in markets like India, where fragmented manufacturing landscapes and underutilized capacity create perfect conditions for orchestration platforms to thrive. Meanwhile, OaaS offers a more universally applicable model (unlike cloud manufacturing, which, as said, thrives on specific market structures). It also offers interesting cross-border opportunities for "digital" outcomes (e.g. India to Europe/US).
For entrepreneurs exploring these models, remember that success requires more than just technological innovation. It demands operational excellence, deep market understanding, and an unwavering commitment to delivering outcomes. The bar is high, but the rewards are substantial.
At Foundamental, we're particularly drawn to founders who dig deep into the overlooked corners of the industry, discover insertion points that require true domain expertise to uncover, and build real businesses that speak the language of their customers while maintaining a clear line of sight on profitability.
If you're exploring an OaaS model in a hidden-in-spite-of-obvious market (or just want to bounce ideas around), don't hesitate to reach out. By the way, I shared a very interesting opportunity (still scouting for founders building in it!) to build an OaaS company in India while serving global customers in a previous article.
More appetite for this type of content?
Subscribe to my newsletter for more "real-world" startups and industry insights - I post monthly!
Head to Foundamental's website, and check our "Perspectives" for more videos, podcasts, and articles on anything real-world and AEC.
#ConstructionTech #OutcomeAsAService #VentureCapital #ProductMarketFit #businessmodel #aec #founders #startup