Creed Aberdeen

01 Overview

CREED stands for Christians Redeemed Equipped Empowered Destined, and the organisation describes itself as a training institute rather than a noticeboard. It runs three programme strands: entrepreneurship seminars, a skillset bootcamp in AI and data, and employability and reskilling. The build replaced the previous creedaberdeen.org.uk with a site that both publishes the programmes and administers entry to them, so an event can define its own application form, take submissions, rank them against a capacity, and email each applicant an outcome. Nineteen public pages sit in front of fifteen content collections, all in one deployable service.

02 The Challenge

The flagship programme is a machine learning bootcamp for teenagers with thirty places. That single fact set the engineering constraints. Application records hold a child's date of birth, medical notes and guardian contact details, so who can read a record matters as much as the record existing. Photographs are published with consent recorded per photograph, so a picture withheld from the gallery must not be reachable at all rather than merely hidden. Places are finite, so two people applying at the same moment must not both take the last one. And the organisation has to be able to run this without a developer present, which rules out anything that only works when someone remembers a step.

03 The Solution

1. 01Built the site and its CMS as one Next.js application with Payload self-hosted inside it, so there is a single service to deploy and one place where access rules are evaluated, rather than a public site plus a separate hosted CMS.
2. 02Chose Payload over a hosted CMS specifically for safeguarding: access control is ordinary code running per request, which is what makes it possible to keep applicant records away from the people who only edit content. Three roles separate content editing, safeguarding access to applications, and user administration, with an editor holding no access to application records at all.
3. 03Made under-18 applications a distinct code path rather than a variation. An event flagged as involving minors collects participant and guardian details, sends confirmations to the guardian rather than the child, and freezes that classification at submission so editing the event later cannot retroactively change how an existing record is treated.
4. 04Served every uploaded image through a route that applies the per-photograph consent rule at fetch time. A public read rule on the collection would also have exposed a listing of the whole media library, which on a site publishing pictures of young people meant a withheld photograph was still downloadable by anyone who asked for the list.
5. 05Made capacity race-free by ranking applications after the record exists rather than checking for room before writing it. Submissions are ordered by timestamp and anything past the capacity is moved to a waitlist with a position, so the same set of applicants is admitted regardless of which request evaluates first, and declining someone releases their place automatically.
6. 06Let editors define each event's application form in the CMS, with field types, requirements and an optional artefact upload, and assembled the validation schema per event so a new programme needs no code change. Dynamic field keys are namespaced so a CMS field cannot collide with the applicant's own details.
7. 07Wrote five transactional email templates whose HTML and plain-text versions are generated from one source so they cannot drift, with every interpolated value escaped, and sending decoupled from storage so a mail failure never presents as a failed application. Admin notifications deliberately omit dates of birth, medical notes and answers.
8. 08Covered the rules that matter with 334 tests across 18 suites, 8 of which run against a real Postgres instance rather than a mock, concentrating on capacity, date handling, application validation, consent, and escaping in emails and CSV exports.

04 Key Features

• Per-event application forms defined in the CMS, no code change per programme
• Under-18 flow with guardian details, consents and safeguarding acknowledgement
• Automatic waitlisting once an event reaches capacity
• Photograph consent enforced when the image is requested, not just when displayed
• Role-separated admin, with applicant data closed to content editors
• Applicant, guardian, outcome and waitlist-promotion emails
• Cohort CSV export and accepted-email tools for organisers
• Cookie consent with analytics that load only after agreement