Industry

Nonprofit and NGO Websites on Drupal

Knowledge hubs, member portals and document repositories for nonprofits, NGOs and intergovernmental organisations, built on Drupal and handed over with the source code.

Talk about a nonprofit project SPREP and PIRT case studies

An engineer reads it and replies within one business day.

  • Built for conservation networks around SPREP
  • PIRT and Pacific NbS live and maintained
  • Warranty of 1 to 3 years

Who we build this for

  • Intergovernmental organisations
  • Regional secretariats
  • NGOs
  • Foundations
  • Research networks
  • Grant-funded programme teams

Case studies

What have we built for conservation networks and programmes?

The platforms below serve the conservation networks around the Secretariat of the Pacific Regional Environment Programme (SPREP). We designed and built both, both are live, and we maintain them.

  • Pacific Islands Roundtable: the coordination platform for the Pacific Islands Framework for Nature Conservation and the Vemööre Declaration, whose members include regional bodies and international conservation organisations. It carries the specialist working groups, the Pacific Conservation Database, briefing notes and annual reports, and runs registration and programme information for the Pacific Islands Conference for Nature Conservation and Protected Areas. SPREP introduced the Roundtable to us, and we built its site as a site of its own.
  • Pacific NbS Resource Hub: the nature-based solutions knowledge platform, gathering tools and guidelines, case studies, financing opportunities, community guides, training toolkits and research evidence into one searchable place, with a project database and registered member accounts for contributors. SPREP commissioned it from us, and we developed it from the sprep.org base.

Ms Utulei Lui, Project Manager for the PPIN project at SPREP, wrote this for our reviews page:

The Weebpal team are awesome and easy to work with. They have made the design and development of the "Pacific NbS Resource Hub" a breeze and they are quick, efficient and I am really happy with the quality of their work and I highly recommend them.

The rest of our work for SPREP, from sprep.org itself to the SPREP Virtual Library, PRISMSS and the Fagogo staff intranet, is set out on the government and intergovernmental page, together with the public-sector side of the same work: procurement, accessibility and supplier independence.

See more of the work

What shapes the work

What makes NGO website development different from commercial work?

The engineering is not harder than commercial work. The constraints around it are different, and they are the part that tends to be discovered late.

  • The money is project-shaped and the platform is not.

    Funding arrives as a grant with a start date, an end date and a deliverable attached to it. The platform that grant pays for has to keep running long after the grant has closed, usually without a line item anywhere that covers doing so.

  • You report to donors as well as to users.

    Someone has to be able to show what was produced, what it cost, and what it is being used for. That is a requirement on the platform itself (content that is attributable to a programme, a country and a funding stream), not a favour asked of the web team at reporting season.

  • The audience is spread across countries, languages and connections.

    A regional body serves members in different territories, in more than one official language, on connections that are not uniformly fast. Page weight that is invisible on an office fibre line is a real barrier on an outer-island connection, and bilingual is a content model decision rather than a plugin you switch on at the end.

  • Knowledge is the product.

    Reports, guidelines, datasets, media. If a practitioner cannot find the document they came for, the platform has failed however good it looks. Findability is the actual requirement: search, facets, curated collections, and metadata that is filled in consistently by contributors spread across many organisations who do not report to you.

  • The people who run it are not developers.

    Programme officers, librarians and communications staff publish the content, often part-time and alongside the job they were actually hired for. For them the editorial interface is the product, and a content model that only makes sense to the person who designed it will quietly stop being used.

  • Institutional memory is the asset.

    Staff rotate, consultants come and go, projects end. What has to survive is the archive and the ability to keep adding to it without hiring the original supplier back.

  • Procurement asks who can maintain this afterwards.

    Many donors and public bodies require evidence that the delivered system can be operated independently of whoever built it. A platform only its vendor can run fails that test on paper before it fails it in practice.

What goes wrong on nonprofit web projects?

  • The site that dies with the grant.

    Built on a proprietary platform or a per-seat licence the organisation cannot renew, it goes quietly offline two years later and takes the archive with it.

  • The rebuild that loses the back catalogue.

    A redesign that treats existing publications as content to migrate "if there is time" ships a handsome new site on top of a broken URL history, and every citation and bookmark pointing at the old documents breaks at once.

  • The repository nobody can search.

    Several hundred PDFs uploaded with inconsistent metadata, so the only way to find a document is to already know that it exists.

  • Supplier dependency.

    No repository, no documentation, one agency that knows how it works. Every subsequent change becomes a procurement exercise, and the price of the second change is set by the fact that nobody else can bid for it.

  • The intranet and the public site that disagree.

    Staff maintain one set of documents internally and another externally, and within a year nobody can say which version of a guideline is current.

How we build it

How does WeebPal approach nonprofit Drupal development?

Everything is Drupal and open-source infrastructure, and everything is handed over in full.

  • Nothing to renew

    There is no licence to renew, no seat count, and no component of the stack that stops working because an invoice went unpaid. That is not an ideological position: it is the only arrangement under which a platform funded by a three-year programme can still be running in year six.

  • Discovery that runs on your material

    Work starts with a discovery, before any contract and at no charge, that produces the content model, the architecture and a working prototype of the parts that carry the most risk, rather than a specification document. For a knowledge platform that is almost always the taxonomy and the submission workflow, so that is what we put in front of your librarians and programme officers first, running on your own material.

    Correcting a content model in week two costs a conversation. Correcting it in month five costs a migration.

  • Constraints asked about early

    We ask early where the data is legally or politically required to live, and which existing systems have to keep running unchanged, because both change the architecture rather than the schedule. Both are routinely discovered late, and both are far cheaper to design for than to retrofit.

Which of our services does this work use?

  • Intranets and portals: knowledge hubs, member portals and document libraries, such as the NbS Resource Hub with its member accounts.
  • Website development: public sites designed on real content and accessible from the start, such as the Pacific Islands Roundtable.
  • Drupal multisite: one base for an organisation's programmes and networks.
  • Drupal website redesign: a new interface for a site whose content and archive still work.
  • Drupal migration: an older site moved onto current Drupal with its publications and their addresses.

Why does owning the source code decide whether the platform outlives the grant?

Every engagement ships the full repository: application code, custom modules, theme, build tooling and deployment configuration. It runs on your servers, your cloud account, or ours, and the choice is reversible. Another team can pick it up, because Drupal coding standards, automated test coverage on the code we ship and documentation written for a developer who has never met us are deliverables rather than extras.

For a commercial client that is good practice. For an organisation whose funding is renewed in cycles it is the difference between a platform and a liability: when the programme that paid for the build ends, the successor programme can take the same codebase to whoever it likes, including an in-region developer, which is usually cheaper and is often a donor preference. The full argument is on why you own what we build.

How do you fit a Drupal build inside a grant budget?

Scope is agreed before a price is committed, and the price is then fixed. Discovery comes before the contract and is not invoiced: it produces the architecture, content model, integration map and phased plan with acceptance criteria that the fixed price is committed against. That sequence exists because a grant application usually has to name a figure before the work is understood well enough to name one honestly, and a costed architecture is a far better thing to attach to a proposal than an estimate.

Where a programme is funded in tranches, delivery is phased to match: each phase is a working, deployable increment with written acceptance criteria rather than a fraction of an unusable whole. If the next tranche does not arrive, what has been paid for is already in production and already yours. Our bands and milestone structure are on the pricing page.

What happens at handover, and what does the warranty cover?

Handover is a deliverable in its own right, not the last afternoon of the project. Delivery carries one year of warranty as standard, extendable up to three years by agreement, worked by the team that built the system rather than by a separate support desk reading the ticket for the first time. What the warranty covers, and what it does not, is written down.

What an organisation receives at handover

DeliverableWhat it means in practice
Full repositoryApplication code, custom modules, theme, build tooling and deployment configuration, under your own account.
Deployment configurationEnough to stand the platform up on your own infrastructure or your own cloud account, in your own region if that is a requirement.
Developer documentationWritten for a developer who has never met us, because the point is that a successor team can read it.
Editor and administrator trainingFor the programme officers, librarians and communications staff who will actually publish into it.
WarrantyOne year included on development projects, extendable up to three years by agreement, with security releases applied during it.
Ongoing operationA separate support and maintenance arrangement (security updates once the warranty term ends, core upgrades, incident response under SLA), taken up only if you want it.

We are equally willing to hand the platform to your own team or to an in-region developer and answer their questions while they take it over. Moving an existing site off an older Drupal version is handled by our Drupal migration practice, which includes keeping the URL history and the published archive intact.

What do nonprofits ask before choosing a Drupal partner?

We have no developers on staff. Is Drupal too much for us? The question that matters is not which CMS, it is whether the editorial interface matches how your people actually work. That is a design constraint from the first week, and it is why the content model goes in front of your programme officers as a running prototype rather than as a diagram.

Can our archive of existing publications come across? Yes, and it should be scoped as part of the build rather than left to the end. Migration includes the metadata and the old URLs, because a repository whose citations stop resolving has lost the thing that made it worth migrating.

Can we host it ourselves, or in our own region? Yes. It is standard open-source infrastructure, so nothing in the build forces the choice, and data residency requirements are an architecture input we ask about during discovery.

What if the funding stops mid-project? Phased delivery means each completed phase is deployable and already handed over. You are not left holding a half-built system that only becomes useful at the end.

Can another supplier take this over later? That is the intended outcome, not an edge case. Coding standards, tests and documentation are deliverables precisely so that the answer is not "only WeebPal".

Do you work with organisations outside the Pacific? Yes. The Pacific estate is where most of our nonprofit work happens to sit, but nothing in the approach is regional: the constraints described on this page are the ones grant-funded organisations share everywhere.

See it working before you commit

We build a working prototype first, so you decide against something real.

  • Full source code, handed over
  • Price fixed once the architecture is agreed
  • Warranty of 1 to 3 years
Talk about a nonprofit project See what it costs All sectors