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?
- Which rows belong in the worksheet?
- What drives the length of a bounded scope?
- How do you compare two proposals for the same brief?
- Worked example: two proposals that looked different
- How should the commercial shape be decided?
- How do distributed delivery and security change the total?
- Which questions should you ask every supplier?
- Common questions
- Turn the worksheet into a scoped conversation
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.
-
- Registered duration
- 35 working days
- What the scope included
- Magento 1 to Magento 2 Commerce, including 11 extensions with installation, configuration, customisation and data transfer
-
- Registered duration
- About 20 to 25 working days
- What the scope included
- Guided mobile-first apparel ordering, built and tested on staging with client acceptance testing, a handover walkthrough and a 30-day bug-fix window
-
- Registered duration
- 4-8 weeks
- What the scope included
- Milestones from design and prototype to documentation, knowledge transfer and 30 days of support
-
- Registered duration
- Six milestones over four months
- What the scope included
- A full platform with training and six months of support
-
- Registered duration
- Four phases over 3.5 to 4.5 months
- What the scope included
- A headless multi-store platform for a Dubai-based loyalty and rewards technology company
-
- Registered duration
- Typically 6 to 13 days in total, depending on the damage
- What the scope included
- Investigation, cleaning and recovery, then file restore and hardening of a compromised store
-
- Registered duration
- 90 days of post-launch support
- What the scope included
- Support after launch of a multi-vendor marketplace
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?
-
Normalise the request
Send every supplier the same brief and ask for assumptions and exclusions in writing.
-
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
List the 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 stay with you if you buy no follow-on support.
-
Choose a first commitment
When scope is still uncertain, make discovery the first bounded decision.
(opens the full-size diagram in a new tab)
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.
Related services and solutions
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