What we would tell you before you hire anyone.

Generative design programs rarely die in the optimization. They die in the handoff — the moment the geometry leaves the design tool and reaches the person who has to make it. By then the celebration email has already gone out and the weight number is already in the deck, which makes the failure harder to admit.

How it breaks

Workholding. Organic geometry is often impossible to clamp while it's being cut. If the optimization ran without a workholding constraint, the result is manufacturable in theory and unclampable in practice.
Machine mismatch. A structure optimized for 5-axis isn't the same structure a 3-axis shop can produce. If you have to buy a machine to realize the saving, the business case is usually gone before the first chip is cut.
Toolpath regeneration. If the CAM work happens after the optimization is signed off, it becomes a rework loop with nobody owning it — and the schedule absorbs the cost.

The fix is ordering, not technology

Constrain the optimization with the process instead of validating against it afterwards. Practically that means the machine capability, workholding approach and material are inputs to the generative run, and the same model produces the toolpath. Then the geometry that leaves the loop is the geometry that gets cut.

A useful side effect: when the optimization is constrained toward the process, the results often need less fixturing than the original design. That cost reduction usually never appears in a generative design case study, and it's frequently larger than the material saving.

These get sold as one thing and they aren't. Choosing wrong is the most common way a design automation budget disappears without a result.

Parametric: you know the shape family

The topology is settled; what varies is dimensions and rules. Change a parameter and the drawing adjusts itself. It's fast, predictable, cheap to maintain, and, this matters more than it sounds, explainable to a quality auditor. There's no model to validate, only a rule to check.

Generative: you know the objective, not the shape

You have a load case, a mass target and a set of manufacturing constraints, and you don't know what the structure should look like. This is where topology optimization earns its cost — and where it needs a CAE loop, because nobody can sign a shape they haven't simulated.

The decision rule

If a parametric rule produces the same geometry as a trained model, use the rule. A large share of "we want AI in our design process" requests are parametric problems wearing an AI costume, and the parametric answer ships in weeks instead of quarters.

Generative is worth it when three things are true at once: mass or performance is the objective, the topology is genuinely open, and you can validate the output. If any one of those is missing, the honest answer is to skip it.

Most cost is locked in before anyone asks the factory a question. By the time a design reaches a formal review, the decisions that determine unit cost, wall thickness, material, part count, assembly sequence, are already load-bearing in someone's mind, and changing them now feels like admitting the last month was wasted.

The fifteen-minute version

Before the review, put the model in front of the person who will make it and ask five things: what is the wall thickness at its thinnest, what draft does this have on the vertical faces, how many parts is this and how many could it be, what is the tolerance on the two dimensions that matter, and what does this look like from the customer's hand.

Those five questions surface the majority of cost and rework risk. Not because they're sophisticated, but because they're usually asked in month four instead of week two.

Why teams skip it

Because the design isn't finished, and asking feels premature. But the questions are cheaper to answer on a rough model than a finished one, and the answers change the design rather than judging it.

The practical fix is scheduling: put a manufacturability checkpoint on the calendar before the design review, not after, and give it the authority to change the model.

A digital twin isn't a rendering project, and it isn't a one-time deliverable. It's a decision-support system that has to be maintained as the plant changes. Priced as a visualization, it looks expensive. Priced against the decisions it changes, it's usually cheap.

What drives the cost

Three things, in order: the quality of the input data, whether the site is greenfield or brownfield, and how far you want to go on live status. A brownfield site needs scanning and reconciliation against old drawings that may not be true. A greenfield site is cheaper to model but the model has to absorb design changes weekly, which is a different kind of effort.

What it should replace

The honest test is whether the twin removes a decision-making cost you're already paying: the layout meeting that keeps recurring, the commissioning surprises, the "ask the engineer who has been here eleven years" dependency, the throughput argument that can't be settled with data.

If none of those exist, you don't need a twin yet. If two of them do, the business case usually writes itself in one page.

The part people underestimate

Maintenance. A twin that stops being updated is worse than no twin, because people keep trusting it. Budget for the update loop at the same time you budget for the build.

These get compared on rate, which is the one dimension where they're closest and the one that matters least. One buys capacity. The other buys outcomes. Choosing the wrong one is how programs fail while everyone agrees the team is good.

What staff augmentation buys

Named people, on your tools, taking direction from your leads. It's the right purchase when the work is defined, the priorities are stable, and the constraint is genuinely headcount. It's the wrong purchase when nobody has decided what to build, because you are now paying senior rates for a coordination problem you still own.

What an embedded pod buys

A technical lead who is accountable for output, not hours, and who will tell you when the backlog is wrong. That's a different contract: you're buying judgment, not capacity, and it costs more per person precisely because it includes the part that keeps the program from drifting.

The test

Ask one question: if a senior engineer told you next Monday that the current plan is wrong, who would act on it? If the answer is "our side, eventually" — augmentation. If you want that conversation to be someone's job — embedded.

Every program has gates. The ones that get scheduled are the visible ones — design review, tool kickoff, first article. The ones that decide whether the program succeeds are usually unscheduled, which means they happen late, informally, and without an artifact.

The five, and the artifact each should produce

Intent — a one-page brief stating target cost, volume, and the three features that can't be compromised. Without it, every later trade-off is an argument.
Manufacturability — a written DFM report with costed recommendations, including the ones that require a design change.
Physical proof — parts made on the process closest to production, with a test log.
First article — a dimensional report against the drawing, with cosmetic criteria agreed before the steel was cut.
Ramp — a control plan and an escalation path handed to whoever runs production.

Why the artifacts matter more than the meetings

A gate with no artifact is a status update. The document is what makes the gate real, because it's the thing that gets reopened when someone asks why a decision was made. Teams that keep the artifacts recover from problems in days; teams that don't, re-litigate them for weeks.

The instinct is to buy PLM because it's the bigger word and the board has heard it. The usual outcome is an eighteen-month implementation that captures a process nobody has settled on yet.

What each one solves

PDM solves one problem: there's exactly one controlled version of every drawing, model and revision, and everyone knows which one it's. That's it. It's unglamorous, it's cheap relative to PLM, and it's the prerequisite for everything else.

PLM solves a different problem: requirements, BOM structure, change control and release process across a product's life. It only works if the underlying data is already controlled — otherwise you're automating the distribution of versions nobody trusts.

The order that holds up

PDM first, always. Run it until engineers stop emailing STEP files and start treating the system as the source. Then, when change control becomes the actual pain — usually when there are multiple variants or a regulatory submission — PLM has something to govern.

Pre-revenue teams that buy PLM first usually end up buying PDM anyway, two years later, with less patience.

Every engagement ends, including the good ones. What determines whether the client remembers it well isn't the quality of the deliverable. It's whether they could operate it without calling you.

What gets used

Not the two-hundred-page manual written at the end by someone who wasn't on the project. What gets used is a short document that answers: where the code and infrastructure live, how to deploy, what the three most likely failures are and what to check first, who decided the non-obvious architectural choices and why, and what we would do differently next time.

The test we apply

We ask the client's engineer to deploy the system from the documentation alone, without asking us anything. Whatever they have to ask becomes a section. It's an uncomfortable exercise and it's the only one that produces a document somebody actually reads.

Why firms avoid it

Because a client who can leave is a client who might. That's a real commercial risk and pretending otherwise is dishonest. The answer isn't to hide the documentation. It's to be good enough that leaving isn't attractive.