How to Start a CAD Automation Project: 4 Steps That Work

I start from the problem, not the tool. The first thing to do is not to write code but to measure two things:

• Which task repeats, and how often?
• Where exactly is time lost in the current process?

These sound simple, but the answers are often surprising. A team says "modelling takes too long"; when you measure, the real loss turns out to be in manually fixing drawing output, not in modelling. A project that automates the wrong place produces no felt gain, however flawless the code.

How to keep a two-week log

Measurement does not have to be complex. One table, a few columns, two weeks:

What matters is not precision but finding the right item. Rounding minutes will not change the outcome; picking the wrong task changes everything.

The return of automation is time saved times repetition count. Perfectly automating a rarely repeated task produces less value than roughly automating a frequently repeated one.

Three habits that ruin measurement

Estimating from memory. "It probably takes about an hour a day" is not a measurement. Once logged, most estimates turn out to be double or half.

Sampling the worst day. People remember the most annoying task, not the most time-consuming one. Logging ordinary days for two weeks corrects that bias.

Counting only the "doing" time. The waiting around the task — finding the file, confirming the right revision, waiting for information — is often longer than the task itself. If automation does not touch that waiting, the gain stays on paper.

The second step is to look at the list from step one and make one distinction explicitly: what goes to software, and what stays with a person.

Skip this and the project breaks in one of two ways:

1. Scope keeps growing. Every exception is added to the software, the system turns into a pile of rules, and maintenance becomes impossible.
2. Nobody trusts it. If it is unclear where the automation begins and ends, users re-check its output every single time — which hands the saved time straight back.

A practical distinction that works: work that can be turned into a rule goes to software; work that requires judgement stays with a person. Computing a profile length from a parameter is a rule. Deciding whether a customer's special request fits the standard production flow is judgement.

Put the boundary in writing

Where the boundary sits matters, and so does the fact that it is written down. A single page is enough, with four headings:

• The automation does this: the input list and the produced output list, itemised.
• The automation does not do this: the things that will be asked for often but are deliberately out of scope.
• It stops and hands over when: a parameter is missing, a dimension is out of range, a product family is unrecognised.
• Who may change this document: the owner of scope decisions.

Every later exception request is judged against this page. Without it, every request looks reasonable and the scope grows silently.

Do not turn exceptions into rules

The most common decay I see in the field: a one-off exception made for one customer enters the rule engine as an if. Six months later there are twenty such branches and none of them explains why it is there.

Practical guard: put exceptions in data, not code. A configuration table keyed by product family does the same job but stays readable and is easy to remove.

The third step is where code begins — but not all of it. You pick a small piece with a measurable result.

The test of a well-chosen pilot: when it is done, whether it worked should not be open to debate. "It feels better" is not a result. "Preparing the same frame went from 40 minutes to 6" is a result.

The pilot does one more thing: it breaks assumptions early. The most expensive mistakes in automation projects come from discovering, six months in, that production data is not in the shape you assumed. A small pilot shows that in week two.

Five properties of a good pilot

1. End to end, but narrow. One product variant, from parameter entry to production output. A pilot that automates only the middle of the chain hides the real bottlenecks.
2. On real data. Not a cleaned sample file — a file from the field. Dirty data is the pilot's real exam.
3. With one user. Handing it to five people at once blurs the feedback.
4. Time-boxed. Four to six weeks. A pilot with no end date is not a pilot; it is an open-ended project.
5. Success criterion written first. Something like "continue if preparation time drops by 40%." A criterion set afterwards makes every outcome look like success.

The one question to ask when a pilot ends

Not "did it work?" but: would the person who used to do this by hand refuse to go back? If the answer is no, something is wrong regardless of the numbers — usually the verification load was underestimated.

The final step is expanding scope — but with evidence, not guesses.

As the pilot proves itself in the field, you add the next variant, the next product family, the next output type. Before each expansion, the same question: which of the loss items measured in step one does this address?

Without that discipline, automation projects bloat with features nobody uses. Every unused feature is not just wasted time; it is a permanent maintenance cost.

A simple score for expansion order

Three factors, multiplied:

The product of the three predicts what should come next surprisingly well. The third factor matters most: automating a task whose rules have not settled is trying to pin down a moving target.

Describing a method means naming what it excludes, not only what it covers.

• Decisions that require judgement. I use AI tools for speed and iteration; architecture decisions, verification and test load stay with me. The code-side version of this line is in writing a SolidWorks add-in with AI.
• Rarely repeated tasks. Automating something done once a month usually costs more than doing it by hand.
• Processes that have not settled. First the process stabilises, then it gets automated.
• Outputs with no verification. If no deterministic rule can check an output that goes to production, that step is not automated.

Once measurement and boundary are settled, the tool decision becomes mechanical. Rough thresholds:

I cover the technical difference between these three routes in macro, API and add-in, and where Python ends and C# begins in SolidWorks automation with Python.

How large a team do you need to start an automation project? One developer and one user are enough for the pilot phase. Team size should grow only after scope is proven in the field; a crowded team at the start stacks parallel work on unverified assumptions.

How do you decide whether a task is worth automating? Multiply time saved by repetition count, then subtract maintenance load. If the monthly gain does not cover development and maintenance within a reasonable window (typically six months), the task stays manual. The measurement method is in measuring automation gains.

How long should a pilot project run? Four to six weeks. Shorter does not break assumptions; longer stops being a pilot. The end date and the success criterion must be written down before it starts.

What is the most common mistake in automation projects? Choosing a tool before measuring. A close second: not writing the automation's boundary down — without it, every exception request looks justified and scope grows silently.

Which language should I choose for CAD automation? Python for exploration and validation, C# / .NET for permanent flows that go to production. For one-off small jobs a VBA macro is still the fastest route. The decision follows from who will maintain it and how long it will live.

Which metrics should track an automation's success? Four are enough: preparation time, rework rate, first-time-right percentage, and the number of errors that escape to production. Measuring only production time makes the gain look bigger than it is.

An automation project's success is decided by the questions asked in the first week, not by the library chosen on day one:

Tool selection comes after these four answers — and by then it is usually obvious anyway.