Choose advisory
Use it when leadership needs to prioritise opportunities, test feasibility, or set an investment and governance boundary.
AI delivery decision guide
AI advisory, custom development, or FDE?
Choose the engagement model by the uncertainty you need to resolve—not by which service label sounds most advanced.
By Onyx Devs Lab · Published · Updated
AdvisoryResolve a decision
Custom buildDeliver a defined system
FDEResolve and deliver in one field loop
The decision boundary
The three models solve different kinds of uncertainty.
Choose custom development
Use it when users, workflow, integrations, and acceptance criteria can be defined before implementation.
Choose FDE
Use it when the valuable problem is known but the correct intervention must be learned from real operations.
Signals you chose the wrong model
A mismatch appears early if the engagement is measured against the wrong unit of success.
Advice without a decision
A strategy project is incomplete if nobody owns the resulting choice and next gate.
Build without a stable boundary
A fixed specification fails when core requirements change as operators see working software.
FDE without field access
Embedded delivery cannot work without operator participation, evidence access, and an accountable outcome owner.
Compare the three engagement models
Choose by the uncertainty that must be removed and the evidence the engagement must produce—not by the most impressive label.
| Decision test | AI advisory | Custom development | FDE |
|---|---|---|---|
| Primary uncertainty | What should we do, and should we invest? | How should we build the defined system? | What intervention will work in the real operating environment? |
| Choose when | Opportunity, feasibility, governance, or sequence is unclear. | Users, workflow, interfaces, constraints, and tests can be specified. | The valuable problem is known, but the solution boundary must be learned in the field. |
| Accountable output | A signed decision with evidence, owner, and next gate. | A tested system against agreed scope and acceptance criteria. | A measurable operating outcome and a production-capable system. |
| Acceptance evidence | Recommendation, rejected options, assumptions, and next-stage gate. | Traceable functional, quality, security, and operational test results. | Baseline-to-outcome evidence, operator adoption, failure handling, and readiness gates. |
| Change mode when | Scope stabilises → custom development; field discovery is required → FDE. | Field evidence invalidates the specification → FDE; investment changes → advisory. | Uncertainty falls and ownership is clear → stable product delivery or managed operations. |
How to use the decision map
Name the decision
State what must be decided or changed and who owns it.
Score uncertainty
Separate uncertainty about value, workflow, data, integration, and adoption.
Choose the smallest complete model
Buy only enough engagement to resolve the material uncertainty.
Set an exit gate
Define evidence for scaling, changing course, or stopping.
Frequently asked questions
Can an engagement move between models?
Yes. Advisory can produce a defined custom build, while a build can become an FDE loop if field evidence reveals that the original boundary was wrong.
Is FDE always more expensive?
Not necessarily. It involves broader ownership, but can avoid the cost of building against an inaccurate specification. Commercial scope still depends on duration, access, and delivery risk.
Can we start with a short assessment?
Yes. A bounded assessment can clarify whether the next step should be advice, a build, an FDE intervention, or no project.
Start with one concrete operating problem.
We will first clarify the workflow, evidence, data boundary, and outcome standard before recommending the next step.
Contact Onyx