Pradyut Paul | CAD Data Management, Part Numbering, and Project Management for Hardware Teams

SUMMARY KEYWORDS
pdm, teams, solidworks pdm, build, design, engineers, hardware, cad, cloud, companies, workflow, part, manufacturing, product, platform, system, tool, manage, create, onedrive
SPEAKERS
Presenter, Pradyut Paul, Aaron Moncur

Presenter 00:00
Hi everyone, we’ve set up this being an engineer podcast as an industry knowledge repository, if you will, we hope it’ll be a tool where engineers can learn about and connect with other companies, technologies, people, resources and opportunities. So make some connections and enjoy the show.

Pradyut Paul 00:18
But one of the most surprising things that really stuck with me at Apple was that we were working on some really complicated designs, with really strict tolerances and margins built on expensive CAD systems, building products that would generate billions of dollars in revenue. Yet, almost all of our cross functional and external communication happened through screenshots of these designs, over email, slide decks, and spreadsheets.

Aaron Moncur 01:05
Hello, and welcome to another exciting episode of The being an engineer podcast. We’re speaking with Pradyut Paul today who holds bachelor’s and master’s degrees in electrical engineering, as well as an MBA from Yale. Among other things, he managed several new product programs at Apple, including the iPhone eight, eight plus xs, xs, Max 11, as well as early development of air tags produced says about himself. I’m not very smart. But I’m smart enough to know that engineers shouldn’t be spending most of their time in meetings and sifting through emails. My goal is to enable hardware teams to focus on innovation and engineering by providing a platform that removes the frictions in design collaboration. I love that because I often start sentences the same way. I’m not very smart. But I’m smart. enough.dot.so. That’s great. Pradyut, Welcome to the show.

Pradyut Paul 02:01
Thanks for having me, Aaron.

Aaron Moncur 02:03
Well, I’ve been really excited about this, because the topic that we’re going to discuss, which is, effectively what your company does, is something that we have been thinking about and acting on here, Pipeline a lot more in the past year than then we have been previously. So this is almost going to be kind of a selfish episode. For me, I feel like I might get more out of this than anyone else. But I’m sure there are other people out there other engineers kind of struggling with this same thing. If there weren’t, then you’d be in big trouble. I think. Before we get to that, tell me what made you decide to become an engineer?

Pradyut Paul 02:44
Right. So, you know, I’m definitely not an engineer anymore. But I definitely started my career as one, I’ve always been a very visual learner. So seeing how things functioned, and are built has just been very fascinating to me. I’ve always struggled when it comes to coding software, because you essentially just type words, and then an output would disappear. Whereas with very physical products, you can see and understand how each component plays a role in the overall system. So as a student, I also really enjoyed physics and math. And you know, what better way to incorporate those subjects into the physical world than engineering? So yeah, I mean, that’s really why I’m really passionate about hardware and why I’m so excited about the innovation that’s taking place around us today.

Aaron Moncur 03:33
Yeah. Can you talk a little bit about I mean, we’re gonna dive into your company, build, but But before that, can you share a little bit about your professional past to date, you know, where have you worked and what roles have you held?

Pradyut Paul 03:47
Yep, so I started as a RFIC engineer over at Raytheon space and airborne systems. That’s kind of where I worked on next generation sensors for low visibility applications for the military. Shortly thereafter, I moved to leading hardware team over at a consumer electronics startup called Tracker, we were creating these Bluetooth tracking devices, a lot like the air tags. And there I helped manage design, sourcing manufacturing of both the existing product line along with r&d efforts on new products. And after Tracker, I moved over to Apple as a program manager for iPhone hardware development, where as you had mentioned, I helped launch iPhones eight through 2011. And as a systems program manager I had visibility into the entire sound development would frequently travel over to China for their engineering builds. So I also worked cross functionally with electrical, mechanical manufacturing software. engineers to help deliver that next generation of hardware. And of course, shortly after I left Apple I co founded build.

Aaron Moncur 05:08
Awesome. So that’s a perfect segue into build a new tool for modern hardware teams to manage view and share CAD in the cloud. Can you give us an overview of your company?

Pradyut Paul 05:20
Yeah. So you know, build is a design management platform that provides a more modern experience around version control, project management, and cloud storage for hardware design teams. Many of the companies that we work with are looking for better data management practices, and are often limited to traditional PDM solutions. They’re also running design reviews through screenshots, slide decks, and emails, and are looking to have a more effective form of communication when it comes to those practices. So build comes in and takes all of those engagements and creates a cloud based environment where teams can have a more streamlined and organized workflow around both their data management for CAD assets, but also the ability to review and provide feedback on those assets.

Aaron Moncur 06:19
Okay, I mentioned that this is a timely interview, because we recently at pipeline, we purchased SolidWorks PDM, to try for a year and kind of see how we like it. And in early next year, we’ll be deciding whether to keep it or try something else. So I have several questions for you about build for SolidWorks PDM. Realizing Of course, the build is more than just PDM. But initially anyway, I’m going to focus some of my questions on the PDM aspect of it. So let’s start with kind of a broad question. Why would hardware teams use build over SolidWorks? PDM?

Pradyut Paul 06:53
Great question. And I want to start by saying I’m glad your team is already looking into better data management processes. You know, I think it’s a slow and steady process for teams to adopt PDM. And traditionally, it’s been very cost prohibitive. It just taken a lot of time. And now most companies are choosing Build over, you know, a legacy PDM system like SolidWorks PDM, because they care about that experience, from how they buy software, to the end platform experience, to maintenance and all the way to support. So if you look at, let’s say the traditional way of buying software, any software pretty much in the hardware industry, you’re generally stuck with a VAR or value added reseller. I’m sure you’ve had to deal with one of these in the past. And you know, generally the experience with VARs are less than ideal to say the past, right? There’s a lot of slow response times, it feels like engineers are in a very salesy motion. And there’s quite limited support, it’s a pay to play support service industry. At build, you pretty much just get a demo on day one. And you’re on a trial, we run a very transparent process. And we have a very transparent pricing model as well. Right. So the buying experience turns from this month long evaluation, that seems super vague to a very transparent, quick process. And then it comes to the input from experience in the maintenance. And so the number one thing that teams will say to us is that they don’t want to manage a server. So if you look at the framework for most legacy PDM, they were built for an on prem installation, which means that you would have to get and maintain a server. And so in today’s era, no one wants to take on that headache, nor the costs associated with a server. So even if you wanted to host PDM in the cloud, you’d still have to go to a VAR. And they would tell you, Okay, well go and procure an Azure or AWS instance. And then we’ll host it there. And if you don’t want to do that, we can do that for you. Which really means that PDM in the cloud is quite literally an, you know, a software application in the cloud. It’s not a cloud native application. So for teams that are actually looking for that cloud first platform, that’s kind of where we come in. And because we’re we are that cloud first platform. It’s a very intuitive interface, and it feels like it was built in the 21st century. There’s no setup, and there’s no maintenance cost. And that’s why build ends up becoming the PDM of choice. Now, when it comes to feature sets, right, we’re pretty transparent about this SolidWorks PDM has a lot of features, right? It’s got features from a all the way to Z. But most teams 90 plus percent of teams will only use features A through E but the end paying for everything else. So becomes extremely cost prohibitive. It also creates a highly complicated product that ends up becoming extremely difficult to use requires a lot of training and a lot of maintenance. So build our product is centered around the features that teams actually use. And then we provide customization on top of that for enterprise customers. So you’re really only paying for what you use, and you have a platform that’s reflective of your workflow.

Aaron Moncur 10:30
I’m curious, how did you identify which features engineers actually use? How was that determination made?

Pradyut Paul 10:38
We did a lot of customer discovery, right? So we went to a lot of hardware engineers and hardware teams, and we asked, What do you really care about? And what are you really looking for from a PDM system. And almost all the teams would reciprocate kind of core four features, checking in and checking out files so that other team members aren’t overriding my designs, version control, being able to render cat in the cloud, so I don’t have to load it into SolidWorks every single time. And then being able to recover our previous version. Right, those were the core assets. And then every team, you know, had this gotcha, right, which was a nice to have it was, we do this very specific thing in our workflow does build support, and that’s where the customization comes in. And that’s where we are able to provide that enterprise level feature set for the teams that really need it. But we provide the core functionality and the foundation to PDM. For all the teams out. Absolutely need PDM.

Aaron Moncur 11:45
Got it. Okay. So this is sounding, you know, so far, so good here. How about the cost, because we’re paying for SolidWorks PDM. Right now. And we were very similar to the people you spoke with that said, I don’t want to manage a server. So we’re doing it in the cloud. And we don’t want to manage our own cloud server even. So our var is managing that they have their own, you know, cloud systems. So we’re paying more for that it’s pretty expensive. And I think we ended up paying, well, maybe I won’t give a figure but it was 10s of 1000s of dollars just for the first year. And it’s been really time consuming to set everything up. And to get trained. It’s not like you just install the software and you’re off to the races, there’s a significant amount of front and center setup that goes on. So how does the cost of build compared to SolidWorks? You don’t need to give exact numbers if you don’t want to do that, but maybe just you know, a rough percentage or something like that.

Pradyut Paul 12:44
Yeah, I want to start out by saying that the experiences you’re facing is not uncommon, right? Pretty much every team that we’ve worked with that has gone through the process of buying SolidWorks PDM, or any traditional PDM systems is faced those exact experiences. So in general, if you’re a team that wants to get started on a PDM, and you go with a system like SolidWorks, PDM, you would expect to pay about $2,300 for one single editor seat, plus an annual maintenance of about $620 per year, right. And then on top of that, if you need help setting it up and configuring it, implementation and training costs can range from somebody 500 to $10,000, for that first year, right. So if you look at, say, a small team of five engineers, your first year costs is going to be around $22,000. Now at Build, our pricing model is very simple. And we’re super transparent about this. Our starter plan for teams that are looking to get out to PDM is $60 per user per month. And so for that same team of five individuals, it would be $3,600. Making build folds cheaper than SolidWorks PDM.

Aaron Moncur 14:11
Well, that is attractive from a price standpoint for sure. We we were working on one of the projects we’re doing right now, it’s pretty good size build. And there are hundreds of custom parts not Not to mention all of the COTS, you know the McMaster stuff and SMC hardware and all those off the shelf items in the assembly. And one of our pain points in a project like this is how to effectively manage all of that data. You know, have we exported all of the custom parts to get to our vendors? Which manufacturing partner are we sending which parts to for parts that have multiple configurations did we include all of the configurations in our drawing package does does build help with those kinds of issues as well? This is

Pradyut Paul 14:59
a A very interesting problem that you’re having and a great question. So, as you suggested, at a point in the development cycle, you’ll enter the manufacturing phase where designs turn into a physical output. And so for most teams that involve some sense of supply chain management, and part lifecycle management, the complicated needs of manufacturing, procurement, and the overall supply chain lead to the need of a PLM, or product lifecycle management tool. And so that’s how we think about PDM vs PLM. So when you’re in the actual manufacturing process of the development cycle, PLM is in play. And when you’re in the design process, when you’re in CAD, right, that’s when PDM is in play. Right now, though, functions, the purpose of PDM with very light PLM features, such as tracking cost suppliers and manufacturers for each design that you host in the PDM vault. So we’ve embedded all that information directly in the metadata of the design, which helps designers get lightweight PLM functionality alongside with their PDM needs. For a complete solution, right, we just recommend companies to adopt a PLM. But like in your case, most teams will first adopt a PDM system before PLM. And we’re able to bridge the gap in terms of when they need to get to that PLM.

Aaron Moncur 16:36
Got it. Okay. Another challenge that we have managing CAD data is is we use Microsoft OneDrive or SharePoint to host all over our CAD data, where we did before moving to SolidWorks PDM. And we would create conflicted copies unintentionally, right? There’s two people have the same part open at the same time, but but don’t know and they both save it. And on small projects where there’s just one or two people working, it’s not much of an issue. But on larger projects, where there’s half a dozen or more engineers that are working at the same time, this becomes a big issue. How does how does build solve this?

Pradyut Paul 17:14
This is the core concept of PDM. Right and having a vault. So it seems like as you had mentioned, if you aren’t on a PDM system, having a generic cloud storage tool like OneDrive, Google Drive Dropbox, you’re going to have issues around multiple designers trying to work around the same design at the same time, right? There’s a lot of overwriting designs, a lot of duplicate copies that are floating around. The benefit of a PDM is that it solves for this exact problem through a checkout check in process. So when you want to work on a design, you check it out in the PDM. And it informs your team members that you’re currently working on it. And it doesn’t even allow them to checkout and design. They can view that design in a read only format. But it doesn’t allow them to actually work on it at the same time that you currently have it checked up. Now you work and you make your changes. And when you’re ready to push your changes back to the vault, you check in the design, and it updates all the team members with the latest version. So this process this check in and checkout process ensures that there’s no designs being overrun, and that there are no duplicates floating around. Because everyone’s just working on a read only format. Yeah, great.

Aaron Moncur 18:33
That makes sense. But one of the things that we’ve learned as we’ve spooled up on on PDM is that the PDM tool itself is of course very useful, and prevents things like you know, duplicated copies being made with the vault, like you mentioned. But it it has to be layered on top of a process that’s defined by your team, you have to have a process in mind for how you want your CAD workflow to go. Right. Do you want to have mandatory design reviews at certain steps? You know, at what point does a part become released and controlled revision control, things like that. And this process can get pretty complicated, depending on you know, what your specific needs are? Are there specific tools that you have developed within build to to make that process? I guess, the setup and the onboarding process a little bit faster and simpler than traditional? PDM?

Pradyut Paul 19:34
Yeah. So like I mentioned PDM was built. It was kind of a one size fits all right? It was a solution that would fit the early stage three person startup so the world all the way to the Boeing’s of the world. And with that mentality SolidWorks PDM and most PDM solutions are super heavyweight. They were acquire a lot of change management. And it doesn’t allow teams to quickly transition into a PDM workflow as you as you mentioned, right. Most of the companies that we work with come from a tool like OneDrive where they haven’t had any processes in place. Everything is extremely undefined. And they rely on PDM to provide structure. But the way PDM has been built, is it asked you to define the workflow. And then it gives you the structure there, which is actually kind of counterintuitive, because these teams don’t have that workflow in built. So with build, we make that process extremely simple, right? We have an out of the box, workflow and process that integrates directly with the tools you’re already on. So the CAD systems, whether it’s SolidWorks, or NX, or creo, along with project management tools, whether it’s Asana, Monday, JIRA, and the communication tools, whether it’s slack or teams, so we integrate into your existing infrastructure. And we’re basically saying, You need a cloud based solution that looked and felt like OneDrive, Google Drive and Dropbox, but you don’t need these insane guardrails that prevent you from leveraging your existing workflow, but just have it better. So that’s what Bill does, right? It’s extremely simple process around checking and checking out designs, that provides version control along that process, but also integrates exactly into your workflow the way it is, now, there’s always going to be changed management, right? And change management is the number one problem that most of our customers will, will go through, right, it’s not actually how to use the tool, it’s not set up. It’s not an implementation. But it’s actually I have a very specific process, or I don’t have a process and it’s extremely unorganized to now mentally, we have to go into this checkout or design, make changes, check into design, checkout, or design a changes check in and design. And with every rep that you go through, it gets easier and easier. So we don’t claim that you’re going to be like a king of PDM on day one with build. But it you know, it’s hours on build rather than months on PDM. So just to put some numbers around these right, first enter team that’s not coming from an existing PDM migrating data is a simple drag and drop, or you can actually connect your existing cloud storage. So your team was on OneDrive, you can add your OneDrive and we put all that information over to you automatically. And build onboarding happens through a one hour call with our team. And then two subsequent check ins to help with workflows and setup. Right so and 100% of the customers that we’ve gotten, we’ve been able to go through an onboarding in one hour. That’s how intuitive and simple the platform actually is. It’s amazing. Yeah. So if you’ve used a tool like Dropbox or Google Drive, you generally won’t have a problem once you’re in the platform. And all of this is possible, because we’re 100% cloud native, that means there’s no downloads, no configurations, there’s no hardware setup, and etc, right? You don’t have to work with a VAR get set up, you can just chat with us. We create an account for you, you log in on a website.

Aaron Moncur 23:31
And you’re on your way. Well, that is super attractive. And I’m getting more and more excited about build and looking into build as we speak. I’m going to take a very short pause here and share with the listeners that Team pipeline.us is where you can learn more about how we help medical device and other product engineering or manufacturing teams develop turnkey equipment, custom fixtures and automated machines to characterize, inspect, assemble, manufacture and perform verification testing on your devices. And we’re speaking with producer Paul today about PDM and build his company as well as some other features that they offer. How about data security? If we’re putting our CAD data into builds servers there I’m sure you know their concerns about confidentiality and just overall security of one’s data. How does build manage that?

Pradyut Paul 24:26
This is a top three concern we get from all of our customers and the companies out there. I think the industry has traditionally been very conservative in how they manage their data. The on prem server was the framework of choice. I think as technology has evolved, and specifically cloud technology has evolved. The confidence in cloud storage and hosting has exponential Have you grown. And so we’re at a position where, you know, on prem and cloud are pretty much identical in terms of security, right, you can have an on prem system, and you can make it not secure. Or you can put in all the guardrails and make it secure. The same thing goes with Cloud Storage. And so you can make cloud storage super loose and not secure, or you can put in all the protocols in place, have be compliant, and you can make a really secure platform. So for some background, we offer enterprise grade solutions, we work with Fortune 100 companies, we also work with companies that are servicing the government and the Department of Defense. And so in the US, if you’re working with any government agency, you have to be ITAR compliant. And so with that comes some standard protocols around security and the way you handle and manage data. And so if the people that are, you know, creating the future generation of aerospace and, and the military applications are trusting and build, it really provides a lot of confidence in to the other customers as well. So, you know, I definitely understand and can appreciate people’s concern about hosting CAD in the cloud. But I believe that with the infrastructure and the technology, at where it’s at today, it’s very much in line, if not better than an on prem server in terms of security.

Aaron Moncur 26:44
How was the user experience in terms of speed, opening and modifying CAD files, if there, all of their data is in the cloud? Does that mean that each part drawing assembly file needs to be downloaded and then uploaded every time they’re accessing it?

Pradyut Paul 27:02
That’s right. So this has been a common misconception, kind of across industry, I think people overestimate how big CAD models actually end up being right. We stream unknowingly, gigabytes of video pretty seamlessly over the internet, right? If you’re on Netflix, you’re watching 4k video. And it’s not a problem. And that’s that’s gigabytes of video, right? When you look at these CAD models, even a pretty complicated assembly, it’s probably 1020, maybe 100 gigs, right? The architecture of build is when you checkout a design, we actually create a local copy. And so you can get on a plane, and you can work on your CAD model on a plane without any internet connection. And so you work on a local copy until you have to push your changes. And the way that we built build is you’re only pushing the changes of files that you’ve actually made changes, too. So let’s say you’re working on 100 part assembly, but you’ve only modified 17 part files, you’re only going to commit the 17 part files up to the cloud, you’re not going to commit the rest. And so it provides a lightweight, versatile solution that can scale with really complicated designs. And so we work with customers that are creating massive, massive industrial drones, and robots. And these are very complex designs. And with today’s enter, you know, we’re not in the 1990s or early 2000s, where we’re on dial up, right, everyone’s got semi decent internet speeds, the upload and download speeds are phenomenal. And we’re talking about a difference of a couple of seconds versus traditional PDM. But it provides you the flexibility to access your designs anywhere you go. And then once they’re local, you’re working off a local copy. So there is no difference in terms of the performance there.

Aaron Moncur 29:00
Got it. Okay. I’m curious, how have you implemented into build what you learned at Apple about CAD management and associated best practices? I imagine Apple has a pretty robust system for how they manage CAD data and PDM. What are a few specific lessons you learned there that bill makes available to hardware teams?

Pradyut Paul 29:23
You’re right. So Apple has a very, very robust process. But one of the most surprising thing that really stuck with me at Apple was that we were working on some really complicated designs, with really strict tolerances and margins built on expensive CAD systems, building products that would generate billions of dollars in revenue. Yet almost all of our cross functional and external communication happened through screenshots of these designs over email. One slide decks and spreadsheets. And all of this was because that set of tools was the highest common denominator across these different teams. And I knew that that tech stack and how we communicated had to change. And it needs to be further integrated with the design source itself. So I actually took my learnings from Apple, and we’ve integrated the ability to communicate on and discuss design changes directly on top of where data source lives in built. So with build any user, regardless whether you have a license to SolidWorks, or creo, or inventor, whatever it might be, can view a design on the cloud, on a web browser, they can provide feedback, or redline the model. And it modernizes the design review process and provides visibility to the stakeholders like never before. And so we’re able to deliver this experience, all without needing users to have specific hardware, extra license to CAD systems, or even the learning curve associated to learning those systems.

Aaron Moncur 31:13
Very cool. So CAD data can be accessed in one of two ways is what I’m hearing you say one is traditionally just through SolidWorks, like we always do, but also in kind of like a separate viewer on a web browser. Is that right? That is correct. And so if I wanted to do a design review with, say, a customer of mine, do they need to have an account on build or some kind of license? Or can I just send them a link and they can open it up in a web browser and redline away?

Pradyut Paul 31:44
Exactly, it’s the latter. So just like you would share, like a PDF or a Word doc over Google Drive, you could do that on build in CAD, you can they can render the 3d CAD, they can take cross sections, they can explode assemblies, they can measure, and they can provide feedback directly on top of the models. It’s a really cool and intuitive platform, I highly recommend that you take a chance to get a look at it. And they can provide feedback all without needing an account. There is a great way to run, for example DFM. So if you’re sharing with a supplier, and they want to provide DFM, and traditionally DFM has been done over Excel docs or PowerPoint slides, this is a much more better and streamlined way to run that

Aaron Moncur 32:32
nice, very neat. Maybe let’s get into some of the other features that build offers. So PDM, we’ve covered, you just talked about design reviews. And I understand there’s some some project management tools as well, is that right? That is correct.

Pradyut Paul 32:50
And so we talked a little bit about providing feedback on top of designs, but then you know that it doesn’t just stop there by providing feedback to specific individuals. So you can assign these issues, just like you would in JIRA for software to specific designer. So I can say, Hey, Aaron, I need you to look at this component. And look at this specific thing that I had mentioned here, I can set due dates to it. So I can say I need you to get this done. By next Friday. I can associate feedback, other feedback items to this and add attachments, I can add tags, I can create a whole Kanban board and a whole Gantt chart, I can create a whole kind of story end to end in terms of how we’re going to go around this project from beginning to end. And so as you get these cross functional stakeholders being more and more involved in the design review, you need some level of project management to close out on these issues. And to plan how you’re going to put your resources to actually tackle the the feedback that you’re getting. And so that’s where build can help support your day to day engagements as an engineer beyond just the check in checkout or version control PDM features

Aaron Moncur 34:06
Cool, okay. I saw a blog post about well, it was about part numbering on your sides. I don’t know if you wrote it or someone else. But this has been a source of of spirited debate amongst our team. And some advocate for smart part numbering where you know numbers and letters actually mean something while others want to keep it simple and just have DME part numbers that have no meaning whatsoever. Can you share some some best practices about effective part numbering?

Pradyut Paul 34:37
Yes, I strongly believe that every team should be leveraging some part numbering schema. Having some partners schema is always better than Well, we generally see is it’s not the best form of this but teams will make their file name their part number really the idea of part number is, you’re using this unique string to pass along the entire lifecycle of this design. So when it’s in the design phase, so when you’re in CAD and PDM, you’re iterating on it, you can always go back to that part number, you can take that part number and associated to that design in PDM. But you can also take that part number and associate it to a physical object in Downstream engagements. So whether it’s in your PLM system, or your ERP system, or your MES system, or pick any three letter acronym platform, right. And so that unique part number provides traceability and search ability in a product that might have 1000s of difference of components. And so this becomes particularly important when we’re thinking about sourcing and manufacturing the product. And if you have multiple skews, how do how does a specific design roll up to different product lines, right. And so a smart part numbering schema allows a faster search ability, or being able to search faster for a specific component. Now, if you’re working on a product that doesn’t have many line items, or many components to it, you may not need that complicated of a part numbering schema. In general, what we see as best practices is there’s going to be some identifier as a category. Right? So is this an assembly? Is this a drawing? Is this a part? Is this not a bolt, right? Is this an off the shelf component, there’ll be a unique identifier, and then there’ll be a rev. So the rev is really important. Because you want to be making sure that you’re manufacturing and you’re tracking the correct revision of that part number, because designs are in flux. Products are in flux, and they evolve over time. And so you might have a rev A, that is in production, you might get some feedback from manufacturing, you might have a rough B, and C, you want to make sure that there is a revision identifier in your part numbers so that you can trace it down the entire supply chain and understand the exact source of where and what this part is.

Aaron Moncur 37:23
Very cool. Okay. Well, let’s see, I’ve just got a couple of more questions. And then we can we can wrap things up here. It looks like build is a relatively new company a couple years older. So I’m sure that you and your team are managing the company very well. Nevertheless, startups are inherently risky ventures and one concern hardware teams may have is the long term sustainability of the company. I mean, teams wouldn’t want to migrate their data to build and start using it and then be disappointed if the company went went under a year or two later, what what assurances are there that build will be a long term viable solution for hardware teams.

Pradyut Paul 38:07
You’re right. It’s definitely a great commitment that we get from companies to believe in our future. So while I can’t make guarantees, the problem is so prominent, and teams aligned with our mission and product so much, that they’re willing to support us in our journey. So of course, as we grow, the risks that you’ve identified becomes smaller and smaller. But I can assure you that we definitely aren’t going away anytime soon. For teams that do have concerns, and you know, they may want to migrate our system or their data into our system. And at some point, they may say, Look, this isn’t the right fit, or whatever it may be, it’s as easy to migrate data out of build as it is to migrate it into build. So at anytime, if companies choose to part way, the process is as painless as migrated it in. And that’s really assuring, because they understand that the pain needs to be solved yesterday, they understand that the solutions that are kind of in front of them aren’t going to be sustainable, they’re either going to be cost prohibitive, the teams aren’t going to have bandwidth to actually implement it. And so the opportunity cost is actually quite high for them to to not make a decision. And so they would rather go with a solution that has the inherent startup risk, knowing that it’ll solve their problems immediately. And we also provide the assurance that look one day, God forbid if we, you know, if we shut down, getting data out of our system is as easy as getting data into our system. And so that process will also be pretty painless.

Aaron Moncur 39:57
Okay, well, what does We all have planned for the future, what what can we expect to see, you know, in terms of new new features or improved features in the next couple of years?

Pradyut Paul 40:08
Right, we’re just the beginning of it. So we look at the hardware development cycle has an ongoing process. So it doesn’t just while it may start in CAD, it doesn’t end at a designer’s workstation. Right. Most of the teams we’re working with are building these are designed these products to get built and manufactured. And so those downstream engagements require some level of support and functionality. And so what our future holds is the integration into those systems like the ERP systems, like different PLM, like the MES systems out there, and also support for other file formats. So, you know, the cat environment is an ever growing ecosystem, there’s a lot of players that are coming in, traditionally, every big company has created these really high walls that don’t allow their system to talk to other systems. But if you look deep enough, they have the infrastructure that allows you to go in and out. And so our goal is to integrate Bill deeply into these downstream systems. And we’re seeing a lot of innovation into some of these ERP systems into some of these new mes and PLM systems. And we hope to integrate with them, we have a very open API that developers and engineers can leverage to automate a lot of functionality and tasks and be able to leverage the data that’s in PDF out of it. And then beyond that, we want to be able to make build even more intuitive for non engineers. So for the people that are reviewing designs, providing the ability to do visual diffs, right. So in software, diffs, are a very useful tool, when you’re looking at what is changing from one commit to the other. And so that ability in a CAD environment is something that we aim to deliver to our customers by the end of this year, for example,

Aaron Moncur 42:22
if I’m not familiar with the acronym diff,

Pradyut Paul 42:25
differences, so visual differences, so being able to compare two CAD models, and visually understand what actually changed God, from the geometry standpoint, that’s correct. And so it makes a really intuitive interface for non engineers to quickly come in and visually see, what are the changes from one version to the other version, traditionally, we’ve had to kind of type up all our changes, right? We go in, and we change the diameter of this hole, and we increase the size of whatever. So now, you know, being able to automate that through a more visual platform where you just kind of checking in Polish, I can pause, and you can just visually see all the changes every single time that you check in a file.

Aaron Moncur 43:10
Well, that’s, that’s awesome. I am super excited to see a new tool for engineers. There, I think there just is not a ton of innovation around the tools that that engineers use, you know, we’re kind of using the same things that we’ve been using for decades at this point. So to see a modern tool like this, it’s very compelling. It’s a very compelling platform. Yeah, thank you again, for spending some time with us and sharing all about build and PDM and simpler ways of managing our CAD data. Producer, is there anything else that we should talk about that we haven’t hit on yet?

Pradyut Paul 43:46
No, I’m really excited to hear that enthusiasm. I think you’re absolutely right. I think they’re, you know, we’ve hit a time in the industry where innovation is prime to disrupt the toolset that engineers have been living on for decades. I think everyone is looking for that facelift for that modern experience. And we’re excited to to help strive towards a future of a more better experience for hardware engineers.

Aaron Moncur 44:15
Awesome. Well, Pradyut, thank you again so much for joining me today. Appreciate all your time, and insight and wisdom that you shared with us.

Pradyut Paul 44:17
Thanks a lot, Aaron.

Aaron Moncur 44:18
I’m Aaron Moncur, founder of pipeline design and engineering. If you liked what you heard today, please share the episode. To learn how your team can leverage our team’s expertise developing turnkey equipment, custom fixtures and automated machines and with product design, visit us at Team pipeline.us. Thanks for listening