Current state
What exists now, who uses it, how it is maintained and what is currently failing?
Playbook live
Playbook 04
Updated 18 Jul 2026
Discovery · Scope · Delivery · Handover
Freelance Delivery System
A professional operating system for turning an unclear client request into a qualified opportunity, a controlled scope, a visible delivery process, an accepted result and a maintainable handover.
Pricing examples, client identities, contracts, private communications and commercially sensitive project information remain outside the public playbook.
01 · Opportunity qualification
A good delivery process starts by deciding whether the project should exist.
Not every inquiry is a suitable project. Qualification protects delivery quality by checking whether the problem is real, the client can make decisions, the required inputs are available and the budget or timeline can support the desired result.
The objective is not to reject difficult work. It is to identify which constraints must be resolved before a proposal becomes credible.
When qualification is weak, the proposal becomes guesswork and the project absorbs uncertainty through revisions, delays and unpaid changes.
02 · Discovery
Translate the request into an observable problem and outcome.
Discovery should produce decisions that can enter a scope document—not an unlimited brainstorming session.
Desired change
What should users, staff or the business be able to do after delivery?
Primary users
Who needs the result, what device or environment they use and what matters to them?
Required materials
Copy, images, data, brand assets, accounts and approvals needed from the client.
Boundaries
Timeline, technology, hosting, compliance, language, budget and maintenance limitations.
Acceptance signal
What observable result proves the project solved the agreed problem?
Discovery output:
A short decision brief containing the problem, users, desired outcome, constraints, dependencies and unresolved questions.
03 · Scope system
Define the project by deliverables, boundaries and acceptance.
A scope is complete when both sides understand what will be delivered, what will not be delivered and how completion will be recognized.
What will exist?
Named pages, systems, files, functions, integrations, documentation and handover artifacts.
Concrete outputsWhat work is covered?
Design level, content population, responsive behavior, SEO, QA and deployment responsibilities.
Included effortWhat is outside the project?
Unlisted features, content creation, paid tools, complex backend work or ongoing support unless stated.
Protected boundaryWhat must the client provide?
Accounts, content, approvals, domain access, feedback and third-party decisions.
Shared responsibilityHow is done verified?
Page list, function tests, responsive checks, supported browsers, deployment and agreed quality criteria.
Observable completionWritten deliverables
- Clearly named output or function.
- Defined review and acceptance criteria.
- Dependencies and assumptions recorded.
- Included in timeline and pricing logic.
New requirement or changed assumption
- Was not written in the agreed scope.
- Changes an accepted deliverable materially.
- Requires new data, integration or architecture.
- Changes cost, timeline or risk.
04 · Proposal and pricing logic
Price the responsibility and uncertainty, not only the visible number of pages.
A proposal should connect the client's desired outcome to a delivery method, scope, timeline, responsibilities, commercial terms and acceptance process.
Build complexity
Design, content, development, integration, migration, QA and documentation effort.
Uncertainty
Incomplete content, unclear systems, external dependencies and fragile legacy work.
Business importance
How central the result is to credibility, operations, lead generation or revenue support.
Timeline pressure
Compressed delivery may require prioritization, extra availability or reduced flexibility.
Post-launch responsibility
Training, maintenance, monitoring, warranty window and future updates.
Transfer requirements
Source files, repository, accounts, documentation and intellectual-property terms.
05 · Delivery workflow
Use visible milestones so uncertainty is resolved before it becomes rework.
Confirm kickoff
Lock scope, contacts, communication channel, dependencies, timeline and first payment milestone.
AgreementPrepare the foundation
Create the repository, architecture, shared design system and initial content structure.
FoundationDeliver the first reviewable slice
Show a real page, flow or functional path early enough to validate direction.
AlignmentBuild approved scope
Complete the agreed deliverables using documented source-of-truth and update rules.
ExecutionRun structured review
Collect feedback against the scope and acceptance criteria rather than open-ended preference.
ControlComplete QA and release
Resolve defects, verify live behavior and prepare the accepted release package.
QualityHandover and close
Transfer assets, documentation, access and next-step maintenance guidance.
Ownership06 · Change control
Treat a new request as information before treating it as work.
Change control protects the client's budget and outcome while preventing hidden scope from damaging quality or timeline.
Capture the request
Write what the client wants and the reason behind it without committing immediately.
Compare with scope
Determine whether the request is a defect, clarification, revision or new requirement.
Assess impact
Estimate changes to effort, architecture, timeline, dependencies, QA and risk.
Choose a path
Include it, exchange it for another item, defer it or issue a paid change request.
Record approval
Update the delivery plan only after both sides accept the impact.
Agreed behavior does not work
Fix inside the original scope when it fails documented acceptance criteria.
Adjustment within the agreed output
Handle within the stated revision policy and review rounds.
Additional output or changed architecture
Assess and approve as a new change to cost, timeline or scope.
07 · QA and acceptance
Separate defects from preferences and acceptance from endless revision.
Required behavior works
Features and workflows match the documented acceptance criteria.
Approved materials are present
Text, images, data and links are complete enough for release.
Priority devices are usable
Navigation, forms, media and controls work on agreed desktop and mobile states.
Technical foundation is complete
Performance, accessibility, SEO, security and deployment checks match the project scope.
Responsibilities are closed
Client approvals and unresolved external dependencies are recorded.
Live result is verified
The deployed URL, domain, assets and final files are accessible and correct.
08 · Handover package
Transfer the operating system, not only the visible website.
A professional handover makes the result maintainable after the freelance engagement ends.
Final source package
Repository, changed-file patch, templates, generated-output rules and required assets.
Accounts and ownership
Domain, hosting, analytics, repositories and third-party tools transferred through secure channels.
Update instructions
Which sources are editable, how releases work and which files must not be edited directly.
Release record
Accepted scope, known limitations, tests completed and any deferred improvement backlog.
Owner walkthrough
A practical demonstration of the tasks the owner will repeat after handover.
Warranty and next phase
Define the defect-support window, maintenance options and what becomes a new project.
Manual GitHub workflow:
Deliver only new or modified files, preserve repository-relative folders and explicitly warn about hidden files such as
.nojekyll, .github or .gitignore.
09 · Maintenance model
Close the project clearly, then offer the right type of ongoing support.
Defect correction
A defined post-launch window for issues that do not meet the accepted scope.
Finite and scope-linkedRoutine updates
Small content, dependency, monitoring or compatibility work under a recurring agreement.
Predictable supportNew capability
Additional features, architecture or redesign handled as a new estimate or project phase.
New scope10 · Reusable templates
A delivery system becomes scalable when its documents are reusable.
These artifacts keep important decisions visible without forcing every engagement into the same solution.
Opportunity qualification
Problem, fit, authority, inputs, timeline, budget and key risk.
Discovery brief
Current state, users, outcome, constraints, dependencies and unresolved questions.
Scope of work
Deliverables, inclusions, exclusions, responsibilities and acceptance criteria.
Proposal
Approach, milestones, investment, payment terms, revision policy and validity.
Change request
Requested change, reason, impact, price, timeline and approval status.
Review log
Feedback item, classification, owner, resolution and acceptance state.
Release checklist
Content, functions, devices, SEO, performance, deployment and access.
Handover record
Files, accounts, documentation, training, known limitations and support terms.
11 · Common failure modes
Most difficult freelance projects fail through ambiguity, not technical inability.
Quoting before discovery
A fixed price is committed before the real inputs, constraints and dependencies are understood.
Deliverables described vaguely
Words such as “professional,” “full” or “modern” replace observable scope and acceptance criteria.
Client dependencies are invisible
Content, access or approvals arrive late, but the original delivery date remains unchanged.
Every request is treated as included
New requirements accumulate without impact assessment or written approval.
Feedback has no review structure
Different stakeholders provide conflicting preferences without one approval owner.
Handover stops at file transfer
The client receives the site but not the knowledge required to operate or update it.
Phase status
Fourth playbook complete. Phase 03 complete.
KhaiTriOS now has a full public operating library for website delivery, growth measurement, automation and freelance project delivery.