Skip to main content

What are you looking for?

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

Milestone project delivery with clear acceptance

A milestone is only useful when both sides know, before it starts, what will be delivered, what the buyer must provide, how the result will be checked and who decides whether it is accepted. Project delivery on OutsourcingVN is built around making those points explicit and keeping them in one record from the first proposal to the final handover.

Submit a project See Custom Product Engineering

Reviewed by David Nguyen (CEO) · Updated 5 Oct 2026

star

From brief to proposal

Every project starts with a brief, sent through the project submission page. The project team reviews fit and constraints and agrees one of three next steps with you: a proposal, a short discovery or audit milestone, or a clear statement that the project is not a fit. Phase 1 has no public deposit and no automatic project creation; nothing starts until a proposal is accepted.

If you are still weighing a custom build against SaaS, deciding between low-code and custom development, or planning the first release of a SaaS product, work through the SaaS discovery questions before sending the brief. The answers become the proposal's assumptions rather than open questions discovered mid-milestone.

A proposal names:

  • the outcome and the decision it supports;
  • scope boundaries, exclusions and assumptions;
  • the milestone plan, with the inputs each milestone needs from you;
  • risks and dependencies, each with an owner;
  • the acceptance method for each milestone;
  • handover content and the exit path;
  • commercial terms for that specific scope, including whether it runs as fixed scope or milestone contracts.

The delivery lifecycle

  1. Discovery and alignment

    Confirm the outcome, users, systems and constraints, and agree the architecture and team the scope needs.

  2. Milestone delivery

    Build in increments against outcome-based milestones, with weekly reviews and written status between them.

  3. Rollout and handover

    Verify, release, train and transfer ownership. Ongoing support or improvement is an optional, separately scoped step.

Behind these stages sits Netbase's six-step lifecycle: discovery and strategic alignment, team assembly and architecture planning, agile execution with outcome-based milestones, reuse of proven components where they fit, training and rollout, and ongoing support when you want it.

What every milestone contains

  • a title, business purpose and the accountable owners on both sides;
  • included deliverables, exclusions, assumptions and dependencies;
  • target review dates and any time-zone overlap the work requires;
  • acceptance criteria and how they will be verified;
  • links to the repositories, environments, designs and documents involved;
  • security, privacy, data and AI-use constraints, including where human review is required;
  • the rule for handling changes;
  • conditions for starting the next milestone.

By default only one milestone is active at a time. Parallel milestones are used when their dependencies, owners and acceptance paths are independent and the agreement allows it.

Who is responsible for what

  • Sponsor

    Side
    You
    Responsible for
    The business outcome, budget, escalation and major scope decisions
  • Product or process owner

    Side
    You
    Responsible for
    Requirements, access to systems and people, timely answers and milestone acceptance
  • Delivery lead

    Side
    Netbase
    Responsible for
    The plan, milestone scope, team coordination, risk, reporting and handover
  • Technical lead

    Side
    Netbase
    Responsible for
    Architecture, technical quality, security and technical evidence
  • Quality owner

    Side
    Netbase
    Responsible for
    Test coverage against acceptance criteria and release evidence

On a small project one person may hold more than one Netbase role. The buyer keeps product and business decisions; Netbase owns the agreed delivery work and reports evidence against each milestone.

Reporting and communication

Delivery is remote-first, so written communication carries the project. You can expect:

  • written status updates at an agreed rhythm during active work;
  • a weekly review or demonstration when a working increment exists;
  • a risk register and dependency log updated when something changes, not just before meetings;
  • material decisions written down soon after they are made, even when discussed on a call;
  • response and acceptance windows agreed per project.

The global delivery page covers working hours and time-zone overlap.

Acceptance

A milestone is not complete because code was uploaded or a task list is ticked. It moves through internal verification by Netbase, then your review, and ends in one of three recorded outcomes: accepted, changes requested against the acceptance criteria, or blocked by a dependency. Only an accepted milestone is closed, and the next one starts when its conditions are met.

Change control

Requests are classified before anyone acts on them: a clarification, a defect against acceptance criteria, a dependency change, a scope change or a new milestone. The delivery lead records the impact on outcome, schedule, cost, security and other milestones, and scope changes need your written approval. Nothing silently rewrites an approved milestone; the change control guide shows how to set the same rule with any supplier.

What we ask from you

Most delays in outsourced projects come from waiting, not from building. Before each milestone starts, the plan lists what it needs from your side: access to systems and test accounts, sample data, decisions on open questions, and the time of the person who will review and accept. If an input is late, the plan shows which work waits on it, so the impact is visible early rather than discovered at the review.

Pausing or stopping

A project can be paused, for example while a budget or dependency decision is made, or stopped early. In either case the current milestone is closed out with a record of what was completed, what was accepted and what remains open, and accounts and environments are left in a documented state. A paused project restarts from that record.

AI-assisted delivery, human decisions

Netbase uses AI tools inside delivery, for example to draft code and tests, summarize changes or prepare documentation. A named engineer reviews and owns every change that ships, AI output is never used as acceptance evidence on its own, and any restriction you set on AI tool use is written into the project definition. The AI-assisted software delivery guide lists the evidence to ask any supplier for.

Handover and exit

Handover is planned from the start, not negotiated at the end. It covers the accepted deliverables, source code and documentation, access transfer for accounts and environments, and a list of open issues and known limitations. For custom development, the intellectual property created for you belongs to you.

An exit path is part of every project, including one that stops early. It lists what can be transferred, what remains dependent on third parties, and what must be closed or kept for audit. Continued support, maintenance or managed operations are separate scopes you can choose; see engagement models.

See it applied

The Work records describe projects delivered in milestones, for example a chatbot and CRM integration delivered from design and prototype through to documentation and knowledge transfer. The services that use this model are listed on the services page.

From a brief to an accepted transition

Use the project brief to define the outcome and acceptance evidence. Settle IP ownership before work starts, and agree the handover and exit package while access is still easy to arrange. When an existing project has stalled, begin with a rescue assessment before promising a replacement schedule. These decisions feed a bounded Custom Product Engineering engagement.

The Magento recovery and hardening record describes a limited recovery scope. It does not establish a universal recovery outcome. A milestone plan should therefore record what the assessment actually finds, what remains unknown and who accepts each residual risk.

Ready to define the first milestone?

Start with a brief: submit a project. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.

Tell us what you want to build or automate.

Submit a project