The pattern
Industry-specific CAD rarely fails on engineering. It fails when practitioners quietly go back to their old method — because the tool is slower for the everyday job, or because it will not let them do something the job requires. Both are scoping decisions, not coding ones.
These are the recurring lessons from building software for specialised manufacturing domains — the things worth knowing before scoping rather than after launching.
1. The domain rules are the product
The drawing canvas is commodity engineering. What makes vertical CAD valuable is that it knows the trade — bend allowances, joinery standards, seam allowances, edge clearances.
Get these from practitioners, not from standards. Shops routinely use values that differ from published figures, for reasons grounded in their specific machines and materials. Encoding the textbook value produces software that is confidently wrong in the eyes of the people who must trust it — and trust lost in week one is not recovered.
2. Make the rules configurable
Hard-coding domain values guarantees the tool fits exactly one workshop. Different shops have different machines, materials and tolerances.
- Bend allowance tables that a user can edit.
- Material libraries with per-shop properties.
- Standard sizes reflecting what that shop actually buys.
- Tolerance and clearance defaults, adjustable per customer.
This also lets domain experts refine the software without a developer, which matters enormously for long-term usefulness.
3. Warn, never block
The instinct is to prevent users from producing unmanufacturable designs. In practice there is always a job where the rule does not apply — a special material, a customer requirement, a technique the shop has developed.
A tool that refuses the exception gets abandoned for the rule as well. Practitioners do not maintain two workflows; they pick one, and it will be the one that never blocks them.
4. Output matters more than input
Adoption is usually decided by what comes out, not by how pleasant the drawing is:
| Output | Why it drives adoption |
|---|---|
| Cut list | Removes transcription and its errors |
| Nested sheet layout | Direct material saving, easy to measure |
| Machine file | No manual preparation step |
| Costing | Quote produced from the drawing itself |
| Shop drawing in familiar format | The floor can read it without explanation |
5. Respect the conventions that already exist
Every trade has established drawing conventions — how dimensions are shown, what symbols mean, how sheets are laid out. Software that produces technically correct drawings in an unfamiliar style creates friction on the shop floor, where the person reading it was not part of the software decision.
6. Interoperate from day one
- Import what customers send — usually DXF, sometimes PDF, occasionally a native format.
- Export what machines need — the specific dialect your cutting or bending equipment expects.
- Produce PDFs for everyone who just needs to look at it.
A tool that cannot open the customer's file is a tool with an extra manual step at the front, which undermines everything downstream.
7. Design for the actual workstation
- Offline operation. Shop-floor connectivity is unreliable.
- Modest hardware. The machine will not be new.
- Readable in poor lighting, with high contrast and adequate text size.
- Keyboard-driven for repeated tasks — experienced operators are fast with keys and slow with menus.
- Resilient to being closed abruptly, because it will be.
8. Involve practitioners throughout, not at the end
- Watch the current process before designing anything. What people describe and what they do differ.
- Identify the common job — optimise that, not the impressive edge case.
- Prototype early and put it in front of the person who will use it.
- Measure against the old method on a real job, timed.
- Iterate on friction, which practitioners will report accurately if asked specifically.
The test that predicts adoption: time an experienced practitioner doing a routine job their existing way, then with the new tool. If the new tool is not faster on the common job, it will not be adopted regardless of what it does for complex ones. Complex jobs are rare; the common job is what fills the day.
9. Plan for the knowledge to outlive the project
The domain rules you encode are frequently the most valuable thing the software contains — often knowledge that existed only in a few heads. Document where each rule came from and who validated it. When someone questions a value in three years, that provenance is what lets you answer.
10. Scope by excluding
Vertical CAD is viable because it excludes almost everything general CAD does. Every feature added "because CAD usually has it" moves you toward competing with mature general tools on their terms — which is not a competition a focused vertical tool wins.
Building CAD software for a specific trade? Tell us the industry and the rules your practitioners apply. See our CAD engineering service, 2D CAD for niche industries, and add-in vs standalone.