Background
Castlemilk Pantry is a community food pantry supporting local members through subsidised shopping. Before this system existed, every part of running it, registering members, checking weekly shop eligibility, tracking user shops, and reporting to funders — was done by hand.
I was a user before I was the developer
I used the pantry myself and saw the daily burden firsthand: staff manually registering users and checking, sheet by sheet, whether each person was eligible to shop that day. At the end of every day, week, month, and quarter, someone had to turn that paperwork into reports for funders, hours of work that should have gone toward the community instead.
I offered to help as a newly qualified full-stack developer. We met so I could introduce myself properly and bring an early dashboard mockup to that first conversation. Once we agreed to move forward, we signed a Data Protection Impact Assessment before any development began.
I introduced the agile approach I'd learned on my CodeYourFuture final project (Bikes for Refugees), giving Fiona and Kelly the Product Owner role defining requirements and prioritising the backlog around business value, while I ran delivery.
Designing together, not for them: for every new feature, we opened Excalidraw live in our meetings. Fiona and Kelly would describe how they wanted something to work, and I'd sketch the wireframe with them in real time — turning a conversation into a shared visual reference before a single line of code was written.
Scrum master and sole developer
Fiona and Kelly owned the "what" and "why." I owned the "how" end to end.
I owned
- Scrum facilitation — weekly meetings, sprint planning, backlog grooming
- All coding, testing, and deployment
- Requirements gathering from stakeholder conversations into user stories
- Architecture and infrastructure decisions (AWS, RDS, auth, API security)
- Meeting minutes and the ongoing user manual
- Walking Fiona & Kelly through every GitHub update personally
Fiona & Kelly (Product Owners)
- Defined requirements and business priorities
- Prioritised the backlog to protect business value
- Domain expertise on pantry operations and member needs
- Reviewed and tested each release before rollout
Keeping non-technical stakeholders inside the process
We ran the whole build on a visible, shared Trello board — not just meeting updates. Fiona and Kelly could check backlog status, in-progress work, and shipped features at any time, without waiting for me.
What the system does
Membership database
Searchable member records with editable profiles and status tracking. Staff can message one member or broadcast SMS to targeted groups, using specific or generic templates.
Automated onboarding
New registration triggers a templated welcome email with membership rules, benefits, and a pantry orientation video, plus an SMS with a direct link to the member's profile.
Multi-type shop scanner
Scans a member's QR code to instantly verify status — active, in a grace period, or annual payment due. Evolved to also handle non-members, signposted users, and charity-sponsored shopping payments in the same flow.
Reporting
Daily reporting, Weekly shop, Membership payment, annual payment, quarterly, and annual reports for funders: new members, members per quarter, members by housing association, member vs. non-member split, generated instantly instead of hand-compiled.
Dashboard
Get clear, accessible insight into their daily, weekly, and monthly visitor trends, along with new member sign-ups, total membership counts, and grouped dietary needs.
Member self-service profile
Members access their unique profile to see their own membership status and personal QR code to make a weekly shop, and can message pantry admins directly with questions about other services.
How it's built
Used MUI (Material UI) to rapidly build and deploy consistent, accessible components across the app. During my training at CodeYourFuture (Full Stack Web Developer Course) I was exposed to a wide range of technologies, and MUI was one of them it's now part of my go to stack and a key part of my success as a developer.
Chose PostgreSQL because it's what I learned at CodeYourFuture, and I've since built hands-on experience with it through real projects. It gave me a reliable, well structured relational database to manage the app's data with confidence.
Chose Redux to manage complex, cross-cutting state across the scanner, membership, and reporting modules — these all needed to stay perfectly in sync as staff moved through their shift, so keeping state predictable was key. Learning to implement Redux from the ground up was a valuable experience, and it's since become a tool I'm confident using and glad to have in my skill set.
Implemented Firebase Authentication with secure token-based sessions; every single API endpoint is protected with server-side token verification rather than relying on client-side checks alone. Additionally, sign-up and sign-in flows are fully managed through Firebase, ensuring consistent and reliable user authentication across the entire application.
Started on AWS free-tier (EC2 + RDS) to validate the MVP at zero cost. After the free year ended, Fiona chose to pay for hosting directly — and we're having conversations of migrating to a VPS with Dokploy to cut ongoing cost while keeping the setup portable and reliable, mirroring the approach used on the Auldhouse project.
What changed
Launched publicly in May 2025 after running quietly in parallel with the old Excel process, so staff could trust the new system before fully switching over.
What I'd do differently
Hosting cost wasn't planned for past the AWS free year — we're now migrating to a VPS with Dokploy for a cheaper, more portable, more reliable setup. Next time, I'd model realistic post-trial hosting costs with the client before launch, not after.