Custom website development does not need to take over the whole client project. It can operate as a specialist technical layer inside an agency-controlled workflow, while strategy, design, content decisions, client communication and final approval remain elsewhere.

For this to work, development cannot become a separate project running alongside the agency’s own process. Responsibility needs to be clear, implementation needs enough context and technical questions need a route back to whoever owns the relevant decision. Just as importantly, the agency needs opportunities to review what development produces before the work moves too far ahead.

Start by separating project ownership from development ownership

An agency can remain responsible for the website project without performing every part of it internally. Project ownership and development ownership are different things.

The agency may own scope, strategy, design approval and the client relationship, while another team owns frontend implementation, CMS development, integrations or other technical work. Another agency might divide those responsibilities differently. The specific split matters less than making it explicit.

Before work starts, both sides should know who owns scope decisions, who can approve changes, who resolves technical questions, who communicates with the client and who decides that a stage is ready to move forward. PMI’s stakeholder guidance follows the same broad principle: responsibilities, communication paths and approaches to requirement changes should be defined rather than left implicit.

“You want development to feel like part of the same project, not like a separate supplier receiving isolated tasks. That usually comes down to fairly simple things: shared context, clear owners for decisions, and an agreed way to bring questions back to the agency when needed.”

Evgeniya Karelina, Delivery Director at GetDevDone.

Bring development into decisions before they become expensive assumptions

Development does not need to sit in every design meeting, but technical input becomes useful before the agency locks decisions with significant implementation consequences.

Custom interactions, unusual responsive behavior, integrations, CMS requirements and accessibility constraints can all look straightforward during design while creating much larger technical implications later. If development sees those decisions only after client approval, the agency may have to choose between changing an approved solution, accepting more implementation work or forcing a technically awkward approach.

Figma’s research found that 55% of surveyed front-end developers wanted to enter the design process earlier. Its handoff guidance also recommends aligning on what is being built and discussing implementation while ideas are still flexible.

The practical point is not “involve developers early” as a general rule. Use development as a checkpoint where a design or requirement carries enough technical weight that revisiting it later would be expensive.

Treat the handoff as a transfer of implementation decisions, not design files

A development handoff is incomplete if developers can open every design file but still have to invent important behavior.

Static layouts may not explain responsive transitions, CMS editing rules, empty or error states, custom interactions, integration behavior or what happens when real content is longer than the mockup. Scope decisions and client-approved constraints may also live outside the design file entirely.

Figma’s current handoff framework is useful here because it treats handoff as alignment on what is being built, how it will be built, shared terminology and clear design intent rather than simply transferring files.

More documentation is not automatically better. Rewriting information that a developer can already inspect accurately creates maintenance work and more places for versions to diverge.

The useful material is what development cannot safely infer. If two competent developers could reasonably interpret an important requirement differently, either clarify the expected behavior or explicitly leave the decision to technical judgment.

Keep custom development visible through milestones and feedback loops

Custom development can involve enough technical work that waiting until the whole build is finished creates unnecessary risk. By then, a wrong interpretation may already affect several templates, components or integrations.

Staged review gives the agency opportunities to confirm that implementation still matches the intended project before too much work accumulates behind one assumption. DORA’s guidance on small batches makes the same broader software-delivery argument: smaller units shorten feedback loops and make it easier to revisit assumptions or course-correct.

This does not mean every website needs Scrum, continuous deployment or a review after each individual page. The size and frequency of checkpoints should match the project.

The Music Publishers Association project delivered by GetDevDone with The Playground provides a useful example of how this division can work. The Playground created the designs, while GetDevDone handled responsive frontend implementation and the WordPress backend. The project covered 11 pages, numerous JavaScript interactions, integration with the MPA’s CiviPlus system and accessibility work addressing key WAI/WCAG requirements. Delivery was divided into batches, and The Playground supplied comments and update requests as those batches were delivered.

That is the important workflow point. The development team owned substantial custom implementation, but the technical work still returned to the agency repeatedly for review rather than arriving as one opaque final delivery.

Route feedback and technical decisions through the right owner

Once development starts, new questions will appear. Some are straightforward implementation clarifications, while others affect design, scope, client expectations or the technical approach.

Those categories should not all be handled in the same way.

A developer should not silently make a business or client decision because the requirement is ambiguous. At the same time, the agency should not need to decide every low-level implementation detail that it has deliberately delegated.

A useful pattern is: development identifies the issue and explains the technical implications, the person who owns the affected decision chooses the direction, then implementation continues. This is much more precise than telling both teams to “communicate regularly.”

Client feedback also needs to return to development in a usable form. If comments arrive through account management, design files, email and direct messages at the same time, the development team has several instruction sources and no reliable indication of which one is final.

QA should reconnect technical delivery with the agency’s original requirements

Developer QA and agency review are related, but they answer different questions.

The development team should verify that the implementation works technically and matches the supplied requirements. The agency still needs to decide whether that implementation represents the website it has committed to delivering to its client.

This becomes especially clear with requirements such as accessibility. WCAG provides testable success criteria rather than treating accessibility as an abstract intention, which allows a requirement to move from design or project scope into technical verification.

In the Music Publishers Association project, accessibility formed part of GetDevDone’s implementation responsibilities alongside frontend work, WordPress development and integrations.

The broader lesson applies beyond accessibility: QA should reconnect technical output with the original delivery requirement instead of functioning only as a bug hunt after coding is complete.

Define where development responsibility ends at launch

“Development complete” and “agency ready to close the project” are not necessarily the same milestone.

Before launch, responsibility should be clear around deployment, production checks, repositories, credentials, CMS access and any documentation the agency needs after handover. The same applies to post-launch defects and continuing development support if those remain part of the engagement.

This does not require a large maintenance agreement for every site. It simply prevents the technical team from considering the project finished while the agency is still missing access, information or work needed to deliver confidently to the client.

The handback should therefore be treated as another responsibility interface: what does development stop owning, what does it continue to own and what information or access moves back to the agency?

Custom development does not need to own the entire website project

Custom development is one function in the broader delivery system, not necessarily the center of it.

An agency may retain strategy, UX, visual design, content and client management while delegating a defined technical scope. Another project may keep most development internal and use external specialists only for an integration or complex feature. Neither arrangement is inherently more mature.

Nor does every project benefit from extensive custom development. The technical scope should follow the actual requirement rather than become a goal by itself.

What matters is that custom development enters the workflow with clear inputs and decision rights, remains visible through review points and leaves the project with clear handover responsibilities. When those interfaces are explicit, separate agency and development teams can operate as parts of the same client-delivery process rather than as two projects that occasionally exchange files.