Build a total software delivery cost from the work, not a headline quote
A software delivery total is the buyer's worksheet for every activity needed to reach an accepted handover. It starts with the outcome, then includes discovery, build, review, environments, governance and the work your own team must do. It cannot be an average, because those decisions differ from project to project.
Submit a project Plan project deliveryReviewed by David Nguyen (CEO) · Updated 27 Sep 2026 · 7 min read
OutsourcingVN is operated by Netbase JSC, so we have a commercial interest in work you may buy. This guide gives a worksheet you can apply to every proposal, including ours. It publishes no rate, range, saving or external benchmark. The aim is to expose what a proposal assumes before you compare its total with another one.
Start with one comparable request
- The buyer-built worksheet
- Decide the commercial shape after discovery
- Include distributed delivery decisions
- Make security and data visible
- Compare proposals in sequence
- Evidence and its limits
- Common questions
- Turn the worksheet into a scoped conversation
The buyer-built worksheet
Use these rows to turn a headline total into an explanation:
| Worksheet area | Ask what is included | Buyer decision |
|---|---|---|
| Discovery | Current-system review, scope, risks, architecture and acceptance definition | Is there enough information to commit, or should discovery stand alone? |
| Product and build | Design, engineering, testing and accessible documentation | Which user journey and capability are actually in this release? |
| Integrations and data | Credentials, sandbox access, mapping, migration, retries and reconciliation | Who owns each dependency and what proves data is correct? |
| Environments | Development, test, release process, hosting and operational access | Who controls each environment and what must be ready before work starts? |
| Governance | Planning, reviews, change control and decision records | Who accepts work, and how quickly can they decide? |
| Security and compliance | Access boundaries, review, audit needs and incident contacts | Which controls are mandatory before access is granted? |
| Handover and support | Documentation, access transfer, training, known limitations and follow-on scope | What will your team operate after acceptance? |
Do not add columns for imagined returns. Adoption, sales, internal uptake and a third party's response are outside a supplier's delivery control. A clear worksheet separates the work a provider can be accountable for from the outcome a business hopes that work will enable.
Decide the commercial shape after discovery
Netbase normally agrees defined projects as fixed-scope contracts after discovery, with milestone-based arrangements available. It also offers dedicated teams, on-demand support and fully managed delivery as secondary options. The engagement models guide explains who carries day-to-day control in each shape.
A bounded project moves estimation risk toward the provider, which is why the scope, acceptance test and change route matter. A capacity-led arrangement leaves more sequencing and prioritisation with the buyer. Managed operations needs a separate definition of service boundaries, coverage, reporting and the work that is excluded. A lower initial total can be a different allocation of risk rather than less work.
Include distributed delivery decisions
Remote-first delivery changes the worksheet because written handovers, decision records and scheduled overlap are part of the work. Netbase remains accountable when a project uses its staff, approved specialists or disclosed partners, but the working rhythm still needs to be designed. The global delivery page describes this model; the time-zone collaboration guide shows what to agree about overlap and escalation.
Add the buyer's own review time to the worksheet. A slow approval, unavailable subject-matter expert or missing system credential does not disappear because it is absent from a proposal. Record who supplies each input, when it is needed, and what the plan does when it arrives late.
Make security and data visible
Security is a project input, not a final checklist. State which environments the team may access, whether data can leave them, how credentials are issued and removed, who approves a production change, and what evidence the buyer needs at handover. The data security and compliance guide lists questions to settle before access is granted.
Those choices affect effort because they change the design, test path and coordination. This is not a legal determination: use your own legal, security and procurement advisers for obligations that apply to your organisation. The worksheet's job is narrower: make the delivery work visible to the people who must decide whether to fund it.
Compare proposals in sequence
-
Normalise the request
Give each provider the same brief and ask it to list assumptions and exclusions.
-
Map each proposal to the worksheet
Mark every row included, excluded, deferred or owned by the buyer.
-
Test acceptance
For each milestone, ask what evidence closes it and who signs it.
-
Inspect dependencies
Identify systems, people and approvals that can delay the plan.
-
Read the change route
Ask how a new requirement is classified, estimated, approved and recorded.
-
Test the handover
Ask what artefacts, access and training remain with you if follow-on support is not bought.
-
Choose a first commitment
When the scope is still uncertain, make discovery the first bounded decision.
Evidence and its limits
The multi-vendor marketplace mobile app record is a specific published record related to Custom Product Engineering. It describes delivered scope at its stated evidence level. It does not show the commercial total, a saving, an ongoing operations result or a guarantee that another marketplace has the same needs.
Use records to ask better questions about scope and dependencies, never as a substitute for your own worksheet. The methodology page explains why records publish only what their source permits.
Before making a selection, walk the worksheet with the people who own product, finance, security, operations and the dependent systems. Their job is not to negotiate a number in that meeting. It is to establish that the same delivery boundary is being compared. Record the unanswered rows and make them an explicit discovery output. The project delivery guide shows how that output can become a milestone with inputs and acceptance evidence.
Include the cost of delay only as a buyer-owned decision, not as a supplier promise. A launch date may constrain the scope, but it does not make unverified integration work disappear. If a date is fixed, identify the smallest acceptable release, the decisions that must be made before it, and the capabilities that can wait. That turns schedule pressure into a visible trade-off instead of a hidden assumption inside the delivery total.
Plan the next step for your project
Common questions
The names can differ, but you should be able to locate discovery, build, acceptance, handover and the work around dependencies in each one.
It can provide an initial view, but it should distinguish confirmed scope from assumptions. Treat a commitment made before systems and dependencies are understood with care.
Only when it is defined. Record its coverage, responsibilities, reporting and exit route instead of assuming it follows handover.
No. It establishes only the scope and limits published for that record.
Turn the worksheet into a scoped conversation
Submit a project with the outcome, systems, decision owner and constraints. OutsourcingVN is Netbase's own outsourcing-services platform, and a person will use that information to decide whether discovery or a bounded delivery scope is the honest next step.
Work behind this guide
For RB Marketplace, Netbase built an English-first multi-vendor marketplace for West Africa on Laravel, then built the customer shopping app on that marketplace's own API.
Keep ReadingRelated services and solutions
Custom product engineering for a bounded release outcome
Custom Product Engineering is for a buyer who can name the users, the release decision and the outcome a product increment should deliver. The engagement produces an accepted, working release, the evidence that it works, and a handover your team can operate. It is not a way to rent developers by the month.
Learn More