Is real.
Engineering work is difficult. Software to make it collaborative and productive is probably even more difficult.
Don’t ever try to use onshape professionally
The last month or so I’ve spent working on a few separate problems evaluating and selecting software packages for the engineering group I’m working with.
There are a lot of challenges to selecting CAD, analysis tools, even databases in the modern era. In the end the differences between the higher end packages aren’t stark, but can subtly affect every aspect of the design / build cycle, and also impact overall performance of the team. Some notes:
Getting quotes is a huge pain in the ass. Dassault, Siemens, and others all seem to think you’d rather talk to a 3rd party vendor for three weeks to make a buying decision( like a used car salesman). If a new player, like Tesla did for automotive, could provide high performance CAD / FEA / CAM software with a (buy) button and listed prices it would revolutionize the industry overnight. For now you have to call, email and pester to get a baseline together. Plan for this to take weeks to a month.
Being in a startup is also difficult. Software ain’t cheap (relative to things like salaries), and more often than not, founders haven’t been directly exposed to the pricing of engineering software, and will be taken aback that by the time you outfit an engineer with the software they need, and the infrastructure to support it, you’ll likely have increased their annual cost to the company by 50-80%.
What makes parting with the cash even more difficult is: each engineer won’t be able to leverage the software the same, some are more experienced and can get more value out of it, and some struggle with it always. If you get one CAD or FEA wizard in early who is prolific in their software package of choice, it can pull in schedules by months, reduce drawing or analysis error rates substantially, and generate huge returns for the company.
The real issue with getting the software purchases or tools approved is often short term thinking. In early phases a hardware startup has only really raised enough money to get through preliminary design and prototypes, and isn’t really thinking about production, but production is the point, and engineers are never properly leveraged if they aren’t applying their knowledge to problems many times in excess of their salary (10-100x). While you may think 20k for a cad package is steep, if it can reduce a couple errors in a 3 million dollar production run, you might save ~500k in rework or scrap.
Early on, your engineering team will always be tackling problems well below where they should be in terms of impact, but if you tool up for those low impact tasks (prototyping) and need to quickly transition to production, right when the money is about to run out, you’ll kill the startup in production hell. You don’t normally find this out before you’ve founded your first startup and run it to ground.
This is one of the things that makes hardware real hard. Most VC’s are focused on software startups and don’t understand the immense cost differences between making hardware and software products. This leads the conventional startup wisdom on burn rates and series raises to be shaped by software development cost models. These are maybe 4-10x less for a given size group of hardware engineers pushing to get to pilot production.
The toys are real and expensive, and you have to buy upfront to learn the same lessons that happen on free clock cycles for computational work. This also makes the advice you get as a founder often wrong. Despite best intentions, your investors may not understand your development costs, timelines or risks adequately, and due to the aforementioned predilection towards software world, they’ll tend to think you can get across the finish line and to the next raise without a substantial departure in capital from a software startup.
To combat all of this, founders should try REAL HARD to understand costs upfront before initial raise. You’re David and the entire industry you’re trying to displace is Goliath, so you’re going to want a damn good sling and rock. You should do the research and understand what a really good tool set looks like, then try to get the best setup you can for your team. Don’t skimp on the engine in your car.
Don’t compromise on the tools, as they’re going to be the force multiplier for every solid technical hire you make, and also allow you to attract an even higher performing group of talented people. There is some risk in buying specialty tools too early and pivoting away from that vertical before reaching production, but normally early on you’ll want to follow cheaper subscription models for software tools rather than buying them outright, so the ding on picking a wrong specialty tool isn’t huge.
Remember one of the key questions you ask when forming a startup is “why is now the right time for this” and in many modern startups, part of the why will be ” the last time this problem was tackled, a room full of computers and drafts-people were required to get a product out the door, now one engineer can do all of that with software in a short period of time” Get that good software. Tackle the world.