Their exact problem, what they built, and what happened next

By Prasath | ScriptedCAD | https://scriptedcad.com

Most engineers assume CAD automation is something companies buy. A product someone else builds. A tool IT installs. These three engineers assumed the same thing. Then they got frustrated enough to try something different. Here is what each of them actually did, what they built, and where they ended up.

Engineer 1: Peter Brinkhuis (Netherlands) — From Mechatronics Engineer to Product Founder

Peter spent 5 years as a mechatronics engineer in the Netherlands, designing complex custom machines at companies including VIRO and Imotec. His projects ranged from knee replacement surgery instruments to tensioners for underwater pipe laying. Real engineering. Complex problems. Small teams.

The problem that changed everything was not a hard design challenge. It was the drawings.

On every project with hundreds of drawings, the same questions came up every single time. Which template? Which sheet format? Which views? Small decisions, but multiplied by hundreds of drawings, on every project, indefinitely.

His response: write a business plan, quit his engineering job, teach himself professional software development, and launch CAD Booster in 2017. His first product was Drew, a SOLIDWORKS drawing automation tool that handles the setup decisions automatically. He later built a Fastener Models library and Lightning during the 2020 lockdown. CAD Booster is now a software company built entirely on the SOLIDWORKS API.

• Peter's full story: cadbooster.com/about-cad-booster
• Follow him on LinkedIn: linkedin.com/in/peterbrinkhuis
• CAD Booster on GitHub: github.com/CAD-Booster

Engineer 2: Ramu Gopal (Bangalore, India) — From Mechanical Design Engineer to CAD Automation Specialist

Ramu has 10+ years as a mechanical design engineer in Bangalore. B.E. in Mechanical Engineering from Government College of Engineering, Bargur. No computer science degree. He works in SolidWorks, focuses on engineering design and workflow optimization, and is based in the exact environment most Indian design engineers know.

His pain: managing custom properties across dozens to hundreds of SolidWorks models. Small changes consumed entire afternoons. Large changes ran into the next day. The same manual process, every project, every time.

He built a Custom Properties Batch Manager: a tool with proper workflow tracking, progress display, and diagnostic logs. He documented the entire build and published it on Medium in February 2026. Then in March 2026, he went further and published how he built an Automated Engineering Drawing Comparison tool using Computer Vision and OCR, a system that checks drawing outputs automatically.

Engineer 3: Artem Taturevych (Australia) — From Engineering Team Lead to Ecosystem Builder

Artem has 17+ years in CAD automation development. He previously led software teams at Central Innovation, building engineering design validation tools for aerospace, automotive, and energy clients. He is a certified SOLIDWORKS Professional and a SOLIDWORKS Champion.

In 2020, he founded Xarial and did something that most automation engineers do not do. Instead of building tools for individual companies, he built infrastructure for the entire community.

• xCAD.NET: an open-source framework for building SOLIDWORKS add-ins in C# and .NET. Any developer building automation tools now has a foundation instead of starting from zero.
• CodeStack: a free library of hundreds of SOLIDWORKS API code examples. The resource thousands of engineers search when they get stuck on the API.
• CAD+ Toolset: a free automation tool for SOLIDWORKS covering property management, drawing automation, and more.

• See his work: xarial.com
• Follow him on LinkedIn: linkedin.com/in/artem-taturevych
• GitHub: github.com/artem1t

The Pattern All Three Share

Three engineers. Three different countries. Three different outcomes. One pattern underneath all of them.

• Each one faced a specific, recurring problem that took too long
• Each one chose to fix it instead of accept it
• Each one learned exactly what that specific problem required, not a CS degree, not years of preparation
• Each one published or shipped what they built

The career transformation was not the plan. It was the consequence of building.

The Three Paths Out

These three stories show three different outcomes from the same starting point.

• Path 1 — Stay and go deeper: Keep your engineering role. Build internally. Get recognised. Transition your title and your pay. Ramu shows this path.
• Path 2 — Build a product: Take what you know about a specific engineering pain point and build a tool other engineers pay for. Peter shows this path.
• Path 3 — Build for the ecosystem: Go open source. Build the infrastructure. Become the resource the community searches. Artem shows this path.

What To Do Next

Pick one problem you solve manually more than twice a week in your current CAD tool. That is your starting point. Not a career plan. Not a portfolio. Not a certification. One problem. One attempt at automating it. That is how all three of these engineers started.

The salary gap between a CAD design engineer and a CAD automation developer in India is documented at 2 to 3 times for the same years of experience. The skill gap is the only thing separating them. LinkedIn India named workflow automation and API integration as top rising skills for 2026. 74% of Indian recruiters say they cannot find qualified automation talent right now.

You do not need to be the one who cannot be found.