When is building in-house the right choice?
If your organisation has a standing AI engineering team, an eighteen-month horizon and a highly specific need, building remains defensible. We would rather say so.
Comparison
Both approaches are legitimate. They do not solve the same problem of calendar, maintenance and control. This page helps you identify which one is yours.
Every technical choice stays in-house: languages, hosting, security policy, release cycles.
Connectors and workflows can match the detail of applications already in production.
No licence contract, no third-party roadmap, no product end-of-support risk.
The team that builds the stack remains the reference. The knowledge stays in the organisation.
The observed time to a first industrialised process is on the order of 6 to 12 weeks, versus 9 to 18 months for a stack built from scratch.
LLM engines, patches, connector changes: absorbed by the platform, not by a permanent in-house team.
Code control is not total. Reversibility and code delivery can be provided for contractually.
Each extra process reuses the stack already deployed. Unit cost falls; in-house, stack maintenance remains a fixed load.
Chain several LLMs and tools in one execution, with a technical receipt per run.
Link each assertion to its sources and a confidence score.
Present sources, confidence and validation status in an exportable view.
Draft → Reviewed → Approved, with identities recorded at each stage.
Keep who saw, changed, validated, and when.
Replay a past run (versions, parameters, inputs) under the same conditions.
Identify and handle PII before it enters a model.
Control where data and logs are stored (EU, private, on-premise).
Freeze prompts, policies and models used for a given run.
Track cost per execution, not only per seat.
SSO, roles and entitlements on the validation chain.
Feed back what was approved to lower the cost of later runs.
Each of these elements is feasible. The issue is cumulative lead time and maintenance over the years.
| Criterion | Internal development | NEXA |
|---|---|---|
| Time to first process in production | 9 to 18 months | 6 to 12 weeks |
| Maintenance | Permanent dedicated team | Included |
| LLM engine evolution | On you | Absorbed by the platform |
| Code control | Total | Partial, code deliverable under contract |
| Upfront cost | High, spread over time | Moderate |
| Cost at three years | Rising | Falling per process |
Time to first process in production
Maintenance
LLM engine evolution
Code control
Upfront cost
Cost at three years
If your organisation has a standing AI engineering team, an eighteen-month horizon and a highly specific need, building remains defensible. We would rather say so.
Multi-engine orchestration, per-execution traceability, evidence panel, validation chain, audit log, execution replay, personal-data detection, data residency, versioning, cost steering, identity management, capitalisation of validated patterns. Each of these is feasible. The issue is cumulative lead time and maintenance over the years.
For an in-house stack, 9 to 18 months is a common order of magnitude before the first process in production. On NEXA, the first industrialised process typically sits between 6 and 12 weeks. These are observed durations, not a universal contractual commitment.
If your organisation has a standing AI engineering team, an eighteen-month horizon and a highly specific need, building remains defensible. We would rather say so.
A walkthrough on a process your teams already run. Then a framing session to size the first deployment.