Skip to main content

What are you looking for?

Explore our services and discover how we can help you achieve your goals

Total software delivery cost: count the work, not the headline figure

The total cost of delivering software is all the effort needed to reach an accepted handover: discovery, design and build, integrations and data, environments, governance, security, handover and support, plus your own team's time. Compare proposals row by row against that list, because two totals are only comparable when they describe the same work.

Submit a project Plan project delivery

Reviewed by Huy Nguyen (David), CEO · Updated 28 Sep 2026 · 9 min read

star

OutsourcingVN is operated by Netbase JSC, so we have a commercial interest in the proposals you compare, including our own. This guide gives you a worksheet to apply to every supplier and uses Netbase delivery records to show what drives the length of a bounded scope. It publishes no rates or ranges, because those depend on scope decisions only you and a supplier can make together.

Contents

What goes into the total cost of software delivery?

A total is only as good as the request behind it. Give every supplier the same outcome, users, systems, data, integrations, deadline, decision owner and acceptance evidence. The software project brief template gives that request a usable shape.

Then treat every unknown as a named assumption. A supplier may cover an uncertainty in discovery, exclude it or add contingency. Each is legitimate when visible; the problem is an integration, migration or approval cycle that appears in one proposal and is silently implied in another.

Which rows belong in the worksheet?

Worksheet row What to check is included Buyer decision
Discovery Current-system review, scope, risks, architecture and acceptance definition Enough information to commit, or discovery as a separate step?
Design and build Design, engineering, testing and documentation Which user journeys are in this release?
Integrations and data Sandbox access, mapping, migration, retries and reconciliation Who owns each dependency, and what proves data is correct?
Environments Development, test, release process, hosting and access Who controls each environment?
Governance Planning, weekly reviews, change control and decision records Who accepts work, and how quickly?
Security Access boundaries, reviews and incident contacts Which controls are mandatory before access is granted?
Handover and support Documentation, access transfer, training, bug-fix window, support period What will your team run after acceptance?
Buyer time Reviews, test participation, content, approvals Who on your side supplies each input, and when?

The last row is the one most often missing. A slow approval or an unavailable subject expert does not disappear because it is absent from a proposal.

What drives the length of a bounded scope?

Duration follows scope, dependencies and acceptance, not the category of project. These are durations registered for specific Netbase scopes; they are records of those scopes, not estimates for yours.

Three patterns stand out. Acceptance testing, handover and a support window appear as named items, not as leftovers. Integrations and migrations are counted item by item, such as the 11 extensions. And ranges widen where the work depends on something unknown at the start, such as the damage found in a compromised store.

How do you compare two proposals for the same brief?

  1. Normalise the request

    Send every supplier the same brief and ask for assumptions and exclusions in writing.

  2. Map each proposal to the worksheet

    Mark every row included, excluded, deferred or owned by the buyer.

  3. Test acceptance

    For each milestone, ask what evidence closes it and who signs it.

  4. Inspect dependencies

    List the systems, people and approvals that can delay the plan.

  5. Read the change route

    Ask how a new requirement is classified, estimated, approved and recorded.

  6. Test the handover

    Ask what artefacts, access and training stay with you if you buy no follow-on support.

  7. Choose a first commitment

    When scope is still uncertain, make discovery the first bounded decision.

Diagram of a proposal comparison pipeline: normalise the request, map each proposal to the worksheet, test acceptance and inspect dependencies, then read the change route, test the handover and make discovery the first commitment (opens the full-size diagram in a new tab)
Diagram of a proposal comparison pipeline

Worked example: two proposals that looked different

A distributor asks two suppliers for a B2B ordering portal connected to its ERP. Proposal A's total is noticeably higher than Proposal B's. Mapped to the worksheet, the gap explains itself.

  • Integrations and data

    Proposal A
    ERP order sync with retries and a reconciliation report
    Proposal B
    "ERP integration" with no detail
    Question that closed the gap
    "Which events sync, and what happens when the ERP is down?"
  • Data migration

    Proposal A
    Customer accounts and product catalogue migration included
    Proposal B
    Excluded
    Question that closed the gap
    "Who migrates existing customer accounts, and when?"
  • Acceptance

    Proposal A
    Two rounds of buyer testing on staging
    Proposal B
    Not mentioned
    Question that closed the gap
    "What evidence closes each milestone?"
  • Handover and support

    Proposal A
    Documentation, walkthrough, 30-day bug-fix window
    Proposal B
    Documentation only
    Question that closed the gap
    "What happens to a defect found a week after launch?"

After the three questions, Supplier B revised its proposal to add migration, a test round and a bug-fix window. The two totals moved closer together, and the buyer could finally compare delivery approach instead of guessing at hidden exclusions.

How should the commercial shape be decided?

Most Netbase projects are agreed as fixed-scope contracts after discovery; milestone-based arrangements are also available. Netbase also offers dedicated development teams, on-demand support and fully managed delivery as secondary options. The engagement models guide explains who controls day-to-day priorities in each.

A bounded project moves estimation risk towards the supplier, which is why scope, acceptance and the change route matter. A capacity-led arrangement leaves sequencing with the buyer. A lower first total can be a different allocation of risk rather than less work.

Netbase's delivery lifecycle is discovery and strategic alignment; team assembly and architecture planning; agile execution with outcome-based milestones; modular components; training and rollout; and ongoing support. Project teams draw on business analysis, project management, solution architecture, development, QA and UI/UX roles, and typically range from 3 to 30 people. Check that each proposal staffs the roles its scope needs.

How do distributed delivery and security change the total?

Remote-first delivery adds written handovers, decision records and scheduled overlap to the work. Netbase stays accountable while teams may combine Netbase staff, approved specialists or disclosed partners, and onsite work is available on request and scoped as a separate project activity. The global delivery page describes the model, and the time-zone collaboration guide shows what to agree about overlap and escalation.

Security is an input, not a final checklist. Which environments the team may access, whether data can leave them, how credentials are issued and removed, and who approves a production change all affect effort. The data security and compliance guide lists the questions to settle before access is granted.

Which questions should you ask every supplier?

  • What are your assumptions and exclusions? A good answer is a written list you can compare line by line.
  • Which rows of the worksheet does your proposal leave to us? Look for named buyer tasks with dates.
  • What evidence closes each milestone? Expect a test, a demonstration or a document, and a named signatory.
  • How is a change request handled? Expect classification, estimate, approval and a record.
  • What is in the handover? Look for documentation, access transfer, training and known limitations.
  • What does support cover, and for how long? Expect a written period, scope and exit route.
  • Which roles are on the team? Look for analysis, project management, architecture, development, QA and design where the scope needs them.
  • How are milestones structured? Look for outcome-based milestones that can be accepted one at a time.

Plan the next step for your project

Common questions

It can give an initial view, but it should separate confirmed scope from assumptions. Treat a firm commitment made before systems and dependencies are understood with care, because the unknowns are then either hidden in contingency or waiting to return as change requests.

Anything not yet understood well enough to commit to: an unassessed legacy integration, data migration from an unknown source, or third-party approvals. Good proposals list these as exclusions or as separate discovery tasks, so the buyer can see what the fixed scope really covers.

Only when it is defined. Record the coverage, the responsibilities, the period and the exit route. Registered Netbase scopes show how varied this is, from a 30-day bug-fix window after an ordering-flow upgrade to six months of support after a classifieds platform.

There is no typical figure worth quoting. Registered Netbase scopes range from a recovery measured in days to a platform delivered in phases over several months. Your own duration comes from discovery, once dependencies and acceptance are clear.

Large enough to cover the roles your scope needs and no larger. Netbase project teams typically range from 3 to 30 people across business analysis, project management, solution architecture, development, QA and UI/UX. Ask each supplier which roles it assigns and for how long.

Turn the worksheet into a scoped conversation

Walk the worksheet with your product, finance, security and operations owners, record the unanswered rows and make them a discovery output. Project delivery shows how that output becomes a milestone with inputs and acceptance evidence, and the methodology explains how the records on this page are sourced. For a bounded build, see Custom Product Engineering.

OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with your outcome, systems, decision owner and constraints, and a person will reply with whether discovery or a bounded delivery scope is the right next step.

Custom product engineering for a bounded release outcome Custom product engineering for a bounded release outcome

One defined release of your product, built to named outcomes and handed over with acceptance evidence.

Learn More
line

Tell us what you want to build or automate.

Submit a project