A custom website for a support dog charity, delivered through a change of client

The charity's website came from an off-the-shelf builder, and it could not do what the organisation needed.

They wanted a proper custom site that reflected their brand and did real work for them: explaining eligibility, taking applications, attracting donations and recruiting volunteers.

• Their own identity. Custom colours and their logo, rather than a generic template.
• Eligibility and applications. Clear eligibility information and a way to apply or enquire online.
• Trust. Testimonials and reviews from people they had supported.
• Donations. A dedicated, secure payment gateway.
• Volunteers. A way for people to sign up to help.

As a university project, the role was broader than a typical BA position. I ran the business analysis and project management, and built the data side of the site.

I ran discovery with the client's stakeholders, then went back for the detail until the requirements were concrete enough to build.

1. 1.Booked time with the stakeholders we were put in contact with, and met them over Zoom.
2. 2.Ran a discovery conversation about their current problems and what they wanted to achieve.
3. 3.Held follow-up meetings to draw out the detailed working requirements for the site.
4. 4.Finalised the requirements and validated them back with the stakeholders.
5. 5.Prioritised them with MoSCoW to confirm what the team could deliver in the time available.

I wrote each requirement as a user story with clear acceptance criteria, so the team knew exactly what to build and how it would be tested.

Example user story (illustrative)

As a person interested in a support dog, I want to check the eligibility criteria before I apply, so that I know whether to submit an application.

• Given I am on the eligibility page, when I read the criteria, then each criterion is listed in plain language.
• Given I meet the criteria, when I select apply, then I am taken to the application form.
• Given I submit a completed application, when it is received, then it is stored in the database and I see a confirmation.

This example is written in the style I used for the portfolio; it is not copied from the project records.

• Kanban boards. I set up Jira Kanban boards and moved every user story onto them.
• End-to-end tracking. The boards tracked each story through build, deployment, implementation and post-go-live maintenance.
• Team collaboration. The team used Trello to coordinate day to day and to step in when someone needed help.

I designed the database behind the site, connected it to the website the team built, and set up analytics the charity could act on.

• Database. I designed an Amazon DynamoDB database to store enquiries, applications and the user data the website needed.
• Integration. I built the connection between the website and the database, and we confirmed it worked in UAT.
• Analytics. I built live dashboards in Google Analytics covering website traffic, enquiries, accepted applicants, donations, donation page visits and volunteer sign-ups.
• Purpose. The dashboards were designed to show the charity what was working, to guide promotion and fundraising.

Three months in, after the design and prototype phase, the client stopped responding.

After the two-week summer break, our course coordinator stepped in as the client. He already knew the project's history, so we kept our momentum. He joined a weekly meeting to review the working site and our progress through build, implementation and handover.

• Whole-team UAT. Every team member took part, testing each flow end to end, including submitting enquiries as a real user would.
• Integration checks. We confirmed the website to database connection worked during UAT.
• Handover. We handed over a finished, working build, live, to the course coordinator. Because the original client had stopped responding, the site did not go live for the charity itself.

• A finished custom website with the charity's branding, eligibility information, applications, testimonials and volunteer sign-up.
• A secure donations payment gateway, built and working in the final version.
• A DynamoDB database storing enquiries and applications, connected to the site and tested.
• Live analytics dashboards covering traffic, enquiries, applicants, donations and volunteers.
• A finished build delivered despite losing the original client halfway through.

• Document requirements properly. Clear requirements, user stories and strong acceptance criteria keep the delivery cycle on track; anything left loose adds build time later and eats into budget and resources.
• Keep clients invested. Some things are outside anyone's control, but regular, well-paced updates at every step help a new client stay engaged without overwhelming them.
• Read the context. This project was free to the client, which made it easier for them to step away. When real money is involved, a quiet client more often means a pause than an end, so plan for the project to resume.