“Is there a universal template that could be built to describe every possible engineering component?” It’s a question as old as engineering itself, recognized for hundreds of years as more of a thought-exercise in academic circles, an unsolvable problem.
That is, until David Anderson, PhD., Founder and CEO of Engora, decided to reframe the question—and launch a first-of-its-kind product that could fundamentally accelerate the engineering of complex systems.
Engora, a portmanteau of the words “engineering” and “Agora” (the plaza in Ancient Athens where people would publicly debate ideas), is at its core a search engine, albeit one that uses advances in machine learning and text matching to build data sets from scratch without a universal template by asking engineers what they need.
Still in its early stages, the goal is to build a tool that hardware engineers can use to take stock of all components available to them, as opposed to current systems of trial and error that not only wastes time, but more significantly, miss potential optimizations that the world desperately needs. Engora aims to bring the exponential innovation now taken for granted in software development to the mechanical engineering industry.
It’s a big vision, but if anyone can execute on it, it’s Anderson. With his unique blend of hands-on experience, practical research, and theoretical grasp of the profession throughout history, Anderson doesn’t simply know engineering. He loves it.
From tinkering in his grandparents’ workshops as a child to working on his PhD in Design Automation while founding Engora, his experience is multifaceted and unique. MassTLC spoke with him to learn more about his story, his company, and his vision for the future of engineering.
___
Tell us about Engora. What does the company do and what is your vision for it?
Engora is a search engine for mechanical and industrial components. There are common products that engineers have to spend a lot of time searching for, especially when looking for weird, specialized product types. For example, bolts or fasteners. What Engora does is provide pre-built, pre-computed results for some of these really common product verticals to guarantee a high quality. A user can type in any product name, provide the parameters they want, and Engora will provide those results. It’s a process of ongoing, continuous improvements. At the same time, for really common product types, anyone can just click a button, and Engora will give back thousands or tens of thousands of options for those products.
The vision is to eliminate manual rote work in engineering design. Engora speeds up one of the most time consuming and repetitive manual tasks in engineering design, but also, our approach is uniquely suited to feeding into other optimization and simulation tools to tie into the broader engineering automation ecosystem. The core motivation is to enable mechanical engineering to move at the pace of software innovation. We’ve seen an exponential speed up in software development. How can we bring that to the hardware side? What we’ve built to get there is Engora.
How did you start on this journey? What sparked your interest in engineering?
My interest in engineering goes way back. As a kid, I tinkered a lot with Legos and toys. My grandparents had workshops, so I built little gadgets and toys there, and I was involved in robotics in high school. That’s what motivated me to study engineering in college. For me, the fun part of hardware engineering is that it’s almost like solving a puzzle, but it’s a puzzle that when you solve it, you make some part of the physical world better. That physical element keeps me focused on the hardware side, as opposed to drifting into software completely.
I studied mechanical and ocean engineering in college at MIT, and while I was there, I took some electives in software. I knew just enough software to be dangerous, but I focused on hardware engineering. After I graduated, I worked for a couple of startups and labs in Boston, and I realized a lot of engineering work is unnecessarily manual—looking through catalogs, doing computations, building CAD models, testing if things fit together. The really frustrating thing was the sheer amount of iteration. Doing that stuff once is fun, but doing it for the 10th time because some other subsystem keeps changing is where it gets frustrating.
As I said, I had dabbled in programming, so while I was working, I started making software tools to automate away the boring work that I had to do as an engineer. That was how I got interested in answering questions like “Why isn’t this more automated? How could we just make this experience better for engineers?”
In the middle of all of that, I did a hackathon with a friend where we built a design automation tool for a particular product, a serial elastic actuator. The funny thing is, both of us ended up going off to grad school to study design automation, in part inspired by that hackathon.
It sounds like the budding idea you had for Engora was really a catalyst for you to go to grad school. Oftentimes, there’s a narrative in the startup world that if you want to fix something, you should jump right in and do it, but you took a different approach. Why did you decide to pursue a PhD first? What was the benefit and was it the right choice?
For me, [the PhD program] was definitely the right decision. I’m the sort of person who wants to understand on a deeper level. I didn’t actually know that much about design innovation or design thinking. Coming from that engineering side, I really didn’t have any idea how to solve this problem, or what the problem even was outside of my own dislike of the situation. Learning methods for formally working out user needs, for ranking those user needs, for ideating around those user needs was extremely valuable for me.
How did your research inform the development of Engora and influence the early phases of the company?
In grad school, my research focused on the human factors of how people build design tools. The core of it was interviewing design practitioners who build software tools and write programs, across many different fields such as architecture and engineering, to look for common patterns and problems. How do they think about these problems? How do they approach designing the software? What gets in the way? What do these people who are experts at using software tools for design see as the major barriers to doing so?
As part of that research, I built a lot of small one-off design tools to support various companies and other labs connected to ours. One of the biggest challenges with building design software that I found is the difficulty of accessing engineering data. You can automate a lot of the optimization side or the rote calculations, but there is no easy access to the data needed to actually make those optimizations useful in many contexts. At some point, if you’re building a robot, you’re going to end up buying motors or bearings off the shelf. Suddenly, that limits your optimization, because you’re buying one of these discrete components. Do you just guess what’s possible? Do you pick a single example and optimize around that? What’s missing is a holistic understanding of what’s possible and where you should invest in engineering effort. This difficulty dealing with engineering data was what I found to be one of the biggest sticking points in engineering design.
Is that because the data is not available? Or no one’s collecting it?
The issue is that no one’s collecting it. It’s scattered, and each of those scattered sources talks about it in their own way. Some of this is a consequence of engineering, having developed back in the late 1700s and 1800s. All of our processes still assume people at every step in the process. The information presentation is designed to make it really easy for a human to understand quickly, but that’s very different from making it easy for a computer to understand it quickly. When a human is reading and understanding it, there’s less need to have an easy understanding across standalone sources.
At what point did you realize you had an idea for a company?
I started thinking about it in grad school, because having this data would have been really useful for me for the design tools I was building for companies, but the first versions of Engora weren’t a search engine.
In the early days, I thought a search engine would be too big to try to build as a small startup. Think about industrial distribution. There’s something like 4000 distributors in the U.S. Even just finding all of them is incredibly difficult, and then on top of that, each of them will have what they offer laid out in a different format. They might discuss the same product using different terms. At the outset, all of these things seemed like it would take a lot of manual work to solve, which is why in the very early days, I thought it would be too big to handle.
For the early version, the idea I had was to create a database system for engineering that would make it easier for a company to accumulate and use data over time. People liked it, and we used the technology to build demos of internal design tools for some big companies. We were able to show that, if you could get the process oriented, you can automate away paper worksheets and repetitive calculations and digitize work a lot faster.
There were two main challenges though. First, enterprise work is slow and difficult, so as a startup, that’s a tough hill to climb. Second, people still wanted data to feed into their system. They could put it together manually, but it was clear the real value would be if we could just provide it for themif we could just give them a list of batteries, or bearings, or fasteners. We kept ending up back at the question of, “Can we just build that data set?”
How did you get Engora off the ground after that? What are you working on now?
For the first two years after grad school, I was a part time postdoc at University of Maryland. It was fun, but in the summer of 2020, I was able to raise a small angel round from some Boston area serial hardware entrepreneurs, which allowed me to work full time on Engora.
We still weren’t working on the search engine yet, but the funding allowed me to focus on the data platform and user needs. From there, I was able to create a proof of concept for the search engine and recognize that it was feasible for us, as a startup, to go ahead and build it.
Now, we’re building that search engine. Based on feedback on the prototype, we raised another round with the same angels, and we’ve since built out the team and soft launched a new prototype that we are getting feedback on now. We consider this to be a production ready prototype, although we’re still adding data to it constantly.
Our focus right now is working directly with individual engineers so we can build something that improves their lives. Of course, if there’s an opportunity to collaborate with a bigger company or integrate with other tools, we’d welcome that, but our focus right now is to prove we’re building something that really helps individual engineers in their day-to-day work.
We want Engora to be simple to access and use, because the difficulty of accessing engineering tools is another thing that I’ve personally found occasionally frustrating. We want to keep this as accessible to engineers as possible.
You mentioned that early on, you thought building a search engine would be too difficult and require too much manual labor. How do you approach solving that problem now?
There were some clever hacks we did in the beginning. To get philosophical, there’s a lot of research on engineering ontologies and on engineering components. In other words, the question is “is there a universal template that could be built to describe every possible engineering product, every possible component?” As you can guess, this is really hard to solve, and hasn’t gotten much traction. We reframed the problem to make it more practical to solve. With Engora, when the engineer is searching, they provide us that ontology, that template for their specific need. That, combined with significant advances in text matching, text reading, and machine learning enables us to skip a lot of the traditional, difficult work of building very formal data sets from scratch.
What is your vision for Engora? What’s next?
In the very short term, we think having the ability to rapidly find components—especially more specialized components or more local, specialized distributors beyond the main players—is something that engineers really want. Engineers can use our search engine to find the right component faster, which helps everyone. It helps smaller, more specialized distributors, more local distributors, and engineers.
In terms of a broader vision of design automation, we are now getting all of this data back in a structured, consistent format, which means it’s machine readable and could be easy to feed into other software tools. We need to test this more.
One of our hopes is this overcomes the problem of data access for any case where you would be looking for off-the-shelf components. You can access all the possible combinations of motors and batteries to see what’s possible and gain an almost instant understanding of whether an idea is feasible and what the potential risks are. In that sense, we hope Engora can kickstart that exponential pace of innovation in hardware that we see in software.
Why does this matter?
We’re seeing the importance of being able to engineer complex systems much faster and much more accurately, everywhere. Climate change is almost a cliche thing to bring up, but we really do need to be able to design new power generation systems quickly. We need to be able to design these electrified versions of our existing products quickly. We need to be able to design more optimal versions of our products. There’s research, for example, that estimates if we could do whole system optimization of every aircraft out there now, we would see a 30% reduction in fuel emissions, which would be huge. Then there are things unrelated to climate change. All of the supply chain issues we’ve had recently, right? It almost seems like we’ve hit our limits of the complexity of the systems we can design with our existing processes. To actually adapt to design new systems for any of these new challenges that are emerging, we need to rethink our processes. We need to do better than we’ve been doing so far. Engineers are great, and Engora will help us be better.
___
A prototype of Engora’s search engine is online at https://search.engora.tech. If you have any feedback or are interested in learning more or discussing collaborations and integrations, please contact David at dsa@engora.tech.
