Most web agencies send you a proposal. You accept it, pay a deposit, and then for weeks you’re not quite sure what’s happening. Occasional check-ins. A staging link. Another one. Then a final invoice.

Communications Directors I’ve worked with describe this as one of their most frustrating professional experiences. Not because the result is always bad, but because it feels like being a passenger in a vehicle you’re paying for, without knowing the route.

This post is how I manage projects at Socialectric: every stage, every decision point, what I do and what I need from you. If you are considering working with me, read this first. It will either confirm the fit or save us both a wasted call.

Before Anything Starts: The Discovery Call

Every project begins with a 15-minute discovery call. Its purpose is to tell you honestly whether I can help, and what that help would look like.

I ask about four things:

  • Budget and authority. Your budget, and who holds the decision.
  • The trigger. What’s not working with your current site, and what’s prompted you to act now.
  • Stakeholder complexity. Who uses the website, and for what.
  • Technical scope. How many pages, what functionality, and whether brand guidelines exist.

I’m not selling on the call. I’m working out whether you need a Blueprint Audit first, or are ready for scoped work. Most organisations I work with benefit from starting with the audit, because the strategic clarity it creates makes everything afterwards more efficient.

How Projects Are Structured

Every engagement follows one of two paths, depending on your organisation’s complexity.

Path 1: Blueprint Audit first

This is the path for most established NGOs: those with multiple stakeholder groups, Board oversight, governance pressure, or significant organisational transitions underway.

The Blueprint Audit is a standalone diagnostic that runs over four weeks. It:

  • maps your stakeholder landscape;
  • audits your current site technically and from a content perspective;
  • produces a Board-ready strategic roadmap.

You own the findings whatever happens next. Nothing in the report depends on you commissioning a build: the fee is payable whatever the audit concludes, which is precisely what keeps the recommendations honest. A diagnostic that pays for itself only when it finds work is not a diagnostic.

If you then proceed, implementation is scoped from the audit’s findings, not quoted from a price list. The audit tells both sides how big the job actually is, so scope, deliverables and schedule are agreed then and written into a Statement of Work.

After launch there is an optional Monthly Partnership: continuous design and development capacity on the site, with monitoring, updates and backups underneath it, and a written report each month. It is a separate decision from the build.

Path 2: Straight to scoped work

For organisations with clear, straightforward needs (no significant stakeholder complexity, no Board-level reporting requirements, no major platform migration), work can begin without the audit.

I’ll be honest on the call about which path fits, and I won’t push the audit if the simpler route is right. If you are weighing me against other people, how to evaluate a nonprofit web consultant is written to be used on me as much as on anyone else.

Stage 1: Onboarding

Once a contract is signed, I send an onboarding document. It covers two things at once.

The practical logistics: access credentials for your existing site, brand assets, the domain registrar login and any existing analytics accounts.

The strategic context. These questions go deeper than the discovery call:

  • your organisation’s history and trajectory;
  • how website decisions have been made before;
  • the Board’s level of visibility;
  • what content exists and what needs creating;
  • who manages the site after launch;
  • what success looks like at six months.

For Blueprint Audit projects, these written answers are the foundation for the stakeholder interviews.

I ask for the document back within five working days. It is the first indication of how the project will flow. In my own projects, how quickly a client completes onboarding has been a reliable signal of how smoothly feedback goes later. That is an observation from my own casework, not a sector statistic.

Stage 2: Stakeholder Interviews (Blueprint Audit)

For Blueprint Audit engagements, I hold at least two stakeholder interviews before any design or strategy work begins: two people, two separate calls. For more complex organisations (larger teams, federated structures, significant Board involvement) I hold three or four.

The primary decision-maker (60 minutes)

Usually the Executive Director or Communications Director. I go beyond the discovery call. I want to understand:

  • how the organisation has evolved over the past three to five years;
  • what the Board expects from the digital presence;
  • what feedback you’ve had from donors or beneficiaries about the current site;
  • how content decisions get made internally;
  • what would make this project a failure in your eyes.

That last question is the most important one I ask.

A secondary stakeholder (45 minutes)

Typically a Programmes Director or Development Director. Their view of the website is usually quite different from the decision-maker’s, and that gap is where the most useful insight lives.

If a Programmes Director tells me beneficiaries often call to ask questions the website should answer, and the Communications Director hasn’t mentioned it, that is an alignment problem. It gets resolved before the site is built, not after.

A Board representative, where it matters

I push to speak to one when the organisation is in significant transition, or when the Board has raised active concerns about the website. The Charity Commission’s guidance on decision-making for charity trustees asks trustees to be sufficiently informed, to take account of all relevant factors, and to record how significant decisions were reached. A website rebuild is usually a significant decision, and it is cheaper to inform the Board now than to revisit an approved design later.

What the interviews produce

I map where stakeholder perspectives align and, more importantly, where they diverge. The gaps between what different people believe the website should do are usually the root cause of why the current site isn’t working.

The audit report maps those gaps explicitly and proposes a path stakeholders can agree on before any pixels are placed. What to expect during a Blueprint Audit walks through the deliverable itself.

Stage 3: Art Direction

The visual direction is set before any design work starts. With a Blueprint Audit, it follows the audit and draws on its findings. Without one, it is one of the first things I tackle.

I send a structured set of prompts:

  • Aesthetic style. Distinct categories (modern minimal, corporate professional, editorial, warm humanist, bold and campaigning). You select up to three that represent how your organisation wants to be perceived.
  • Tone. Should the site feel serious and authoritative, warm and approachable, bold and campaigning, or calm and trustworthy?

Asking for three choices rather than one is deliberate. It gives me room to find the common ground and make a considered recommendation, rather than execute a single instruction. That is my job: to translate what you know about your organisation into a visual direction for audiences who don’t know you yet.

From those choices I build a moodboard in Figma: reference sites, colour direction, typography combinations and photographic style. It is a working reference, not a deliverable in itself. You approve it before design begins. If the brand assets are strong and the direction is clear, this stage moves quickly.

Stage 4: Design

How long design runs depends on complexity. A smaller site with clear brand guidelines and a simple stakeholder structure moves faster. A larger site with more pages, multiple stakeholder pathways and brand development takes longer. The schedule is agreed in scoping and written into the Statement of Work, not quoted upfront.

I work in Figma. When a key design stage is complete (typically the homepage, a core interior template, and specialist pages such as programme listings or donation flows), I send you a screen recording walking through what I’ve built and why. I don’t schedule a call.

That is intentional:

  • Many of my clients are in different time zones, and scheduling calls creates friction that slows momentum.
  • You can watch when it suits you, pause, rewatch, and come back with considered feedback rather than on-the-spot reactions.
  • It leaves a record of every decision and its reasoning, which matters when a trustee asks months later why the homepage works the way it does.

I ask for feedback within 48 hours where possible. This is the most important expectation I set with every client.

Design projects stall when feedback cycles stretch from days to weeks. I then have to move to other client work to keep the practice running, and coming back to your project takes time that prompt feedback would have saved. I raise it not to be transactional, but because clients who understand it upfront consistently have better project experiences.

Stage 5: Development

Once design is approved, development begins in Webflow, using the Lumos framework for structural consistency and editorial safety.

How long the build runs is set during scoping and written into the Statement of Work. I won’t quote a number before the scope exists, for a reason. The largest variable in any build is not the code: it is how quickly copy, images, legal sign-off and Board approval come back from your side.

A build window measured from the day work starts quietly blames you for the part you control. The Statement of Work names what each side owes and by when, which is a more honest instrument than a headline number of weeks.

If the site has to talk to a CRM, a donation platform or a mailing tool, that integration is scoped here, not discovered late. Integrating a CRM with a nonprofit Webflow site sets out the questions to settle first, because a data flow agreed at the start is a configuration and the same flow raised mid-build is a change of scope.

I develop on a staging site in my agency workspace. You have no live edit access during the build, deliberately: partial builds with concurrent edits create errors that take time to resolve. Progress updates come as screen recordings at key milestones, with email for day-to-day communication.

Stage 6: Content Migration and QA

Before launch, content moves from the old site or from your documents into the new build. For smaller sites I handle migration directly. For larger sites you contribute, which is why content ownership and team capacity come up in the onboarding questionnaire.

Migration is also where URLs change, and every changed URL needs a redirect. Migration planning and governance covers what gets lost when that is an afterthought: inbound links from funders, citations in published reports, and QR codes printed on materials nobody can reprint.

QA covers:

  • the full site across devices and browsers;
  • form testing and submission routing;
  • accessibility testing against WCAG 2.2 AA;
  • redirect verification for any URL that has changed;
  • analytics configuration;
  • DNS.

Automated tools such as WAVE and Lighthouse are part of that and not the whole of it. The W3C is explicit that some accessibility checks cannot be automated and require manual review, so keyboard operation, focus order, heading structure and alternative text are checked by hand.

I don’t launch a site that hasn’t passed all of these. How to prepare a nonprofit website to go live is the same checklist written for your side of it.

Sign-off before launch is by email. I send a screen recording of the complete site walkthrough, confirm all agreed functionality is in place, and ask for explicit written confirmation to proceed. That email is the formal go-ahead. It is written rather than verbal so that what was approved, and by whom, is on the record.

Stage 7: Launch and What Happens Afterwards

On launch day the domain is pointed at the host via DNS, SSL provisions automatically, and the site goes live. For most clients this is straightforward. If you have never dealt with DNS before, I walk you through it in a screen recording so there are no surprises.

After launch I record a training walkthrough for whoever manages content day to day. It is specific to your site, not a generic platform tutorial, and covers the pages and collections your team will actually change. It is one half of a handover; what a real website handover contains is the other half, and worth reading before you need it.

You own the website. Hosting is paid directly by you to the platform, not through me. I keep access through my agency workspace so I can carry out ongoing work, but the site and the account are yours, and you are not dependent on me to keep it running. If you ever pause or stop, the site keeps working exactly as it is.

The Charity Commission expects trustees to identify, assess and manage the risks to their charity. Sole-supplier dependency on your main public-facing asset is one worth naming explicitly. The arrangement above exists so the entry on your risk register can honestly say no.

Where the Monthly Partnership is taken up, it is continuous work on the site, not a retainer held against emergencies: new pages, campaign launches, performance work, accessibility monitoring, CMS updates and strategic support, with a written report each month. That is what keeps a site evolving instead of going out of date.

What You Are Responsible For

I take on the technical and strategic work. But projects are collaborative, and some things only you can provide:

  • Materials at onboarding. Brand assets, existing content and access credentials, promptly.
  • Design feedback. Reviewed and returned within 48 hours wherever possible.
  • Content accuracy. I can edit and structure it, but I can’t verify that programme descriptions, team bios and policy documents are current.
  • Internal approvals. Coordinating them, particularly where several people need to sign off on content or design.

That last one is where a website project quietly becomes a governance question. If nobody owns the answer to “who approves this”, every decision becomes a negotiation, and the schedule in the Statement of Work is the first casualty.

Naming an approver per decision type, in writing, before the build starts, is the cheapest intervention available to you. It is the same argument as treating the website as a governance problem rather than a design problem.

Projects go smoothly when a client treats their own responsiveness as a project input, not an organisational convenience. That isn’t a criticism. It is how collaborative work functions.

Is Socialectric the Right Fit?

I work with established nonprofits and NGOs, typically with annual budgets of £2–5 million, where the website is under governance pressure, serving multiple stakeholder groups, or needs an infrastructure approach rather than a cosmetic refresh.

I don’t take every project. If your budget, scope and context aren’t a match, I’ll tell you on the discovery call. If they are, the process above is what working together looks like.

If you are thinking seriously about a website project, the most useful first step is a Blueprint Audit: four weeks, a Board-ready strategic roadmap, and no implementation commitment before anyone knows what the site actually needs. What it covers and what it costs are on the Blueprint Audit page. If your situation is more straightforward, say so on the call and I’ll point you at the shorter route.

Related reading: