Make the risky parts explicit.
We would rather tell you a repair is enough than sell you a rebuild you do not need. Scope, price, acceptance and handover belong in writing before work begins.
A framework is not a strategy.
The starting point is the current system: what your customers need to do, what your team has to maintain, and what the evidence says is getting in the way.
Sometimes the right work is a focused repair. When a replacement is justified, we plan continuity, quality, control and acceptance before choosing the implementation.
You should own what you pay for. At handover you get the code and design files we made for you, the documentation, and control of the accounts the site runs on, and a care plan later doesn't change that. Website builders differ in how much of a site you can export, so before you choose one, check what its own help pages say you can take with you.
Compare what eight website platforms let you export See the work and its contextEight principles.
One clear standard.
These are the decisions and records we expect a client to be able to examine, from the first recommendation to handover.
- 01
Diagnose before recommending a rebuild
A migration is justified only when the business goal, current platform, operating cost, content, integrations, and measured constraints support it. Sometimes repair is the better answer.
- 02
Define the scope before the price
A proposal should list deliverables, exclusions, dependencies, client responsibilities, third-party costs, acceptance criteria, payment milestones, and change terms.
- 03
Treat URLs and content as business assets
Migration planning includes a URL inventory, redirect map, content model, metadata, analytics, forms, integrations, cutover sequence, monitoring, and rollback conditions.
- 04
Measure performance honestly
A performance target is meaningful only when it names the pages, device and network profile, tools, number of runs, measurement date, third-party state, exclusions, and remedy.
- 05
Put control and handover in writing
Repository, hosting, domains, credentials, data, pre-existing materials, open-source licenses, ownership-transfer timing, backups, and retention should not be implied.
- 06
Make changes explicit
When a request falls outside the accepted scope, the effect on cost, timeline, testing, and responsibility is documented and approved before the work changes.
- 07
Ship accessibility, privacy, and security work
Keyboard access, readable contrast, consent, data minimization, endpoint controls, dependency checks, monitoring, and rollback are release responsibilities, not decorative badges.
- 08
Do not promise systems we do not control
A technical implementation can reduce risk and improve foundations, but it cannot guarantee rankings, revenue, conversions, field performance, uptime, or AI citations.
The proposal should make the work checkable.
Before you agree to a project, you should be able to find these answers in the written scope.
- 01What is included and excluded
- 02Who supplies content and access
- 03How acceptance is measured
- 04What happens when scope changes
- 05Who controls accounts and source
- 06How launch and rollback are handled