Building digital is relatively easy—low code lets even measly economics majors like us build an app. If you hack around in Notion long enough you can build a wiki, a task management tool, or almost anything else you can dream of, all within a couple of hours. In contrast, building in the real world is tough. Just ask Zuck! He’s halfway through building the Metaverse, but can’t get past the permit phase of building his Palo Alto compound.
Bytes are easy; atoms are hard. This wasn’t always the case with bytes, and it will not always be the case with atoms.
We believe that building in the physical world will follow a similar evolution as was seen in software development. Software initially optimized internal workflows. The physical world will be the inverse, requiring external workflows with a higher level of contracting, verification, and automation. The software vendors that build for these problems will create platforms that look more like networks than mere applications. Though the challenge is greater than building just another SaaS app, it will allow for a larger, more defensible business that can greatly improve large portions of the physical world.
Past to Present
By examining the history of software development, we can forecast the future of physical automation.
25 years ago, developers were wild-haired creatives. They passed wholly original code on to quality assurance, and only once the code was tested, tested, tested, and tested again would the grizzled operations team deploy that code carefully into production. Each team threw code over the wall to each other, and the instinct was to go slow. One error in a highly interrelated system meant taking the entire product offline. That’s okay if it’s an internal site, but really not okay if it’s your ecommerce site or trading app.
Creating a physical product is like that but, by our very careful estimation, one million times worse. Even today, with all our experience, the design phase is mostly done manually in digital CAD environments. Once designed digitally, the creator of the product needs to figure out how to create it in real life.
The Problem
This isn’t an isolated problem but appears to be common across a wide range of design to manufacturing processes for even the simplest of goods. Take, for example, mechanical keyboards. Dave’s 16-year-old son, Andrew (a hobbyist designer) told us about what it takes to make a keyboard:
“Mechanical keyboards are pretty simple. They have four parts: a case, a PCB (printed circuit board), a switchplate, and various small screws, rubber, and/or foam parts. Despite product simplicity, the manufacturing process is incredibly difficult. After designing the product in CAD, you need to contract with a computer numerical control (CNC) factory for the case, and sometimes a separate factory for specific case treatments. You also need to contract with a PCB factory, as well as suppliers for silicone/foam castors, screws, rubber parts, and woodworking. Nearly all manufacturing contacts are sourced through Alibaba, a sort of wild west of manufacturing, and quotes & files are sent back and forth over Wechat across time zones and languages. Unless you’ve done this many times, it’s impossible to know what you’re getting into in terms of a supplier’s quality control, price competitiveness, and customer service responsiveness. Designers often waste months trying to settle with suppliers and coordinate various parts of their keyboard.”
Xometry, a public company, illustrates the supplier engagement process as follows:
Andrew isn’t alone in his struggles. This problem is almost universally endemic to the design-to-build process, and increases with product complexity.
Imagine working with suppliers to build something as intricate as a car.
Or something as complex as a building.
Working with Suppliers: The Cross-Enterprise Problem
The $50B Product Lifecycle Management (PLM) software category was designed to solve the real-world manufacturing problems described above. The category has had two major advances. The first was CAD—by making drafting more efficient, software vendors could accelerate the design phase. The second was configuration management. Keeping track of all of the details associated with a long shelf-life product requires its own unique set of tools. PLM was meant to be the system of record across all relevant departments: design, sourcing/procurement manufacturing, QA, maintenance, and so on.
However, the PLM approach was designed to only work within a company, not with external suppliers. The cross-enterprise problem—e.g., working with third-party suppliers—is easy to articulate but difficult to solve. Suppliers are incredibly fragmented by type and process. As Andrew described, even a simple product may require 10s or even 100s of highly specialized and discrete steps. To get a feel of this, look up “manufacturing processes” on Wikipedia—you’ll be overwhelmed by the sheer number of high-level categories that it lists.
Oftentimes, there’s no good information on a manufacturer’s capabilities, capacity, quality level, and reputation. Soliciting RFPs requires manually calling around, frequently across time zones and language, and most suppliers will say they can make everything (they can’t). It’s like your wedding: it’s high stakes, infrequent (hopefully), and often you are working with vendors new to you in fields you may not understand.
This problem is further aggravated by culture, technical proficiency, and demographics. Many of these mom-and-pop machine operators might come from blue-collar backgrounds that may not always see eye to eye with white-collar designers. And in many industries, domestic manufacturing is aging out, and working with oversea suppliers creates language and cultural challenges.
A technical program manager at one of the largest consumer electronics manufacturers described their experience with this problem: “There is an entire, massive department made up of GSMs (global supply managers) whose main job is understanding, and managing the relationship with, various suppliers. This ranges from the parts that make up all of our devices, to the vendors who make the equipment that makes our devices, to the contract manufacturers who operate the equipment that we use to make our devices. It’s an extraordinarily complex web of interdependencies.” The program manager further explained, “There’s no real reference book for this—I only know to go with vendor A over vendor B because of working with both vendors previously, and I know vendor A is better. Sometimes I still go with vendor B if we don’t want to spend the extra money for vendor A.”
This is a Big Problem
Manufacturing represents $2 trillion, or 11%, of the U.S. GDP. Even minor improvements will result in tangible, powerful effects because of how much of the world this sector touches.
Manufacturing can be divided into either discrete or process manufacturing. Discrete manufacturing is an industry term for the manufacturing of finished products that are distinct items capable of being easily counted, touched, or seen. This includes parts and systems—like nuts and bolts, brackets, wires, assemblies, and individual products. This distinguishes it from process manufacturing, which is chemical or food- and recipe-based manufacturing.
This design-to-build process is directly relevant to discrete manufacturing, where some of the components need to be custom created. The use cases are essentially infinite, but a good litmus test is anywhere CAD/PLM is used.
Software (AI and Networks) to the Rescue: The Future State
Just as the software industry evolved over the past twenty years to create integrated manufacturing (DevOps, Dev/Sec/Ops, infrastructure as code), so too will real-world manufacturing.
The entire manufacturing process starts with design.
Because it is at the beginning of the manufacturing process, the CAD environment is the natural control point. It is a mature market served by Autodesk, PTC [Creo], Dassault, and Siemens. However, these design environments need to be augmented. They need an understanding of downstream supply realities (cost, durability, availability, speed, risk, sustainability), but also need to provide downstream instructions for manufacturing (handling, finishes, treatments, testing). The products being designed and the manufacturing processes can be quite different, so narrowing the scope to a specific type of product or manufacturing can make the job more manageable and the opportunity for automation more powerful.
The bill of materials (BOM) is the next control point and is a great place to start solving the procurement challenge. The design drives the requisite BOM, and that BOM should be matched to a supplier base. The additional nuance is that suggested changes to BOM by a supplier—or a model that knows what other products have the same form, fit, and function—might improve time to market, cost, and availability.
A supplier base can be utilized in 3 ways:
- Managed service: Companies like Xometry will go out on your behalf to solicit bids to build a part and provide you a final, fully-landed cost (which includes a margin for them).
- Data set: Run enough RFPs as a managed service, and pretty soon you will have a third-party data set on supplier capabilities/credentialing, customer feedback, sustainability, and risk. Real-time integrations (if available) can provide more dynamic attributes, such as pricing and capacity, which can be shared with the client in an individual supplier or aggregated benchmarking fashion.
- Company-specific supplier databases: Many times, there’s a deeper collaboration and customers want to know your supplier. This functionality can be an in-house software supplier management platform, or a third-party managed service or third-party data set.
Against this background, AI can really shine. By “magically” decomposing a product design into required parts and recommendations for the best suppliers and alternative components, software can dramatically reduce the cost and time to build while improving the quality of the collaboration with a better base of suppliers.
Just like in the DevOps analogy, this supplier infrastructure can be brought forward into the design process, where the designer makes choices based on downstream supplier and manufacturing considerations.
The company is now the software fabric between the design and the build, the brand and supplier. The more you make this supplier base available digitally on common workflows, with automated decisions, the more this supplier base becomes a supplier network.
We can imagine a world where the suppliers are all on common RFP/CPQ software workflows, many of which can be automated; where common contract management software not only creates efficiency in the negotiation phases, but automates future engagements with master agreement capabilities. From there it can drive the performance dashboarding of the supplier, provide extended supply chain visibility, and help to coordinate logistics and the iterative supplier engagement described above (see diagram 2).
On the supplier side, this design-to-build software fabric can source demand (reducing the need for sales and marketing), and manage its information across multiple clients, client communications, and task management functionalities. This is an opportunity that we’ve discussed in prior essays on supplier extensions (and in a case study on Ariba).
The benefit of this software fabric compounds when the design process is iterative (which is almost always the case). As a technical program manager at one of the biggest global consumer electronics companies (mentioned above) explained,
“The real value prop here, as I see it, is the ability to play around with different models and see how that impacts manufacturability, cost, lead time, etc., using AI as opposed to the back-and-forth cycle that we operate with currently. We spend millions on iterating through hardware development cycles (or “validation builds”) where we test hardware for its functional capability as well as its reliability. Coming out of a build, we might change part A ever so slightly, or change it to a different material, and we have a painstaking back-and-forth process with the supplier of part A to determine what is feasible and how it will ultimately impact costs.”
Design -> Build -> Operate
You could extend the life cycle even further to the ongoing maintenance of a built product. For example, let's look at a commercial building. Much of the equipment that needs to be maintained—elevators, furnaces, or HVAC— is determined in the design phase. The CAD and BOM are not only useful concepts in the build phase but eventually in the maintenance and redevelopment phases as well. The BOM can provide the inventory of assets & equipment, associated maintenance schedules and instructions, and useful life and depreciation schedules. Eventually, when that building is renovated, the original CAD can provide a baseline for new construction or large CapEx projects.
Digitizing Design-to-Build
COVID and the geopolitical tension of recent years have highlighted the vulnerability of supply chains. Even before these disruptions, the markets were pushing the physical world to digitize. Manufacturers and supply chains that digitize will win markets by improving efficiency, quality, and time to market. Simply put, the companies who digitize design-to-build (and to operate) will be leaders in business outcomes and in an improved world.
For software companies looking to move past being mere applications, their primary goal should be enabling a design-to-build workflow (the truly ambitious can go after the maintenance opportunity, too). This will be accomplished by becoming a multi-stakeholder platform that allows for a common workflow, a single source of data truth, and payments. By having these all in the same place, they can skip the errors of the previous generation of PLM software.
To get started, companies should attack the control points, either at the start of the design process with CAD software or at the bill of materials. We believe that a $100B+ horizontal software company can be built using this strategy. However, because supplier and manufacturer density is key to building network viability, it is best to start with a specific vertical.
We love the idea of bringing together a community to explore the boundaries of Vertical SaaS and are excited by what we can learn from each other. If you are looking for how to build a software company in a specific vertical, check out our work in the Vertical SaaS Knowledge Project. If you have thoughts or comments or want to get involved, reach out to us at knowledge@tidemarkcap.com. If you would like to stay updated as we publish these essays, sign up below.
