The detailed guidance and illustrative examples below are in English. All example business records are fictional.
Make the delivery decision concrete
An internal team is a strong option when software is a sustained core capability and you can supply technical leadership. External delivery can cover a defined phase, provided the future internal owner participates and can operate the result.
Worked fictional transition
A fictional distributor has a permanent product backlog but is still recruiting. It assigns an internal technical owner before commissioning a bounded order-approval release. That owner reviews architecture and acceptance throughout, then takes over maintenance with the incoming engineer.
| Phase | External provider | Buyer / internal team | Exit evidence |
|---|---|---|---|
| Define | Help scope one release and document architecture decisions. | Own priorities, rules, accounts and technical acceptance. | Agreed scope, roles and operating budget. |
| Deliver | Implement and demonstrate the agreed workflow. | Review changes and learn deployment/recovery. | Accepted staging workflow and maintained documentation. |
| Transition | Explain source, deployment, dependencies and known issues. | Deploy a release and restore data with the runbook. | Successful maintainer exercise and access transfer. |
| Operate | Provide only the optional support scope agreed separately. | Own roadmap, patching, alerts, backups and incidents. | Named owners, escalation path and remaining support terms. |
Buyer-input cost worksheet
Choose the same planning horizon for both options. Enter your own amounts in one currency, record tax treatment and avoid counting the same role twice. No salary, hiring-time or savings benchmark is assumed.
| Cost / capacity input | In-house assumption | External phase assumption |
|---|---|---|
| Recruitment and onboarding | Recruitment spend + interview hours × internal rate + onboarding time. | Supplier selection + procurement + onboarding time. |
| Delivery capacity | Compensation, benefits, equipment and realistic available delivery hours. | Written phase fee or agreed hours, with exclusions and availability. |
| Technical management | Lead/review hours × internal rate. | Buyer review hours plus any explicitly included provider coordination. |
| Ongoing workload | Roadmap, maintenance and incident load after launch. | Which work remains internal and which support is separately contracted. |
| Operating costs | Hosting, vendors, backups and developer tools. | The same categories, identifying account and payment owner. |
| Handover / continuity | Documentation, shared knowledge and absence cover. | Source, runbooks, training, transition time and exit arrangements. |
Two viable choices and the trade-off
For the fictional distributor, hiring first gives the permanent team more control from the beginning but requires recruitment and available leadership before delivery. A bounded external phase can proceed with an internal owner, but requires deliberate knowledge transfer and still leaves long-term hiring and operations to the buyer. Confirm real availability for both paths.
What must my team be able to maintain at handover?
They should build and deploy the source, manage configuration and access, understand key business rules, review logs/alerts, restore data and apply routine updates. Demonstrate those tasks before transition. Record gaps as training or support scope rather than declaring handover complete.
Next step: bring one defined workflow, your internal review capacity and the missing evidence. Agree a review or delivery scope before choosing a provider.