Software delivery / Ongoing partnerships
Keep development ongoing and the agreement explicit.
An ongoing development arrangement can give a changing product continuity of engineering work. It still needs a clear answer to what is being bought, who chooses the next task, how completed work is accepted and what happens when the relationship ends.
Understand the arrangement
Recurring work still needs a defined boundary.
In this guide, software development as a service means an ongoing arrangement to develop and improve software for a business. Imagine a booking system with a new scheduling feature, a failed reminder and a dependency update waiting in the same backlog. A recurring invoice does not decide which task comes first or whether incident response is included.
- Development work
- The purchased work changes or maintains software. Agree which activities and responsibilities belong in the arrangement.
- SaaS product access
- SaaS gives a customer use of a provider's cloud application. Paying to develop a particular system is a different purchasing decision, even when both use recurring billing.
- An explicit service boundary
- Hosting, user support, incident response and future changes need their own scope. Do not infer them from the phrase as a service.
Six agreement questions
Turn the proposal into decisions both sides can make.
The following review applies to a proposed arrangement. It does not assume any supplier includes these services or agrees to particular terms.
What work is purchased?
01Question to settle: Does the fee buy time, reserved capacity or a defined result?
- Why it matters
- The same recurring amount can support very different obligations.
- Bring to the discussion
- The proposal, included activities, exclusions and charging basis.
- Booking-system example
- Distinguish time spent investigating reminders from a commitment to deliver a scheduling feature.
- Decision responsibility
- Commercial owners agree the purchase; technical owners test whether the description is workable.
- Written result
- A scope that names the purchased unit and how additional work is agreed.
- Failure to watch
- Treating available capacity as an unlimited feature promise.
- Ongoing practice
- Reconcile actual work with the agreed basis.
Who orders the backlog?
02Question to settle: What changes when an urgent request arrives?
- Why it matters
- A new priority can displace work already expected by the business.
- Bring to the discussion
- Current commitments, urgency, dependencies and the reason for each request.
- Booking-system example
- Record whether repairing reminders displaces scheduling work and what happens to the forecast.
- Decision responsibility
- The product owner chooses business priorities with engineering advice.
- Written result
- A visible priority change and its consequence for other work.
- Failure to watch
- Different stakeholders directing the same team independently.
- Ongoing practice
- Use one agreed route for accepting and ordering requests.
What counts as accepted?
03Question to settle: Which behavior and evidence establish completion?
- Why it matters
- A demonstration may omit failures, integrations or the receiving process.
- Bring to the discussion
- Relevant users, expected behavior, edge cases and acceptance responsibility.
- Booking-system example
- Check the changed booking behavior and reminder handoff in agreed conditions.
- Decision responsibility
- The business owner accepts intended behavior; engineering verifies the technical change.
- Written result
- A reviewed result, test evidence and unresolved limitations.
- Failure to watch
- Closing a task because code was submitted or a meeting occurred.
- Ongoing practice
- Keep acceptance attached to the change.
Who keeps it running?
04Question to settle: Which maintenance and response responsibilities are included?
- Why it matters
- A delivered feature creates ongoing operational work.
- Bring to the discussion
- Existing hosting, monitoring, support arrangements and dependency responsibilities.
- Booking-system example
- Name who receives a failed-reminder alert and who decides whether to interrupt planned development.
- Decision responsibility
- Service and operational owners agree coverage and escalation.
- Written result
- Named responsibilities and separately agreed response expectations.
- Failure to watch
- Assuming development capacity provides continuous incident coverage.
- Ongoing practice
- Review operational demand alongside planned changes.
What does continuity cost?
05Question to settle: Is the recurring arrangement justified by the work ahead?
- Why it matters
- Continuity has value only when it supports a real, managed need.
- Bring to the discussion
- Demand history, likely changes, onboarding effort and the full cost basis.
- Booking-system example
- Compare recurring booking improvements with a bounded repair and a period of lower demand.
- Decision responsibility
- The business owner reviews value with finance and delivery input.
- Written result
- A review decision based on accepted work, remaining needs and total costs.
- Failure to watch
- Renewing because a team is busy without understanding the result.
- Ongoing practice
- Revisit the arrangement when demand or priorities change.
Can another owner continue?
06Question to settle: What remains usable when people or suppliers change?
- Why it matters
- An ongoing relationship can accumulate knowledge that exists only in one person's head.
- Bring to the discussion
- Repositories, setup instructions, operational records and the proposed transition process.
- Booking-system example
- Have the receiving maintainer reproduce a relevant booking check using the handover materials.
- Decision responsibility
- Technical owners verify usability; commercial and legal owners settle rights and transition obligations.
- Written result
- An agreed handover inventory and a demonstrated maintenance path.
- Failure to watch
- Discovering at exit that the next maintainer cannot build or understand the system.
- Ongoing practice
- Transfer knowledge throughout the engagement.
Compare what is bought
A billing rhythm does not define a delivery model.
These are comparison lenses, not standardized packages. A proposal can combine them, so ask which obligation applies to each part of the work.
| Arrangement | Purchase focus | Clarify first | Buyer still decides | Watch for |
|---|---|---|---|---|
| Ongoing capacity | Agreed engineering effort | Allocation and exclusions | Work priorities | Unlimited-output assumptions |
| Bounded project | Defined deliverable | Acceptance and change | Required outcome | Unresolved dependencies |
| Staged development | One agreed increment | Next-stage decision | Continue or revise | Automatic expansion |
| Team augmentation | Skills within a team | Management responsibility | Delivery coordination | Unowned integration work |
| Operational service | Agreed running duties | Coverage and escalation | Service priorities | Assumed response promises |
| SaaS subscription | Use of an application | Product and configuration | Business suitability | Assumed bespoke development |
Make the first period informative
Start with work that tests the relationship.
Use a real, bounded need to make responsibilities observable before increasing dependence on the arrangement.
- 01
Describe the continuing need
Name the software, the people using it and the kinds of change expected. Separate known work from an untested wish list.
- 02
Resolve the work boundary
Agree what is included, what requires another decision and who owns dependencies outside the team's control.
- 03
Choose a revealing increment
Select work with a meaningful acceptance result. Include a relevant integration or operational constraint rather than judging the relationship on a cosmetic change alone.
- 04
Review the complete result
Inspect the change, outstanding problems, actual effort and the handover material. Record where buyer decisions or access delayed progress.
- 05
Decide the next commitment
Continue, adjust or close the arrangement using the agreed terms and current evidence. Update priorities and responsibilities before the next period.
Keep continuity useful
Retain enough knowledge to govern the work.
A supplier can perform substantial delivery work while the business remains responsible for its own priorities and decisions.
- Make decisions available
- Name a buyer who can answer product questions and resolve conflicting requests. An external team cannot infer business authority from silence.
- Inspect more than activity
- Review usable changes and unresolved risks. Task counts and time records describe activity; they do not establish that the intended problem is solved.
- Keep access proportionate
- Grant only the access needed for the work and remove it when no longer required. Record who administers the accounts involved.
- Make transition routine
- Keep instructions current and allow time for shared learning. Check whether another maintainer can use the materials before the relationship reaches its final week.
Questions before committing
Ask what the label leaves unanswered.
A useful proposal should make these answers concrete for the software and business involved.
- Is software development as a service the same as SaaS?
- No. Here the term describes ongoing development work. SaaS concerns using a provider's cloud application. A business might buy either or both, but the scope and responsibilities should be evaluated separately.
- Does a recurring fee mean unlimited development?
- No such commitment follows from the billing schedule. Read the agreed capacity, deliverables, exclusions and process for additional work. Ask how competing requests affect each other.
- When can an ongoing partnership help?
- It can preserve working knowledge across a continuing stream of changes. That benefit depends on relevant demand, understandable software, usable feedback and clear ownership. It is not a guarantee of lower cost or faster delivery.
- When might a bounded project fit better?
- Consider a bounded engagement when the required result is well understood and continuing demand is limited. Uncertain work may need discovery before either arrangement can be evaluated sensibly.
- Who owns the code and what happens at exit?
- The service label does not establish ownership or transition rights. Have the appropriate commercial and legal owners review the actual agreement, including relevant materials and dependencies. Separately verify that the receiving technical owner can continue the work.
Source basis
Sources behind the control model.
- 01
NIST CSRC
Software as a Service (SaaS)The glossary definition, sourced to SP 800-145, distinguishes use of a provider's cloud application from the development arrangement discussed here.
- 02
UK Cabinet Office
Contracting For Agile Guidance NoteJune 2023 guidance discusses commercial models, quality and buyer responsibility. It informs comparison questions; its procurement rules, example incentives and remedies are not adopted as universal terms.
- 03
GOV.UK Service Manual
Governance principles for agile service deliverySupports available decision owners, clear authority and regular inspection of delivery. Government roles are not assumed to exist in every business.
- 04
GOV.UK Service Manual
Working with contractors or third partiesUpdated October 2024. Supports deliberate knowledge transfer and necessary, removable access when working with external contributors.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD