Mode 01
Standard delivery
This mode is better when the first priority is whether the system can run stably and pass formal acceptance. Full-repository source transfer is not included by default.
Delivery Scope
Source Delivery and Licensing Boundary
Client Delivery ScopeIf you are evaluating deployment mode, future maintenance, or control of source code, this page explains the difference between standard delivery, private deployment, and source-code licensing.
The point is to make delivery scope, licensing mode, and maintenance responsibility clear before pricing so both sides do not carry different assumptions.
There are usually three modes right now: standard delivery, private deployment, and source-code licensing or buyout. Whether source code is included depends not only on whether deployment is independent, but also on the licensing scope and future maintenance arrangement agreed by both sides.
standard deliveryprivate deploymentsource-code licensingexplicit contract wording
EXECFABRIC // DELIVERY SCOPEMAT 10
standard: usable_deliveryprivate: independent_environmentsource: licensed_separately
CLARIFY SCOPE BEFORE DELIVERY
Mode 02
Private deployment
This mode is better when the customer needs independent servers, databases, domains, and runtime environments, but the source-code scope still has to be agreed separately.
Mode 03
Source-code licensing or buyout
This mode is better when the customer clearly needs future self-maintenance, second-stage development, or stronger control rights, and it should be handled as a separate licensing mode.
Pricing Boundary
The boundary between the three delivery and licensing modes
| Mode | Default delivery contents | Source-code status | Best-fit scenario |
|---|---|---|---|
| Standard delivery | Deployed system, access entry points, accounts, instruction documents, result entries, and necessary configuration handover | Full-repository source code is not transferred by default | Best when the first priority is runnable output, formal acceptance, and stable use |
| Private deployment | Deployment in the customer's independent environment, deployment manual, parameter list, ops handover, and acceptance support | The scope of source code has to be agreed separately | Best when the customer needs an independent server, independent deployment, intranet operation, or a stronger boundary |
| Source-code licensing / buyout | Code within the project scope, deployment scripts, necessary instructions, and agreed licensing boundary | Licensed separately and quoted separately | Best when the customer explicitly needs source-code control rights and is willing to bear the higher cost |
Quick Summary
Read these four sentences first
- Standard delivery defaults to runnable results, accounts, documents, and delivery explanation.
- Private deployment defaults to independent environments, deployment handover, and acceptance support.
- Independent deployment does not automatically mean a full-repository source-code buyout.
- If source transfer, second-stage development, or stronger control is needed, that is stated separately in pricing and contract wording.
Clarification
Why independent deployment does not automatically equal a source-code buyout
- Many projects mainly need something that is runnable, acceptable, and stable in long-term use, not immediate takeover of the whole codebase.
- Platform projects usually include a general foundation, project-scope implementation, and delivery instructions at the same time, so the source boundary has to be drawn explicitly by agreement.
- If you need future self-maintenance, second-stage development, or stronger control, the mode can switch into source-code licensing or buyout.
- That makes maintenance responsibility, upgrade mode, and fee boundary clearer for both sides.
Contract Wording
Three paragraphs that can be written directly into a proposal or contract
1. Standard-delivery wording
This quotation includes feature implementation within the project scope, deployment landing, account and documentation handover, and problem fixing plus acceptance support within the agreed period. It does not include full-repository source transfer or permanent buyout licensing by default.
2. Private-deployment wording
This delivery is executed on the customer's independent servers, database, and domain. Deliverables include the runtime environment, deployment manual, parameter list, and acceptance support. If source transfer or a stronger licensing boundary is needed, that should be agreed separately on top of private deployment.
3. Source-code licensing wording
If project-scope source transfer, future self-maintenance, or stronger control is required, this should be quoted separately under a source-code licensing or buyout mode. The quotation will be materially higher than ordinary implementation and deployment delivery and should not be mixed into the standard delivery package.
Project Scope
If you explicitly need source code, confirm these four questions first
- Whether the transfer is the full repository or only the code inside this project scope.
- Whether future self-modification and redistribution rights are included.
- After source delivery, who still takes responsibility for later maintenance.
- Whether the general foundation, other-customer content, and internal documents are excluded from this delivery scope.