- Usual largest line
- Integration
- Early check
- Does each tool have an API?
- Fallback
- A structured record a person accepts
Why the demo lies
A demo answers from a sample document and writes nowhere. A production system reads your live stock, checks a real diary, writes to a CRM and reports into a sheet somebody already uses. Every one of those is a contract with another piece of software.
The model is the cheapest part of the system. The wiring is the project.
The first question: does it have an API?
For each system in the path, find out whether there is a documented API, what it allows, and whether your licence tier includes it. That last one catches people: the API exists but costs an upgrade.
Where there is no API, the honest options are a structured record a person accepts, a scheduled export, or replacing the tool. Nexvix names which one in the scope document.
Reads are easy. Writes are the risk.
Reading data is usually simple. Writing means deciding what happens on failure, on duplicate, and on partial success, which is where an integration quietly corrupts records if nobody designed it.
- What happens if the write fails twice?
- What identifies a duplicate?
- Who is told when a record is rejected?
- Is there an audit entry per write?
Sequence the project accordingly
Prove the integrations early, on real credentials, before the clever part is built. A week spent confirming that the CRM accepts what you plan to send is the cheapest week in the project.
Nexvix does this at stage three, and it has ended more than one scope in a better place than it started.