Faststream sells three different things, and the commercial structure differs for each. A product is licensed, a solution is delivered against an outcome, and a service is engaged against a scope. Most confusion in early conversations comes from a buyer wanting one and a supplier quoting another.
| Model | You are buying | You receive | Commercial structure |
|---|---|---|---|
| Products | An artefact that exists | IP core, subsystem, hardware or software licence with integration collateral and support | Licence fee, or hardware price. Royalty where volume justifies it |
| Solutions | A business outcome | A working system: hardware, software, integration and commissioning against acceptance criteria | Fixed price against a defined outcome, milestone-based |
| Services | Engineering capability | Work delivered into your programme, to your plan or ours | Fixed price for a defined scope, or a dedicated team by the month |
ASIC and SoC design is a service, not a product. A product is something you receive at the end; a design service is work that gets done. Confusing the two is how scope disputes start.
A defined scope with defined acceptance criteria and payment against milestones. Suits work where the requirement is stable and can be specified. Requires real specification effort before quoting, which is itself usually chargeable.
Named engineers assigned by the month, working inside your programme and to your process. Suits sustained work, unstable requirements, or a capability gap that is specific rather than whole.
Lower non-recurring engineering in exchange for a per-unit royalty. Suits volume products where the customer wants development cost off the balance sheet and Faststream shares the volume upside.
Shared investment, shared IP position agreed in advance. Suits platform work neither party would fund alone, where both have something the other needs.
Faststream builds and runs the capability, then transfers it — team, process, tooling and documentation — to the customer. Suits organisations building a permanent in-house function.
A short paid engagement — feasibility study, architecture review, conversion assessment — producing a written answer and a scope. Frequently the cheapest thing either party can do.
You describe the binding constraint — power budget, cycle time, node, volume, deadline. An engineer replies, not a sales function. If it is not work Faststream should do, that is said plainly, usually with a suggestion about who should.
Signed before detailed discussion. Mechanism-level security detail, specific foundry and node experience, and any discussion of your existing design all happen behind it.
Engineers on both sides, with the constraint on the table. This is where a fixed-price scope becomes possible or is shown not to be.
A short paid engagement producing a written scope, effort estimate and recommendation — including a recommendation not to proceed, which is a legitimate outcome delivered cheaply.
Scope, deliverables, acceptance criteria, assumptions, exclusions, schedule and commercial structure. Assumptions written down, because undocumented assumptions become disputes at acceptance.
Terms agreed, team named, kick-off with the budgets from the proposal carried forward as the thing progress is measured against.
Because it is the question that stalls engineering procurement, and finding out at contract stage that the positions are incompatible wastes a month for both parties.
Body-shop staffing. Supplying engineers by the head against someone else's plan, with no accountability for outcome, is a different business. There are firms that do it well.
Work priced on a fiction. A fixed price against an unspecified scope is a dispute with a start date. Either the scope gets defined first, or the structure is a dedicated team instead.
Approaches that will not succeed. An inspection problem that is really a lighting problem, a conversion for a design whose requirements are still moving, an accelerator where optimised software on existing hardware would close the budget. Saying so before a purchase order costs a piece of work; saying it afterwards costs a customer.
Claims we cannot support. If a tender requires a certification Faststream does not hold or a metric it cannot demonstrate, the honest answer is that it is not a fit.
A product is an artefact you receive — an IP core, hardware or a software licence. A solution is a business outcome delivered as a working system against acceptance criteria. A service is engineering capability delivered into your programme against a defined scope.
A service. A product is something you receive at the end; a design service is work that gets done. This is why ASIC and SoC design sits under System Integration rather than under Products.
Yes, where volume justifies it. Lower non-recurring engineering in exchange for a per-unit royalty moves development cost off the balance sheet and gives Faststream a share of the volume upside.
Foreground IP created for you is normally assigned to you. Your background IP stays yours. Faststream's existing cores, frameworks and tooling are licensed for use rather than assigned, because they also serve other customers.
Usually, and it is normally the cheapest thing either party can do. A feasibility study, architecture review or conversion assessment produces a written scope and estimate — sometimes including a recommendation not to proceed.
Frequently. It usually starts with a structured assessment of the existing design, constraints and verification state, so the plan reflects what is actually true rather than what the last status report said.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.