We build websites and the content systems behind them.
WAYF designs, builds, and migrates content platforms for established companies, institutions, and funded startups and scaleups. We work on new websites, CMS replacements, and existing platforms that need to support more brands, markets, or products.
What you can bring to WAYF
A new website or content platform
WAYF can take a platform from design through development and launch, including the publishing tools behind it. The content model, reusable page sections, and permissions are shaped around what your team needs to manage.
WAYF built CEB's events platform for its 70-year anniversary. Alongside the public site, the team built tools for participant imports, invitations, approvals, and attendance responses.
Technical details
The Participants Manager supports Excel imports, filtering by invitation and registration status, mass messaging to a filtered group, approvals for public-event submissions, and change history on participant records. CEB can reuse the platform for subsequent events. For CEB's 70-year anniversary, hundreds of invitations went through the platform. All invited participants responded, with almost no support tickets on the invitation flow.
Content inside a larger product
Some products need a CMS alongside a commerce engine, mobile app, or customer portal. WAYF builds the content system and connects it to the other parts of the product, including the tools the team uses to manage it.
WAYF designed and built Kaffy's coffee marketplace across web, iOS, Android, and a roastery panel. Payload runs alongside Medusa, which handles commerce.
Already have a platform and a team?
WAYF can join your engineers for an agreed piece of work or take on the platform's ongoing development. We start with a written audit and recommendation, then agree the work and responsibilities. For continuing support, a retainer covers a defined scope and period.
Discuss your existing platformWhat is agreed before development starts
Discovery establishes the requirements, constraints, and investment needed. For a defined build, the scope, price, delivery window, and acceptance criteria are agreed in writing, including what is outside the scope. Later requests come with a visible impact on cost and timing before they enter the plan.
Your team sees progress and QA evidence throughout delivery. Launch includes verification, release notes, and handover documentation. Ongoing support and new development are agreed separately.
Read how an engagement worksDelivery commitments
-
Engagement setup
Before delivery starts, the cooperation model explains scope sign-off, how new requests enter the plan, and how scope changes are handled. Both sides can refer back to it later.
-
Discovery
A dedicated discovery team defines the problem, why it matters, who it affects, the expected outcome, constraints, risks, and open questions. Discovery scales to the request: a clear ticket for small work, or workshops, feasibility checks, UX exploration and a product requirements document for a larger build. The investment is assessed before a delivery price is quoted.
-
Definition and sign-off
Scope is approved in writing by the right decision-maker, with a date. Out-of-scope items and acceptance criteria are recorded before implementation. A later request gets its own estimate and sign-off.
-
Scoping, planning, and design
Approved scope becomes a visible plan with tasks, owners, priorities, dependencies, risks, and a target delivery window. Technical feasibility is reviewed before the build starts. Active scope and future ideas stay separate; important decisions, including rejected proposals, are recorded and accessible to both sides.
-
Development and QA
Code is reviewed before it is merged. QA runs throughout delivery, and implementation is checked against signed-off scope. Release readiness is based on visible test evidence.
-
Release
The release outcome is verified after deployment. Release notes explain what changed for users, what limitations remain, and what follow-up exists. New scope waits for a later decision.
-
Maintenance and next scope
Defects, support requests, and new ideas follow separate routes. Support work does not consume capacity committed to planned development. New scope goes through discovery and approval, with a separate route for urgent production issues.
Common questions
-
Which CMS would you recommend?
Payload is a strong fit for custom publishing workflows, permissions, and content shared across sites or products. WAYF is an official Payload Partner and Top Contributor; the partner profile records the credential. For a marketing website that a team wants to lay out visually, Framer may be a better fit. We assess the requirements before recommending the platform.
-
Who owns the platform?
Your organisation owns the delivered code and content. The hosting arrangement and handover are agreed as part of the project. Where the chosen platform supports self-hosting, your team can run it or appoint another provider; hosting and third-party service costs still apply.
-
Can the price be fixed, and what if the scope changes?
For an agreed build scope, yes. New requests are assessed and approved in writing, with their effect on cost, timing, and priorities. Urgent production issues have a separate route.
-
How involved does our team need to be?
Your team helps define the requirements, supplies the necessary access and content, and approves the scope and key decisions. We agree who is responsible for those decisions at the start. Delayed access or approvals can affect the delivery date.
-
What happens after launch?
WAYF can continue with a defined support and development scope. Defects, support requests, and new features are handled separately so the responsibilities and capacity are clear. You also receive documentation for a handover to your team or another provider.
Tell us what you need the platform to do.
Send us the existing site or a short description of the project, along with any deadline you are working towards. We will discuss the fit and what the first piece of work should cover.