Nonprofit & Intergovernmental

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.

Scope is agreed before a price is committed, and the price is then fixed. Discovery is paid, and its output (architecture, content model, integration map, phased plan with acceptance criteria) is yours whether or not you continue with us, and is credited against the delivery contract if you do. 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.

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

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.

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.