The governing rule

One rule shaped every decision in this build:

Nothing a non-technical Foundation staff member might reasonably want to change is hardcoded.

Not the programme pillars and their colours. Not the page copy. Not the navigation, the footer, the phone numbers, the bank details or the social links. Not the workflow status labels or the order they appear in. Not the questions on a form, or their validation rules. Not the regions, the volunteer skills, the professions, the time slots, or the answers in the help panel. Not even the interface strings, which live in a translations table.

The test applied to every screen: if the programme manager wants to change this next year with no developer involved, can they?

What the Foundation actually does

It walks with families in Addis Ababa through medical crisis, old age, mental strain and the long work of getting a child through school. That means intake, assessment, casework and disbursement, and a public face that has to ask strangers for money and for time.

The system

A dynamic form engine. Applications for assistance are not hand-written pages. A form is a row in form_definitions with its questions in form_fields, and one renderer draws it, validates it and files the submission. Adding a new intake form is configuration.

Beneficiary casework. Households, beneficiaries, assessed needs by category, case notes, documents and disbursements, with payment methods and accounts behind them.

Donations. Campaigns, donors, one-off gifts, recurring pledges, in-kind donations with itemised contents and photographs, and a reconciliation log against the external giving platforms.

Volunteering, with a safeguarding gate. This one is deliberately not form-builder driven. Volunteering ends in someone being placed with vulnerable people, so the questions the gate depends on are code rather than editable rows: a coordinator deleting the references section would be disabling a control, not editing copy. A volunteer cannot reach an approved stage while the safeguarding checklist is incomplete, and that check lives in the single transition function every path goes through, precisely so a direct POST cannot skip it.

Pillar-scoped access. A caseworker assigned to one programme pillar must not reach another pillar's case notes or documents: not through the interface, not by changing a URL, not by posting directly. The scope is folded into the query rather than hidden in the UI.

The rest. Blog, media library, testimonials, contact routing by subject and office, newsletter, an audit log over everything, and a cached impact-metrics layer for the public figures.

Why it matters

Most nonprofit websites are built once and then slowly become wrong, because every change costs a developer the organisation cannot afford. This one was built so the Foundation owns its own content, its own forms and its own workflow, and the developer is only needed when the shape of the work changes, not its wording.