What your team may want to confirm
- What the engagement is intended to produce, and by when.
- Where the defined decision points sit, and what happens at each one.
- How scope changes are agreed and recorded.
Enterprise readiness
A different delivery model should still be easy to evaluate.
Enterprise buyers should not have to infer how the engagement works. The delivery model should be understandable before the commitment is made.
Diligence matrix
Twelve areas sophisticated buyers should be able to examine.
These are areas of evaluation, not universal contractual outcomes. What applies to a given engagement is established in the agreement for that engagement.
What your team may want to confirm
- Who is accountable for delivery on both sides.
- How engineering involvement is structured for the work in question.
- How continuity is handled if people change.
What your team may want to confirm
- Which artifacts are produced as part of the engagement.
- What is considered complete, and who confirms it.
- Where deliverables are stored and handed over.
What your team may want to confirm
- Which architectural commitments are made early and which stay reversible.
- How the work integrates with existing systems of record.
- What is required to maintain or extend the system internally.
What your team may want to confirm
- Which controls apply in the target environment.
- How access, secrets, and environments are managed during delivery.
- How security review is scheduled relative to release.
What your team may want to confirm
- Which models are used, where, and for what purpose.
- What data reaches a model, and what does not.
- How AI-assisted work is reviewed before it ships.
What your team may want to confirm
- How ownership of code and artifacts is treated in the agreement.
- Which third-party components are used and under what licences.
- How repositories and environments are held during and after delivery.
What your team may want to confirm
- Which environments exist and who controls each one.
- Who performs releases, and under what approval.
- How rollback and incident handling are agreed.
What your team may want to confirm
- What documentation accompanies the software.
- Where architectural rationale is recorded.
- How operating knowledge is captured as the work proceeds.
What your team may want to confirm
- Whether capability transfer forms part of this engagement.
- Which practices and patterns are intended to remain internally.
- How transfer is evidenced rather than assumed.
What your team may want to confirm
- What support, if any, follows delivery.
- How issues are raised and prioritized.
- How support responsibilities shift over time.
What your team may want to confirm
- What an orderly exit would require in practice.
- Which dependencies would remain, and which would not.
- How repositories, documentation, and environments transfer.
Build your diligence list
Questions a serious enterprise buyer should ask any technology delivery partner.
Choose the areas your process needs to cover. The list assembles on screen — copy it, print it, or take it into a review. Use it on us, and use it on everyone else.
12 questions · 3 areas
Security
- What security responsibilities remain with the client?
- How are controls defined relative to the intended operating environment?
- How are access, secrets, and environments managed during delivery?
- When does security review happen relative to release?
Ownership
- Who controls the source code during and after delivery?
- What rights and responsibilities are defined contractually rather than implied?
- Which third-party components are used, and under what licences?
- What happens to repositories and environments at transition?
Deployment
- Who can deploy the next release?
- What environments and approvals are required?
- How are rollback and incident handling agreed?
- What operating knowledge must remain with the client?
How engagements are shaped
Reduce the cost of being wrong before increasing the size of the commitment.
- Commercial structure
- Where appropriate, engagements can be structured in stages with defined outcomes and decision points, allowing the initial commitment to remain comparatively small and reversible.
- Ownership and IP
- Our engagements are designed around client control, portability, and clear ownership terms appropriate to the work, settled in the agreement rather than implied.
- Capability transfer
- Where capability transfer is part of the engagement, responsibilities and deliverables are made explicit rather than left as an informal promise.
- Security review
- Septiva can support security and AI-specific diligence, including questions about model use, data handling, and applicable controls.
- Transition
- Septiva favors architectures, documentation, repositories, and working practices that preserve practical client options and reduce unnecessary dependency. Dependency should be earned through value, not engineered into the relationship.
Evaluation sequence
A typical path from first conversation to first evidence.
An executive conversation about one real problem, a written view of the delivery model, a small first engagement with defined evidence, and a decision made on what actually changed.
- 01Real problem
- 02Delivery model
- 03Defined evidence
- 04Decision