When You Should NOT Build an ASIC (And What to Do Instead)

ASIC is often framed as the “endgame” of hardware development.

Lower unit cost. Better power efficiency. Full control over silicon. It’s easy to assume that moving to ASIC is always a sign of maturity and success.

That assumption causes expensive mistakes.

In reality, some of the worst ASIC projects fail not because the execution was poor, but because the decision itself was premature. Knowing when not to build an ASIC is just as important as knowing when to build one.

This article explains the most common situations where ASIC is the wrong move and what experienced teams do instead.

1. Your product definition is still moving

ASIC punishes uncertainty.

If core requirements are still changing frequently, every decision becomes provisional and every late change multiplies cost and schedule risk.

Warning signs include:

• Interfaces still being debated
• Performance targets shifting release to release
• Features added to satisfy internal stakeholders rather than customers

In this phase, flexibility is more valuable than efficiency.

What teams do instead:

• Stay on FPGA or SoC
• Use prototypes to validate real usage
• Delay ASIC until the core architecture stabilizes

2. Volume is uncertain or fundamentally low

ASIC economics rely on amortization.

If realistic volume is low or highly uncertain, NRE becomes a permanent burden rather than an investment.

This is especially true when:

• Sales forecasts vary by an order of magnitude
• The business model has not proven repeatability
• The product is a niche or custom solution

What teams do instead:

• Optimize FPGA cost and power incrementally
• Use ASSP or off-the-shelf SoCs
• Re-evaluate ASIC once demand is proven

3. Time-to-market dominates everything

ASIC timelines are unforgiving.

When market windows are narrow or competitive pressure is extreme, the risk of missing the window can outweigh the long-term benefits of custom silicon.

This often applies when:

• A first-mover advantage matters more than margins
• Customer commitments require near-term delivery
• Software ecosystem maturity is the bottleneck

What teams do instead:

• Ship on FPGA or SoC first
• Gather market feedback
• Plan ASIC as a second-generation product

4. Your team or partners are not ready

ASIC is not just a technology decision. It is an organizational one.

Projects fail when teams underestimate the coordination required across architecture, verification, physical design, test, manufacturing, and program management.

Warning signs include:

• No clear technical owner
• No experience with silicon signoff
• Unclear decision authority

What teams do instead:

• Partner with experienced design houses
• Start with feasibility or MPW
• Build internal knowledge gradually

5. Power, cost, or performance are “nice to have,” not mandatory

ASIC should solve a hard problem.

If the motivation is incremental improvement rather than necessity, the return rarely justifies the risk.

This applies when:

• Power savings are helpful but not required
• BOM reduction is desirable but not critical
• Performance targets are already met

What teams do instead:

• Focus on system-level optimization
• Delay ASIC until constraints tighten
• Treat ASIC as optional, not inevitable

6. You are trying to solve a business problem with technology

Some ASIC decisions are driven by organizational pressure rather than product need.

Common examples:

• “Our competitors have custom silicon”
• “ASIC will impress customers or investors”
• “We want to look more advanced”

These are weak reasons.

ASIC amplifies strong product fundamentals. It does not create them.

What teams do instead:

• Align ASIC decisions with clear business drivers
• Validate customer value before committing
• Separate signaling from substance
•  

What successful teams do differently

Teams that succeed with ASIC do not rush.

They:

• Accept “not yet” as a valid outcome
• Use prototypes and MPWs strategically
• Revisit the decision as conditions change

The key is not avoiding ASIC. It is choosing the timing deliberately.

Why this article exists

Many sites only explain why you should build an ASIC.

Experienced engineers know that credibility comes from acknowledging when you should not. This is also why vendors trust leads that come through structured decision tools rather than generic inquiries.

What to do next

If any of these scenarios feel familiar, that does not mean ASIC is off the table forever.

It usually means the next step is clarification, not commitment.

Before investing further time or money, it helps to get a clear, non-sales answer to a simple question.

Next step

Run the 2-minute ASIC or Not? Decision Wizard to see whether ASIC makes sense for your product now, later, or not at all, and what you should focus on next.

👉 /asic-or-not