A web project with a clear beginning, scope and handover.
Build is for an agency—or a business buying directly—that has one website, landing page or defined web outcome to get delivered. You can arrive with a finished brief or simply with the business result you need.
Not “some web development”. A defined delivery responsibility.
Build exists for projects where somebody needs to take a web outcome from agreed scope to an actual deliverable. That may be a new landing page, a small or medium website, a campaign site, a redesign, a frontend implementation or a defined custom feature.
The useful boundary is simple: before production starts, we agree what WebAgencyOn is responsible for, what the agency/client is providing, what must work at handover and which dependencies sit outside our control.
A brief is not permission to start accumulating open-ended hours. We clarify the work, agree the commercial scope and only then begin production.
Build works best when there is one project to finish.
Good fit
- New business or service website
- Landing or campaign page
- Existing site replacement
- Approved design that needs production
- Defined web functionality
- Deployment and launch as part of the scope
Probably another route
- Continuous stream of agency work → Delivery Partner
- Complex integrations/infrastructure → Technical Partner
- Simple direct landing package → USONL
- Open-ended custom digital project → 4ONL
You should be able to imagine the whole transaction before contacting us.
We do not treat production like an empty folder.
If a site already exists, the first task is understanding what is live and what must be preserved. The document root, current application, email/DNS dependencies, redirects, forms and files may matter even when the visual site is being replaced.
The Project Builder includes a dedicated “We already have a website” form so you can tell us what must stay, what is broken and whether a backup already exists.
identify production → back up before destructive change → deploy approved work → verify → create a post-launch backup where appropriate.
The easiest deployment can be the one where you never send us your password.
Where practical, the client or agency contracts the domain and hosting directly with the chosen provider. That keeps billing details, identity information, renewals and primary account credentials with the party that actually owns the service.
For deployment, we prefer collaborator/delegated access. If that is awkward, an attended AnyDesk or TeamViewer session can be simpler: you open the hosting dashboard in your browser, log in yourself and remain present while we upload and configure the site.
Unrelated private folders or applications can stay closed. Primary passwords, recovery codes and API secrets should not be sent through project forms.
Written context first; calls and remote sessions when they add value.
If the project changes, the agreement changes before the bill does.
Build is scoped around the work we can actually define. Third-party licences, hosting, domain registration, paid APIs, premium assets and ongoing support are not silently assumed to be included.
If a new requirement materially changes the agreed project, we stop treating it as if it were already priced. The additional work is clarified before it is added. That protects both sides from “I thought that was included” conversations.
Low-maintenance by design, not maintenance-free by promise.
For suitable sites we prefer fewer moving parts—no CMS, plugin ecosystem or database unless the project genuinely needs them. That can reduce routine maintenance substantially.
It does not mean domains, hosting, SSL, forms, external services, browsers, content or future security requirements can never need attention. If something does need attention, the Project Support route gives you a clear way back in.
Questions we would expect before saying yes.
Do I need to know which CMS or framework I want?
No. If a specific technology is a real constraint, tell us. Otherwise we select the implementation after understanding what the project needs to do.
Can you work directly for a business, not only an agency?
Yes. WebAgencyOn is agency-oriented, but a business with a defined web project can use Build directly. For a simple fixed landing product, USONL may be the cleaner route.
Do I have to give you my hosting password?
Usually not. We prefer delegated access or an attended remote session where you log in yourself.
Who should own the domain and hosting?
Normally the intended client or agency. We can recommend a provider and guide the setup while the purchaser enters its own billing and account information directly.
What happens to my current website?
We first establish what is live and what must be preserved. Where supported and included, we take a pre-change backup before replacement.
Can I see the site before it replaces production?
Yes where appropriate. A private review environment can be used before final deployment.
What if I ask for something new halfway through?
We clarify whether it changes scope. Material additions are agreed before being treated as included work.
What if something breaks after launch?
Use Project Support with the project reference and business impact. Support outside the agreed project or delivery period may need separate scope.
Start with the project, not the technology.
Tell us what should exist when the work is finished. We will ask for the other context only if it matters.