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
-
Discovery and alignment
Confirm the outcome, users, systems and constraints, and agree the architecture and team the scope needs.
-
Milestone delivery
Build in increments against outcome-based milestones, with weekly reviews and written status between them.
-
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.