The most directly comparable project is our work with AMI - International Medical Assistance Foundation, a humanitarian NGO operating in 23 countries. When we were engaged, their WordPress site had not had a technical review in four years.

Key findings from the audit included:

• 37 active plugins, of which 14 were either unused, had critical CVEs, or were causing conflicts with WooCommerce. Removing 11 of them improved page load by 1.8 seconds with no loss of functionality.
• The Stripe integration was running on a deprecated API version. Recurring donation tokens were at risk of breaking in a Stripe migration scheduled for 6 months later - a live revenue threat we were able to address before it became an incident.
• The hosting server was running PHP 7.2, two major versions behind support. Memory limits were set to 128MB, causing timeout errors on the donation checkout under moderate traffic.
• Duplicate content across multilingual pages was causing significant SEO cannibalisation - the site was ranking for the wrong language variant in several key markets.

These findings directly shaped the design and architecture decisions. Rather than building on the existing plugin stack, we recommended a clean-slate WooCommerce setup with a curated set of 12 vetted plugins. The hosting migration was executed before any front-end work began. The multilingual SEO remediation informed the entire hreflang architecture for the rebuilt site. The project launched on time and within budget, with a 68% increase in online donations in year one.

We start with a simple principle: donors give to people, not organisations. The design job is to make an anonymous person in a country they may never visit feel personally connected to the impact of their €50.

In practice, this means:

• Impact specificity over generality.
  "€50 clears 100 sqm of minefield in Cambodia" is far more powerful than "your donation helps us clear landmines." We work with APOPO's content team to build a full impact equivalence library - every donation amount mapped to a specific, tangible outcome.
• Named individuals, not statistics.
  A photograph and a first name on a programme page does more work than any data visualisation. We design content modules that foreground the people affected - demining operators, TB patients, community nursery workers - not just the organisational mission.
• Emotional momentum through the checkout.
  Most charities design a great programme page and then drop the donor into a generic WooCommerce checkout. We carry the narrative through - the checkout page reinforces the specific impact of what the donor is about to give, and the thank-you page closes the emotional loop with a personalised message and the PDF certificate that makes the gift feel real.
• The HeroRAT adoption mechanic is already exceptional.
  The idea of giving a specific rat a name and receiving updates about it is one of the most effective individual giving mechanics in the sector. We would build on this - not redesign it.

We use a structured CRO cycle that runs continuously after launch: Measure → Hypothesise → Test → Learn → Iterate.

• Baseline measurement:
  GA4 funnel reports on every step of the donation journey - programme page → donation form → amount selection → checkout → confirmation. We also install Hotjar on key pages to capture session recordings and heatmaps, which often reveal friction points that analytics alone miss (e.g., the "custom amount" field being missed, or the recurring toggle being ignored).
• Quantitative + qualitative:
  Data tells us where people drop off; user testing tells us why. We run informal usability sessions with 5-8 representative donors before any major flow change.
• A/B testing framework:
  We use VWO or Google Optimize (now migrated to GA4 experiments) to test specific hypotheses - default donation amounts, CTA copy, progress indicators in checkout, one-page vs. two-page flow. We typically run 3-4 simultaneous tests with a minimum 2-week runtime and 95% statistical confidence threshold before declaring a winner.
• Emotional resonance testing:
  We test copy and imagery variants, not just UX mechanics. "Adopt a HeroRAT today" vs. "Give Magawa a retirement gift" - the emotional framing of a CTA can move conversion rates by 15-25% on its own.

For APOPO specifically, the biggest quick win is likely default amount optimisation. Most NGOs set defaults that are too low. We will analyse the distribution of existing donation amounts and test anchoring the default at a higher, specific-impact amount.

SEO has been a core service since Codedesign was founded in 2012. We have a dedicated technical SEO team and have managed SEO strategy for clients across 14 markets and 8 languages. Our approach is technical-first: we believe that most SEO problems are architectural problems, not content problems.

For APOPO specifically, the most critical SEO work in Stage 1 is migration integrity - preserving existing rankings through a rigorous 301 redirect strategy, maintaining URL structures where possible, and ensuring that content hierarchy and internal linking are replicated (and improved) in the new architecture.

On the future of SEO:

• AI Overviews and zero-click search
  are the most significant structural shift we have seen since mobile-first indexing. For NGOs, this is a mixed picture - informational queries about APOPO's programmes may increasingly be answered in the SERP without a click, but high-intent donation queries remain highly click-driven. Our recommendation is to prioritise E-E-A-T signals (Experience, Expertise, Authoritativeness, Trust) and schema markup for programmes, impact data, and FAQs to maximise APOPO's presence in AI-generated overviews.
• Multilingual SEO
  is more important than ever as Google's language models improve. Hreflang must be implemented precisely - a single error can cause the wrong language variant to rank in the wrong country, directly costing donations from international donors.
• Programmatic SEO
  for high-volume, low-competition keywords (e.g., country-specific landmine information pages) is an underutilised opportunity for APOPO that we would explore in Stage 2.

WordPress is our primary development platform. We have delivered 180+ WordPress projects since 2013 and maintain 40+ live WordPress environments. This is not a generalised claim - our lead engineer Tiago Santos has contributed to the WooCommerce Subscriptions plugin community and has built recurring donation infrastructure for charity clients.

• Elementor + Astra:
  We are experienced with both and can advise on best practices for maintaining performance while using Elementor's visual builder. We have also moved clients away from Elementor to FSE (Full Site Editing) where performance demands require it - we will make an honest recommendation after the audit, rather than defaulting to the existing stack.
• WooCommerce Subscriptions:
  Direct experience with subscription continuity migrations - we have moved active subscription databases between environments without donor action required on three occasions. The critical path is maintaining Stripe Customer IDs and PayPal billing agreement references, which we have documented processes for.
• Odoo integration:
  We do not have prior Odoo-specific experience, but we have delivered multiple complex third-party integrations - including CRM sync, subscription webhooks, and e-commerce data pipelines - and are confident in our ability to work with the Odoo REST API. We will review APOPO's current integration during the backend audit and document any gaps or risks before development begins.

Ricardo Nunes, our DevOps and Security Engineer, manages infrastructure on Plesk and IONOS Cloud for multiple clients and will lead this work for APOPO.

• Performance baseline:
  PHP 8.2+ with OPcache enabled, memory limits appropriately sized for WooCommerce (minimum 256MB, recommended 512MB), and MySQL query cache tuned to APOPO's traffic patterns. We also review and configure Nginx/Apache rules for optimal static asset serving.
• Caching stack:
  WP Rocket for page caching and minification, Redis object caching for WooCommerce session management, and Cloudflare CDN for static asset delivery globally. This combination typically achieves sub-2 second load times on a well-configured IONOS Cloud instance.
• Security hardening:
  Wordfence Enterprise with WAF rules tuned for WooCommerce, SSL/TLS configuration review, file permission audit, and disabling XML-RPC and REST API endpoints that are not needed. We also configure automated offsite backups (daily, 30-day retention) to a separate storage location from the main server.
• GDPR compliance:
  Cookie consent via WebToffee as APOPO currently uses, DPIA review of third-party scripts, and a documented data retention policy for donor records in both WordPress and Odoo.

We will not recommend migrating away from APOPO's existing Plesk/IONOS environment unless the audit reveals a compelling reason to do so. Continuity of the hosting environment means continuity of the Stripe and PayPal integrations - which matters far more than a marginal performance gain from a different host.

Multi-phase builds are higher risk than single-phase projects for two reasons: scope creep compounds across phases, and dependencies between phases are often underestimated. Our mitigation approach:

• Hard feature freeze for Stage 1 MVP:
  Before development begins, we lock the Stage 1 feature list in writing with APOPO's sign-off. Any additions go to a Stage 2 backlog unless there is a formal change request with agreed cost and timeline impact. This is not inflexibility - it is the single most effective tool for on-time delivery.
• Buffer allocation:
  We build a 15% time buffer into every phase estimate, not as padding but as acknowledged contingency for integration complexity, content delays, and feedback cycles. This buffer is visible in our project plan rather than hidden in line item estimates.
• Dependency mapping:
  We document all inter-phase dependencies at the start. For APOPO, the critical dependency is: Stage 1 Stripe/PayPal integration must be stable and fully tested before Stage 2 donor dashboard work begins, because the dashboard reads from the same subscription data. We will not start Stage 2 until Stage 1 has passed UAT.
• Frequent feedback:
  We keep APOPO's team informed through regular updates shared via ClickUp and Google Docs - covering what has been completed, what is next, and any open risks or decisions needed. Communication is ongoing rather than batched into formal reports.

We use ClickUp for task and project management and Google Docs for shared documentation, briefs, and decision logs.

• Shared project board:
  APOPO's team will have full read (and optionally write) access to the project board from day one. Every task, bug, and milestone is visible in real time - no black box.
• Milestone reviews:
  At the end of each project phase, we hold a review call where we demo completed work on a staging environment. APOPO's team signs off before we move to the next phase.
• Project communication:
  We set up a shared ClickUp workspace and keep APOPO's team updated on progress at every milestone.
• Decision log:
  We maintain a running log of every significant decision made during the project - who decided, what the options were, and why we chose the path we did. This prevents revisiting settled decisions and is invaluable during handover.

The SLA commitments below apply to active maintenance clients only. We treat donation checkout failures as P0 incidents - the equivalent of a storefront with a broken door.

• P0 - Site down / donation checkout failure:
  Initial response within 1 hour (during business hours), 2 hours (outside business hours). Resolution target: 4 hours from acknowledgement.
• P1 - High impact but site functional:
  (e.g., payment method unavailable, PDF certificate not generating) - Response within 4 hours, fix within 2 business days.
• P2 - Medium impact:
  (e.g., display issue on a programme page) - Response within 1 business day, fix within 4 business days.
• P3 - Low impact / cosmetic:
  Goes to backlog and addressed in the next available maintenance window.

We use UptimeRobot for uptime monitoring on the main site and the donation pages, with alerts going simultaneously to our DevOps team and APOPO's IT team - no single point of failure in the alert chain.

The 90-day post-launch warranty covers all issues attributable to our development work at no additional charge, regardless of support tier.

We offer three post-launch support tiers. All tiers include the 90-day warranty period at no charge before the maintenance contract begins.

All maintenance contracts are month-to-month with 30 days notice. No lock-in. We believe our clients should stay because they value the service, not because they are contractually obligated.

A few additional thoughts we wanted to share, beyond the formal scope of the RFP:

• The HeroRAT adoption mechanic deserves its own standalone page experience.
  It is arguably the most differentiated fundraising product in the sector - a specific animal, a specific name, a regular update. We would love to explore a dedicated "Meet the Rats" section that functions almost like a product catalogue, with individual profiles for each available HeroRAT. This could significantly increase the average donation value and the emotional stickiness of the relationship.
• On the €2.5M target:
  We believe it is achievable by 2028, but not through the website alone. The website is the conversion layer - it needs to be fed by a strong email programme, social content, and paid acquisition working in concert. We would be happy to advise on the full digital ecosystem, not just the site, as a value-add to the relationship.
• Subscription continuity is the most important technical requirement in the RFP.
  APOPO's recurring donors are its most valuable asset. Any interruption to their subscriptions - even a missed charge - risks permanent donor loss. We want to be explicit: we will not execute a donation platform migration without a tested rollback plan and a live parallel run period where both the old and new environments process subscriptions simultaneously.
• We reviewed APOPO's current site carefully
  and noticed several immediate quick-win opportunities that could be implemented even before the full redesign: the donation CTA above the fold is too small on mobile, the "Adopt a HeroRAT" flow has an unnecessary account creation step that will be reducing conversion, and the programme pages have inconsistent CTA placement. We would flag these to APOPO's team immediately at kickoff as zero-cost, high-impact recommendations.
• We would welcome a call
  to discuss any aspect of this proposal before the deadline. We are genuinely invested in APOPO's mission and would be proud to be part of the work.