Guide / Delivery
Product delivery scope outline
Use this to shape a written statement of work before you hire a squad. Clear goals, must-haves, milestones, and owners reduce rework and make weekly progress visible. Bring rough answers; perfection is not required. The outline is designed so finance, product, and engineering can argue about the same document instead of three different Slack threads.
Who this is for
Founders and engineering leads who need a v1 or a major release without standing up every role internally. Also useful when an existing codebase needs a stabilisation pass before new features. If you have been burned by open-ended retainers or feature dumps with no acceptance criteria, this outline is the antidote. It works for greenfield builds and for takeovers where the first milestone is making production predictable again.
What belongs in a useful SOW
A good scope is specific enough to price and staff, but open enough to learn in the first sprints. Avoid a feature dump with no priority. If you cannot separate launch-critical work from later work, pause and resolve that before asking for a calendar. Integrations, devices, and approval owners belong in the first draft, not in week six.
Business goal this quarter
One sentence on what success looks like commercially: launch, conversion, staff throughput, or market entry.
Primary users
Who uses the product daily, on which devices, and what they must complete without friction.
Must-have vs later
Split features into launch-critical and post-launch. If everything is critical, the timeline is not real yet.
Current stack
Languages, frameworks, hosting, and any vendor platforms (for example Haravan). Note greenfield vs takeover.
Integrations and devices
Payments, CRM, ERP, messaging, scanners, printers, or other peripherals that must work on day one.
Hard dates
Campaigns, store openings, investor demos, or compliance deadlines that cannot move.
Your side owners
Who approves design, content, and production releases. Slow approvals are a schedule risk.
Budget or team-size signal
A range is enough. It helps us propose a realistic squad shape instead of a generic rate sheet.
How Haikotek usually engages
After contact, we ask clarifying questions, then send a proposal with deliverables, milestones, and pricing. Named owners and weekly visibility are part of the model. Major engineering spend starts only after that written plan is agreed. Peripheral needs such as scanners or printers are included when the product requires them. Discovery is short and purposeful: enough to staff the work and surface risks, not an endless workshop series. If the idea is still too fuzzy to price, we may recommend a Lab walkthrough or a spike before locking a multi-month squad.
What a solid proposal should include
- Outcomes for the next 90 days, not only a backlog of tickets. Leadership should see what will be true in market or in operations when the period ends.
- Dated milestones with acceptance cues and a named Haikotek owner.
- Assumptions, exclusions, and how change requests are handled.
After scope is locked
Delivery continues under Strategic Delivery with weekly checkpoints. If the idea is still risky, we may recommend a Lab walkthrough or a short spike before scaling the build. Performance or AI work can be sequenced when those are the real bottlenecks. Change requests are expected; the SOW should say how they are priced and scheduled so the calendar stays honest.
Common mistakes to avoid
- Listing every feature as must-have for launch. That usually means the timeline is fiction.
- Hiring a squad before naming who on your side approves design, content, and production releases.
- Skipping integrations and devices until late. Payments, ERP, scanners, and printers often dominate the critical path.
- Confusing staff augmentation with accountable delivery. If nobody owns outcomes and milestones, scope will drift.
When this guide is a good fit
Use it when you are about to fund a squad and need a written plan leadership can approve. It fits takeovers, Haravan or custom storefronts, and internal tools that must ship with devices and integrations on day one. Skip it if you only want a one-week design spike with no build, or if procurement already locked a fixed feature list with no room for discovery. Strategic Delivery is the service line; this outline is how you arrive with a brief that can be priced without endless clarification loops. Link stakeholders to the Work cases when they ask what “accountable delivery” looks like in practice.
Common questions
- Is this staff augmentation?
- We work as an accountable squad against a written scope and calendar. Exact commercial shape is confirmed in the proposal. If you need pure staff augmentation with no outcome ownership, say so up front so we do not mis-set expectations.
- Can you take over an existing codebase?
- Yes, when access and documentation allow a responsible takeover. The first milestone is often stabilisation and visibility, then feature delivery. A dump of tickets without priorities is not enough to staff a calendar.
- How do we start?
- Send this outline via Contact with the delivery planning intent. Include hard dates and must-haves. We reply with clarifying questions, then a proposal when the brief is solid enough to price.