Dealokr logoDealokr
ENFR
Create a deal
ENFR
Create a deal

Use case · Web development and no-code

Move a web project forward through verifiable versions.

A web project is more than “a finished site”. It includes scope, dependencies, a test version, feedback, approval and handoff of access or documentation. The deal should make those transitions visible.

Create a Dealokr dealUse the guide

Dealokr supports the deal and its history. Payments and file permissions remain with the relevant providers.

The framework

A web project becomes manageable when each milestone shows progress.

The client should not have to guess whether a mockup, staging site or deployment is “the delivery”. Each version answers a question and prepares the next one.

  1. 01

    Scope

    Describe pages, flows, integrations, environments, responsibilities and exclusions.

  2. 02

    Milestone

    Define what is demonstrated or handed over at each stage.

  3. 03

    Acceptance testing

    Provide criteria, link, access and the person consolidating feedback.

  4. 04

    Approval

    Record the accepted version or specific revisions before the next transition.

  5. 05

    Handoff

    Name the included access, sources, documentation and transfer tasks.

In practice

Make the next action clear.

Each step should show who decides, what needs checking and what follows. That makes the workflow useful day to day.

01

Write the scope as a testable system.

A useful web scope names pages or flows, integrations, content sources, environments, key browsers or devices and exclusions. It can also identify client dependencies: access, copy, media, provider accounts or product decisions.

This gives a useful basis for checking whether a test version meets the agreed phase, without turning the deal into an endless specification.

02

Treat staging as review, rather than implied handoff.

A staging link lets the client check flows, content or behaviour. It does not necessarily mean the project is finished, production deployment is included or technical access is handed over. Explain what to test, how to report a problem and who approves.

Tie feedback to a version or environment. A request adding a flow, integration or priority can then become a separately priced phase rather than an indistinguishable bug.

03

Prepare access before final delivery.

Repositories, hosting, domains, CMS, third-party accounts, documentation and access keys have different transfer processes. List the handoff package and each account owner. Verify permissions with the external provider before declaring access delivered.

Dealokr keeps the decision record and handoff history. It does not independently host or control your technical platforms’ permissions.

Operational checklist

The web acceptance and handoff checklist.

Use it before sending a test link or closing a development phase.

01

The milestone

  • The version meets the current phase’s scope.
  • Client dependencies are identified.
  • The demo or link is associated with a clear version.

02

Acceptance testing

  • The client knows which flows or criteria to check.
  • Feedback is consolidated by a person or agreed route.
  • Scope changes are distinguished from defects within the phase.

03

The handoff

  • Included repository, CMS, hosting, documentation and access are listed.
  • Responsibility for deployment or continuation is clear.
  • External permissions are checked before handoff.

Useful wording

Simple language for the moments that matter.

Adapt the bracketed details to your situation. These examples clarify the project; they are not legal clauses.

At the demo

Guide acceptance testing.

“This version covers [scope]. Please test [flows] on [environment] and approve or list specific issues by [date].”

The client knows what to do with the staging link.

When a request arrives

Distinguish a defect from a new need.

“This point [matches / does not match] the current milestone’s scope. I will handle it as [a correction / the next phase], with [action and date].”

This keeps feedback manageable for prioritisation.

At transfer

Name the access being handed over.

“The approved version is [version]. The handoff includes [repository, CMS, documentation, access]. Each external service remains controlled by its own platform permissions.”

The client can check project continuity after your engagement.

A system, rather than an abstract promise

A deal becomes reliable when everyone sees their next action.

The value comes from connecting scope, payment, review, approval and handoff. Keep your commercial documents, obligations and external permissions current separately.

Common questions

Useful answers before starting the project.

Is staging a final delivery?

Not necessarily. It is often a review environment. The deal should specify what approves the phase and what is included in final handoff.

How should I handle technical access?

List it in the handoff and verify permissions with each external provider. Specify the account owner and who handles deployment.

Does Dealokr replace GitHub, Vercel or a project tool?

No. It organises the deal and its history around those tools, which retain their technical roles and permissions.

A protected next deal

Keep payment and final handoff in the same deal.

Create a clear project for you and your client, with a protected payment flow through the configured provider, protected delivery and visible approval.

Create a Dealokr dealSee the workflow

Continue

01See how it works02Explore resources03Create a clear deal