# Laurence Peberdy > I lead product at Bankuet, working across research, product direction and software development. I built our donor application, led the redesign of our food bank portal, and independently made Research Atlas, a visual tool for navigating academic research. This static resource is generated from the same validated content as the selected-work pages. Each project's case_study contains its complete source record: narrative, decisions, outcomes, evaluation scope, limitations, image descriptions, links and supporting exhibits. The shorter project fields are compatibility summaries, not the complete account. Claims are author-reported. Their context preserves the surrounding evaluation and limitations. Content hashes identify equivalent source records across representations; they do not independently verify a claim. ```json { "schema_version": "1.10", "type": "personal_portfolio_context", "portfolio": { "type": "personal_portfolio", "person": { "id": "laurence-peberdy", "name": "Laurence Peberdy", "email": "laurence.peberdy@googlemail.com", "role": "Product Lead", "location": "London", "worksFor": { "name": "Bankuet", "url": "https://bankuet.co.uk", "description": "a tech-for-good startup helping food banks access supplies" }, "alumniOf": [ "London Interdisciplinary School", "Loughborough University" ], "sameAs": [ "https://github.com/LPeberdy", "https://www.linkedin.com/in/lpeberdy/" ], "knowsAbout": [ "Product strategy", "Product discovery and delivery", "AI-assisted software development", "Interdisciplinary problem-solving", "Data visualisation", "Knowledge representation" ], "positioning": { "introduction": "I lead product at Bankuet, working across research, product direction and software development. I built our donor application, led the redesign of our food bank portal, and independently made Research Atlas, a visual tool for navigating academic research." }, "summary": "Product Lead at Bankuet, where I set product direction across donor, food bank and fundraising products. I combine product strategy and delivery leadership with hands-on implementation, including personally shipping production software.", "tenure": { "id": "laurence-peberdy-bankuet-tenure", "startDate": "2020-03-01", "claim": "He joined Bankuet as a Business Analyst in March 2020, became Product & Operations Manager in October 2020, and has led product since April 2022." }, "mandate": "He owns strategy and delivery across public donations, food bank requests, and fundraising campaigns.", "workingStyle": "His work combines product direction, delivery leadership and personal implementation, including Bankuet's current donor application.", "background": "Before product management, Laurence worked in information and project management, including a higher-education digitisation project covering more than 190,000 records. In 2025 he completed a part-time MASc in Interdisciplinary Problems & Methods at the London Interdisciplinary School with distinction, alongside his full-time work at Bankuet. His earlier degree is a BSc in Information Management & Business from Loughborough University.", "url": "https://laurence-peberdy.com" }, "site": { "name": "Laurence Peberdy", "url": "https://laurence-peberdy.com", "title": "Laurence Peberdy — Product Lead at Bankuet", "description": "Product case studies spanning donor experiences, food bank operations, fundraising and hands-on software delivery." }, "projects": [ { "id": "bankuet-reliability", "slug": "reliability", "title": "Bankuet: Continuous integration and deployment (CI/CD)", "card": { "title": "Continuous integration and deployment (CI/CD)", "deliverable": "Designed and built Bankuet's CI/CD pipeline, from source checks to production release.", "outcomes": "Source and build secret scans · normal releases held until required checks pass" }, "seo": { "title": "Continuous integration and deployment (CI/CD)", "description": "How I built Bankuet's CI/CD pipeline to catch broken behaviour and exposed secrets before a change reaches production." }, "canonical_url": "https://laurence-peberdy.com/w/reliability", "markdown_url": "https://laurence-peberdy.com/w/reliability.md", "project_context": { "type": "organization", "name": "Bankuet", "url": "https://bankuet.co.uk" }, "project_date": { "precision": "day", "value": "2026-09-04" }, "published": "2026-09-05", "updated": "2026-09-07", "role": [ "Product Lead", "Engineer" ], "responsibility_summary": "I designed and implemented Bankuet.co.uk's CI/CD pipeline end to end.", "description": "When we change Bankuet's donor app, Vercel turns the repository code into a version that could go live. I built checks around that path so broken behaviour or secrets are more likely to be caught before release.", "summary": [ "When we change Bankuet's donor application, we change the code in GitHub. Vercel then turns that code into the version that could go live — a build.", "A build can finish successfully and still be wrong. A donation page can pass the wrong fund, generated files can accidentally contain credentials or other secret values, or the deployed app can behave differently from local tests. I used a **Swiss cheese approach**: several imperfect checks overlap, so one can catch what another misses." ], "problem": "Every change follows the same path: we commit code to GitHub, Vercel builds a version of the app, and that version can then be promoted to the live site. Each step can succeed while the result is still broken or unsafe. **The app can build and still behave incorrectly.** Discovery can fail, or a food bank page can load but pass the wrong fund identifier to its donation form. **The files that go live are not only the files we wrote.** The build generates pages and scripts, so reviewing source code alone cannot show everything that may be published. **What works locally can fail after deployment.** Vercel runs the candidate in a different environment, so the exact version that could go live also needs testing.", "constraints": [ "The checks cannot prove safety by repeating real production activity. They have to catch problems without leaking secrets, making real donations or bookings, or taking the current site offline:", "**Our post-build secret scan cannot inspect Vercel's build.** It can inspect the controlled local/CI build; Vercel makes a separate build with its real environment.", "**Tests cannot expose the secrets they are meant to protect.** The workflow cannot put credentials, bypass secrets or donor data in URLs, permanent headers, traces or uploaded artifacts.", "**Integration checks cannot submit real donations or bookings.** They have to test the handoffs without performing the real action or making releases depend on a third party being available.", "**Testing the next version cannot take the current site offline.** The existing deployment stays public until the candidate passes both main CI and the deployment check." ], "hypotheses": [ "If we check the same change at several points — the source code, the files the build generates, browser behaviour, and the exact Vercel version that could go live — one check can catch what another misses and reduce the chance that broken software or a secret reaches production." ], "interventions": [ "The pipeline follows the path of a release. It checks the source before the build, checks what the build generates, and then tests the exact Vercel deployment before that version can replace the live site.", "Run the same checks locally and in GitHub", "One command runs both on a developer machine and in GitHub Actions. It checks environment-variable documentation, scans source for secrets, applies the dependency policy, checks TypeScript and lint warnings, and runs unit, integration, and browser tests. If any check fails, the sequence stops.", "The repository therefore defines the acceptance process; nobody has to reconstruct a checklist before publishing. Known exceptions have an owner and an expiry date.", "Inspect what the build generates", "Secretlint scans the source before the build. After the controlled local/CI build, the pipeline also scans the text that build creates: server output, client assets, and selected deployment manifests. This can catch credentials or other secret-like text that was not obvious in the authored source.", "A finding stops the check and reports the file and rule while masking the suspected secret. An inert test fixture verifies both detection and masking. Vercel builds separately with its real environment; this scan does not inspect Vercel's output.", "Check dependencies and app behaviour", "The dependency check combines npm's audit with first-party Next.js advisories. High or critical findings block the change unless an accepted exception covers them. If an advisory source is unavailable or unreadable, the check fails rather than silently passing.", "Vitest runs unit and integration tests. Playwright then opens a fresh production build using synthetic data and local service fixtures. It checks discovery, public routes, and the fund identifier passed to donation forms. Live donation forms and analytics stay disabled.", "Test the exact version that could go live", "Vercel builds a production candidate while the previous deployment stays public. A trusted workflow confirms that the candidate belongs to the right project and commit, then tests that exact deployment. Normal promotion requires both main CI and the candidate check to pass.", "Those checks cover key pages and redirects, public discovery APIs, required security headers, the Beacon donation-form and Mapbox handoffs, and Calendly discovery. Selected third-party responses are controlled so we can test Bankuet's side of each integration without submitting donations or bookings, or making releases depend on provider availability.", "Keep test access safe and retain human control", "Test access is limited to the validated production candidate. The browser gains access without putting the bypass secret in a URL or permanent request header. Protected traces are disabled; the workflow uploads no credentials or donor data as review evidence.", "The release policy also includes a documented human override and rollback procedure. Automated checks support, rather than replace, operational responsibility." ], "technologies": [ "GitHub Actions", "Vercel", "Secretlint", "Vitest", "Playwright" ], "competencies_demonstrated": [ "Security and reliability as product delivery requirements", "Layered verification across source, build and deployment", "Safe testing of live-service integration boundaries" ], "outcomes": [ "bankuet-reliability-shared-checks", "bankuet-reliability-held-release" ], "case_study": { "id": "bankuet-reliability", "title": "Bankuet: Continuous integration and deployment (CI/CD)", "card": { "title": "Continuous integration and deployment (CI/CD)", "deliverable": "Designed and built Bankuet's CI/CD pipeline, from source checks to production release.", "outcomes": "Source and build secret scans · normal releases held until required checks pass" }, "seo": { "title": "Continuous integration and deployment (CI/CD)", "description": "How I built Bankuet's CI/CD pipeline to catch broken behaviour and exposed secrets before a change reaches production." }, "projectContext": { "type": "organization", "name": "Bankuet", "url": "https://bankuet.co.uk" }, "projectDate": { "precision": "day", "value": "2026-09-04" }, "published": "2026-09-05", "updated": "2026-09-07", "blurb": "When we change Bankuet's donor app, Vercel turns the repository code into a version that could go live. I built checks around that path so broken behaviour or secrets are more likely to be caught before release.", "role": [ "Product Lead", "Engineer" ], "responsibilitySummary": "I designed and implemented Bankuet.co.uk's CI/CD pipeline end to end.", "decision": "Use overlapping checks rather than trust a successful build alone.", "summary": [ "When we change Bankuet's donor application, we change the code in GitHub. Vercel then turns that code into the version that could go live — a build.", "A build can finish successfully and still be wrong. A donation page can pass the wrong fund, generated files can accidentally contain credentials or other secret values, or the deployed app can behave differently from local tests. I used a **Swiss cheese approach**: several imperfect checks overlap, so one can catch what another misses." ], "problem": { "intro": [ "Every change follows the same path: we commit code to GitHub, Vercel builds a version of the app, and that version can then be promoted to the live site. Each step can succeed while the result is still broken or unsafe." ], "items": [ "**The app can build and still behave incorrectly.** Discovery can fail, or a food bank page can load but pass the wrong fund identifier to its donation form.", "**The files that go live are not only the files we wrote.** The build generates pages and scripts, so reviewing source code alone cannot show everything that may be published.", "**What works locally can fail after deployment.** Vercel runs the candidate in a different environment, so the exact version that could go live also needs testing." ] }, "constraints": { "intro": [ "The checks cannot prove safety by repeating real production activity. They have to catch problems without leaking secrets, making real donations or bookings, or taking the current site offline:" ], "items": [ "**Our post-build secret scan cannot inspect Vercel's build.** It can inspect the controlled local/CI build; Vercel makes a separate build with its real environment.", "**Tests cannot expose the secrets they are meant to protect.** The workflow cannot put credentials, bypass secrets or donor data in URLs, permanent headers, traces or uploaded artifacts.", "**Integration checks cannot submit real donations or bookings.** They have to test the handoffs without performing the real action or making releases depend on a third party being available.", "**Testing the next version cannot take the current site offline.** The existing deployment stays public until the candidate passes both main CI and the deployment check." ] }, "hypotheses": { "intro": [ "If we check the same change at several points — the source code, the files the build generates, browser behaviour, and the exact Vercel version that could go live — one check can catch what another misses and reduce the chance that broken software or a secret reaches production." ], "items": [] }, "interventions": { "intro": [ "The pipeline follows the path of a release. It checks the source before the build, checks what the build generates, and then tests the exact Vercel deployment before that version can replace the live site." ], "items": [], "groups": [ { "heading": "Run the same checks locally and in GitHub", "intro": [ "One command runs both on a developer machine and in GitHub Actions. It checks environment-variable documentation, scans source for secrets, applies the dependency policy, checks TypeScript and lint warnings, and runs unit, integration, and browser tests. If any check fails, the sequence stops.", "The repository therefore defines the acceptance process; nobody has to reconstruct a checklist before publishing. Known exceptions have an owner and an expiry date." ], "items": [] }, { "heading": "Inspect what the build generates", "intro": [ "Secretlint scans the source before the build. After the controlled local/CI build, the pipeline also scans the text that build creates: server output, client assets, and selected deployment manifests. This can catch credentials or other secret-like text that was not obvious in the authored source.", "A finding stops the check and reports the file and rule while masking the suspected secret. An inert test fixture verifies both detection and masking. Vercel builds separately with its real environment; this scan does not inspect Vercel's output." ], "items": [] }, { "heading": "Check dependencies and app behaviour", "intro": [ "The dependency check combines npm's audit with first-party Next.js advisories. High or critical findings block the change unless an accepted exception covers them. If an advisory source is unavailable or unreadable, the check fails rather than silently passing.", "Vitest runs unit and integration tests. Playwright then opens a fresh production build using synthetic data and local service fixtures. It checks discovery, public routes, and the fund identifier passed to donation forms. Live donation forms and analytics stay disabled." ], "items": [] }, { "heading": "Test the exact version that could go live", "intro": [ "Vercel builds a production candidate while the previous deployment stays public. A trusted workflow confirms that the candidate belongs to the right project and commit, then tests that exact deployment. Normal promotion requires both main CI and the candidate check to pass.", "Those checks cover key pages and redirects, public discovery APIs, required security headers, the Beacon donation-form and Mapbox handoffs, and Calendly discovery. Selected third-party responses are controlled so we can test Bankuet's side of each integration without submitting donations or bookings, or making releases depend on provider availability." ], "items": [] }, { "heading": "Keep test access safe and retain human control", "intro": [ "Test access is limited to the validated production candidate. The browser gains access without putting the bypass secret in a URL or permanent request header. Protected traces are disabled; the workflow uploads no credentials or donor data as review evidence.", "The release policy also includes a documented human override and rollback procedure. Automated checks support, rather than replace, operational responsibility." ], "items": [] } ] }, "pipeline": { "intro": [ "A typical change moves through five stages. CI and production smoke do different jobs: CI checks the repository and a controlled build; production smoke checks the exact Vercel deployment that could become live." ], "items": [], "groups": [ { "heading": "Open a pull request", "intro": [ "A proposed change is opened in GitHub. Nothing has changed in production yet; this creates the reviewable version of the work that the rest of the pipeline follows." ], "items": [ "Reviewable code change", "No production change" ] }, { "heading": "CI + preview", "intro": [ "**GitHub Actions** runs the main acceptance checks against the repository and a controlled build. **Vercel** also builds a preview so the change can be inspected before merge." ], "items": [ "Lint + TypeScript", "Unit, integration + browser tests", "Source secret scan", "Generated-file secret scan", "Dependency security checks", "Vercel preview" ] }, { "heading": "Merge into main", "intro": [ "Once the change is approved, it is merged into the main branch. That starts the release path, but the new version is still not public." ], "items": [ "Approved change", "Release workflow starts", "Current production stays live" ] }, { "heading": "Main CI + production smoke", "intro": [ "**CI runs again** on the merged change. Vercel builds the production candidate, and **production smoke** checks that exact deployed version — not the controlled CI build — before it can replace the current site." ], "items": [ "CI — code + types", "CI — test suite", "CI — secret scans", "CI — dependency checks", "Smoke — key pages + redirects", "Smoke — APIs + security headers", "Smoke — Beacon, Mapbox + Calendly handoffs" ] }, { "heading": "Promote to production", "intro": [ "Normal promotion happens only when main CI and the production smoke check have both passed. Vercel then makes the tested candidate live; the previous deployment remains public until that point.", "This is why the checks overlap rather than duplicate one another: CI looks for problems in code and a controlled build; production smoke asks whether the exact version about to go live behaves as expected." ], "items": [ "Both checks passed", "Tested candidate becomes live", "Human override + rollback remain available" ] } ] }, "technologies": [ "GitHub Actions", "Vercel", "Secretlint", "Vitest", "Playwright" ], "competenciesDemonstrated": [ "Security and reliability as product delivery requirements", "Layered verification across source, build and deployment", "Safe testing of live-service integration boundaries" ], "outcomes": { "intro": [ "The pipeline makes acceptance checks repeatable and holds normal releases until the required checks pass." ], "items": [ { "id": "bankuet-reliability-shared-checks", "kind": "qualitative_outcome", "claim": "Local development and GitHub share **one acceptance command**, including source and build-output secret scans.", "measurement": { "source_type": "implementation_record", "status": "author_reported", "scope": "Shared CI command and sealed local/CI production-build runner" } }, { "id": "bankuet-reliability-held-release", "kind": "qualitative_outcome", "claim": "A controlled production proof on **4 September 2026** recorded the previous deployment staying public while checks were pending. The candidate went live only after the required checks passed.", "measurement": { "source_type": "implementation_record", "status": "author_reported", "observed_at": "2026-09-04", "scope": "Recorded production-candidate proof in Bankuet issue 71; not a new experiment performed for this write-up" } } ], "outro": [ "The layers reduce reliance on any single check. They do not prove the application is free of vulnerabilities or that a live payment will complete." ] }, "evidenceScope": "Implementation and documented release-proof evidence from Bankuet's repository at b7fc75fc300f9d8319cf7f5bbe4bd2e41d035192. The controlled production proof was recorded on 4 September 2026 in issue 71. Source and output secret scans cover the local/CI build; Vercel builds separately. No measured reduction in incidents, vulnerabilities or downtime is claimed." }, "content_hash": "sha256:a2d6fd54455123812c633399843d117e3c4770377646863764f016fcc7eb6c6c", "evaluation_scope": "Implementation and documented release-proof evidence from Bankuet's repository at b7fc75fc300f9d8319cf7f5bbe4bd2e41d035192. The controlled production proof was recorded on 4 September 2026 in issue 71. Source and output secret scans cover the local/CI build; Vercel builds separately. No measured reduction in incidents, vulnerabilities or downtime is claimed.", "limitations": [], "outcome_context": { "intro": [ "The pipeline makes acceptance checks repeatable and holds normal releases until the required checks pass." ], "outro": [ "The layers reduce reliance on any single check. They do not prove the application is free of vulnerabilities or that a live payment will complete." ] } }, { "id": "bankuet-donor", "slug": "donor", "title": "Bankuet: Rebuilding the donor experience", "card": { "title": "Donor experience rebuild", "deliverable": "Led and built a visual and technical overhaul of Bankuet's donor experience.", "outcomes": "Technical food bank setup ~45 → 10 min · donation 5 → 3 steps" }, "seo": { "title": "Donor experience rebuild", "description": "How I led and built Bankuet's visual and technical rebuild, reducing donation from five steps to three and technical food bank setup from 45 minutes to 10." }, "canonical_url": "https://laurence-peberdy.com/w/donor", "markdown_url": "https://laurence-peberdy.com/w/donor.md", "project_context": { "type": "organization", "name": "Bankuet", "url": "https://bankuet.co.uk" }, "project_date": { "precision": "month", "value": "2025-10" }, "published": "2026-08-05", "updated": "2026-09-06", "role": [ "Product Lead", "Engineering Lead" ], "responsibility_summary": "I led product direction and architecture, recommended the move from Squarespace and built the production application. I worked with our fractional UX Lead and secured CEO buy-in.", "description": "I led and built a three-month visual and technical rebuild of Bankuet's donor application, reducing donation from five steps to three and technical food bank setup from about 45 to 10 minutes.", "summary": [ "Bankuet's donor experience lived in Squarespace. Changing donation options meant working around its page and form model; adding a food bank or fundraising campaign meant repeating setup; and the site connected awkwardly to the services behind it.", "I moved the donor experience into an application we controlled, while keeping specialist services such as Beacon for payments and CRM. That made the experience easier to change, reduced setup work, and gave a small team a codebase it could keep extending." ], "problem": "**Changing the donation journey was hard.** Donation options and steps were constrained by the Squarespace setup, so adapting the flow as Bankuet's needs changed was cumbersome. **Adding food banks and campaigns repeated the same setup work.** Technical food bank setup and fundraising campaign setup both required manual configuration. **The website and operational systems were loosely connected.** The donor site did not integrate cleanly with Beacon CRM and the other services Bankuet relied on.", "constraints": [ "Rebuilding the app did not mean replacing every service. Three constraints shaped the architecture:", "**The application needed to be extensible.** It had to connect cleanly to multiple data sources and services, adapt as Bankuet's needs changed, and support future initiatives without another rebuild.", "**The payment system had to stay proportionate to our scale.** We needed flexible giving and Direct Debit without taking on the implementation and operational risk of a bespoke payment stack unless that extra control justified it.", "**A small team needed to operate and adapt it.** The application had to stay straightforward to run and change without a large engineering team." ], "hypotheses": [ "If we owned the application layer but reused specialist services where they were strong, we could simplify giving, remove repeated setup work, and connect the donor experience to operational data without creating a system the team could not maintain." ], "interventions": [ "I recommended moving the donor experience out of Squarespace and built a Next.js app on Vercel. Rather than rebuild every capability, I connected it to existing services where that reduced risk or made the product easier to operate.", "**Beacon rather than a bespoke payment layer.** Rather than own card and Direct Debit flows, I embedded Beacon CRM donation forms. I had considered handling payments directly with Stripe and Supabase, but Beacon gave us flexible giving, Direct Debit and closer CRM integration with less implementation and operational risk.", "**Supabase and Mapbox for food bank discovery.** A Supabase Edge Function pulls food bank data from Beacon; Mapbox uses it for location search and maps on the donor site.", "**Notion rather than a custom CMS.** Colleagues already managed blog content in Notion, so I used it as the content system and retrieved posts through Notion's API. This reduced build scope and kept editorial control with non-technical colleagues.", "**Look and feel.** With our UX Lead, I implemented the visual redesign and standardised common sections in Figma and code. This made the experience more consistent and pages faster to design and build.", "I also led structured pre-launch QA across pages and screen sizes." ], "technologies": [ "Next.js", "Vercel", "Beacon CRM", "Supabase", "Mapbox", "Notion" ], "competencies_demonstrated": [ "Full-stack product engineering", "Cross-functional design collaboration", "Third-party CRM and data integration" ], "outcomes": [ "bankuet-donor-onboarding-time", "bankuet-donor-campaign-setup-time", "bankuet-donor-checkout-steps" ], "case_study": { "id": "bankuet-donor", "title": "Bankuet: Rebuilding the donor experience", "card": { "title": "Donor experience rebuild", "deliverable": "Led and built a visual and technical overhaul of Bankuet's donor experience.", "outcomes": "Technical food bank setup ~45 → 10 min · donation 5 → 3 steps" }, "seo": { "title": "Donor experience rebuild", "description": "How I led and built Bankuet's visual and technical rebuild, reducing donation from five steps to three and technical food bank setup from 45 minutes to 10." }, "projectContext": { "type": "organization", "name": "Bankuet", "url": "https://bankuet.co.uk" }, "projectDate": { "precision": "month", "value": "2025-10" }, "published": "2026-08-05", "updated": "2026-09-06", "blurb": "I led and built a three-month visual and technical rebuild of Bankuet's donor application, reducing donation from five steps to three and technical food bank setup from about 45 to 10 minutes.", "role": [ "Product Lead", "Engineering Lead" ], "responsibilitySummary": "I led product direction and architecture, recommended the move from Squarespace and built the production application. I worked with our fractional UX Lead and secured CEO buy-in.", "decision": "Build an application we could adapt, but retain Beacon's forms rather than building a bespoke payment layer.", "summary": [ "Bankuet's donor experience lived in Squarespace. Changing donation options meant working around its page and form model; adding a food bank or fundraising campaign meant repeating setup; and the site connected awkwardly to the services behind it.", "I moved the donor experience into an application we controlled, while keeping specialist services such as Beacon for payments and CRM. That made the experience easier to change, reduced setup work, and gave a small team a codebase it could keep extending." ], "heroImage": { "src": "/images/donor-service-find-a-food-bank.png", "alt": "Bankuet's food bank discovery interface, with a map and a list of food banks to support.", "caption": "Food bank discovery in the redesigned donor application." }, "problem": { "intro": [], "items": [ "**Changing the donation journey was hard.** Donation options and steps were constrained by the Squarespace setup, so adapting the flow as Bankuet's needs changed was cumbersome.", "**Adding food banks and campaigns repeated the same setup work.** Technical food bank setup and fundraising campaign setup both required manual configuration.", "**The website and operational systems were loosely connected.** The donor site did not integrate cleanly with Beacon CRM and the other services Bankuet relied on." ] }, "constraints": { "intro": [ "Rebuilding the app did not mean replacing every service. Three constraints shaped the architecture:" ], "items": [ "**The application needed to be extensible.** It had to connect cleanly to multiple data sources and services, adapt as Bankuet's needs changed, and support future initiatives without another rebuild.", "**The payment system had to stay proportionate to our scale.** We needed flexible giving and Direct Debit without taking on the implementation and operational risk of a bespoke payment stack unless that extra control justified it.", "**A small team needed to operate and adapt it.** The application had to stay straightforward to run and change without a large engineering team." ] }, "hypotheses": { "intro": [ "If we owned the application layer but reused specialist services where they were strong, we could simplify giving, remove repeated setup work, and connect the donor experience to operational data without creating a system the team could not maintain." ], "items": [] }, "interventions": { "intro": [ "I recommended moving the donor experience out of Squarespace and built a Next.js app on Vercel. Rather than rebuild every capability, I connected it to existing services where that reduced risk or made the product easier to operate." ], "items": [ "**Beacon rather than a bespoke payment layer.** Rather than own card and Direct Debit flows, I embedded Beacon CRM donation forms. I had considered handling payments directly with Stripe and Supabase, but Beacon gave us flexible giving, Direct Debit and closer CRM integration with less implementation and operational risk.", "**Supabase and Mapbox for food bank discovery.** A Supabase Edge Function pulls food bank data from Beacon; Mapbox uses it for location search and maps on the donor site.", "**Notion rather than a custom CMS.** Colleagues already managed blog content in Notion, so I used it as the content system and retrieved posts through Notion's API. This reduced build scope and kept editorial control with non-technical colleagues.", "**Look and feel.** With our UX Lead, I implemented the visual redesign and standardised common sections in Figma and code. This made the experience more consistent and pages faster to design and build." ], "outro": [ "I also led structured pre-launch QA across pages and screen sizes." ] }, "technologies": [ "Next.js", "Vercel", "Beacon CRM", "Supabase", "Mapbox", "Notion" ], "competenciesDemonstrated": [ "Full-stack product engineering", "Cross-functional design collaboration", "Third-party CRM and data integration" ], "outcomes": { "intro": [ "The redesigned site launched in October 2025. The clearest measured gains were in technical food bank setup and the donation flow:" ], "items": [ { "id": "bankuet-donor-onboarding-time", "kind": "measured_outcome", "claim": "Technical food bank setup time fell from approximately **45 minutes to 10 minutes**.", "metric": "food_bank_onboarding_time", "before": { "value": 45, "unit": "minute" }, "after": { "value": 10, "unit": "minute" }, "change": { "relative": -0.78 }, "measurement": { "source_type": "internal_operational_data", "status": "author_reported", "scope": "Technical food bank setup, not the complete onboarding lead time" } }, { "id": "bankuet-donor-campaign-setup-time", "kind": "qualitative_outcome", "claim": "Fundraising campaign setup went from around **one day to effectively instant**.", "measurement": { "source_type": "internal_operational_data", "status": "author_reported", "scope": "Reported setup-time comparison; not a measured staff-hours saving" } }, { "id": "bankuet-donor-checkout-steps", "kind": "measured_outcome", "claim": "The donation flow was reduced from **five steps to three**.", "metric": "checkout_steps", "before": { "value": 5, "unit": "step" }, "after": { "value": 3, "unit": "step" }, "change": { "relative": -0.4 }, "measurement": { "source_type": "internal_operational_data", "status": "author_reported" } } ] }, "evidenceScope": "Before-and-after operational observations and a donation-step count. Technical food bank setup is a different measure from end-to-end food bank onboarding lead time. Campaign setup timings are not a measured staff-hours saving. The look-and-feel upgrade is described qualitatively, not as a measured conversion improvement.", "limitations": [ "Conversion measurement remains limited: the embedded Beacon donation form and application analytics sit across different systems. This case does not establish a conversion uplift attributable to the rebuild." ] }, "content_hash": "sha256:d6cd97495de7de255f9a52c75e83cd17e71208669657633a27f31b628f0031d3", "evaluation_scope": "Before-and-after operational observations and a donation-step count. Technical food bank setup is a different measure from end-to-end food bank onboarding lead time. Campaign setup timings are not a measured staff-hours saving. The look-and-feel upgrade is described qualitatively, not as a measured conversion improvement.", "limitations": [ "Conversion measurement remains limited: the embedded Beacon donation form and application analytics sit across different systems. This case does not establish a conversion uplift attributable to the rebuild." ], "outcome_context": { "intro": [ "The redesigned site launched in October 2025. The clearest measured gains were in technical food bank setup and the donation flow:" ], "outro": [] } }, { "id": "research-atlas", "slug": "atlas", "title": "Research Atlas: Designing a visual search tool for interdisciplinary research", "card": { "title": "Research Atlas", "deliverable": "Independently researched, designed and built a visual research-navigation tool.", "outcomes": "Users valued finding papers they would not have thought to search for.", "outcomeLabel": "Evaluation" }, "seo": { "title": "Research Atlas", "description": "How I designed and built a graph-based research tool for exploring unfamiliar academic domains and finding unexpected connections." }, "canonical_url": "https://laurence-peberdy.com/w/atlas", "markdown_url": "https://laurence-peberdy.com/w/atlas.md", "project_context": { "type": "academic_project", "name": "Master's capstone", "institution": { "name": "London Interdisciplinary School", "url": "https://www.lis.ac.uk" } }, "project_date": { "precision": "year", "value": "2025" }, "published": "2026-08-05", "updated": "2026-09-06", "role": [ "Designer", "Engineer" ], "responsibility_summary": "I independently researched, designed and built Research Atlas as my Master's capstone at the London Interdisciplinary School.", "description": "Entering a field is difficult before you know its terminology. I independently built and evaluated a visual tool for finding the topics, papers and relationships that help establish that context.", "summary": [ "A researcher entering an unfamiliar field often starts with only a rough question. Conventional search immediately asks for keywords, but the useful keywords, authors and concepts are often exactly what the researcher is trying to discover.", "I built Research Atlas to start from that rough question, retrieve relevant papers, and show the topics and relationships between them. The point is to help a researcher learn what to search for next, not just rank a list of papers." ], "problem": "**Search assumes you already know the language of the field.** Effective queries depend on terms users may still be trying to discover. **A ranked list hides the shape of the literature.** Long result lists make it hard to see clusters, relationships or how papers connect. **Useful work can sit outside the discipline where the search starts.** Relevant papers may use different terminology or belong to another field. **The reason a result appears is hard to see.** Conventional ranking gives users little visibility into the relationships behind a result. **Understanding builds across sessions.** Researchers need to keep useful papers, topics and maps rather than restart each time.", "constraints": [ "The product also has three hard limits:", "**It was a solo capstone.** The scope had to fit research, product design, engineering and evaluation into one project.", "**Research Atlas depends on OpenAlex.** It can organise and relate the works and topics OpenAlex exposes, but cannot control the source's coverage.", "**The graph has to stay readable.** Adding works can reveal useful connections and add noise at the same time, so broad maps are capped at about 200 works and Analysis at about 100 per topic." ], "hypotheses": [ "If the tool turns a rough question into a visible map of papers and topics, reveals relationships progressively, and saves useful connections, users should find unfamiliar fields easier to navigate and discover work they would not have thought to search for." ], "interventions": [ "I tested the relevance of OpenAlex search results using 30 queries across different subject areas. Those checks helped me decide how much material the maps could show before useful connections were lost in noise: about 200 works for broad exploration and 100 per topic in the more focused Analysis flow.", "I built the application with Next.js. Neo4j stores the network of papers and topics; Supabase handles accounts and saved content; D3 draws the maps; and Vercel hosts the application." ], "technologies": [ "Next.js", "D3", "OpenAlex", "Neo4j", "Supabase", "Vercel" ], "competencies_demonstrated": [ "Independent research-to-product design", "Graph-based information visualisation", "Full-stack engineering across a graph, relational, and search data layer" ], "outcomes": [ "research-atlas-user-discovery", "research-atlas-visits", "research-atlas-real-experience-score" ], "case_study": { "id": "research-atlas", "title": "Research Atlas: Designing a visual search tool for interdisciplinary research", "card": { "title": "Research Atlas", "deliverable": "Independently researched, designed and built a visual research-navigation tool.", "outcomes": "Users valued finding papers they would not have thought to search for.", "outcomeLabel": "Evaluation" }, "seo": { "title": "Research Atlas", "description": "How I designed and built a graph-based research tool for exploring unfamiliar academic domains and finding unexpected connections." }, "projectContext": { "type": "academic_project", "name": "Master's capstone", "institution": { "name": "London Interdisciplinary School", "url": "https://www.lis.ac.uk" } }, "projectDate": { "precision": "year", "value": "2025" }, "published": "2026-08-05", "updated": "2026-09-06", "blurb": "Entering a field is difficult before you know its terminology. I independently built and evaluated a visual tool for finding the topics, papers and relationships that help establish that context.", "role": [ "Designer", "Engineer" ], "responsibilitySummary": "I independently researched, designed and built Research Atlas as my Master's capstone at the London Interdisciplinary School.", "decision": "Represent relationships between topics and papers, rather than produce another ranked list of search results.", "summary": [ "A researcher entering an unfamiliar field often starts with only a rough question. Conventional search immediately asks for keywords, but the useful keywords, authors and concepts are often exactly what the researcher is trying to discover.", "I built Research Atlas to start from that rough question, retrieve relevant papers, and show the topics and relationships between them. The point is to help a researcher learn what to search for next, not just rank a list of papers." ], "heroImage": { "src": "/images/research-atlas.png", "alt": "Research Atlas displaying an interactive map of academic topics and connected works.", "caption": "A map of academic topics and the works connecting them." }, "problem": { "intro": [], "items": [ "**Search assumes you already know the language of the field.** Effective queries depend on terms users may still be trying to discover.", "**A ranked list hides the shape of the literature.** Long result lists make it hard to see clusters, relationships or how papers connect.", "**Useful work can sit outside the discipline where the search starts.** Relevant papers may use different terminology or belong to another field.", "**The reason a result appears is hard to see.** Conventional ranking gives users little visibility into the relationships behind a result.", "**Understanding builds across sessions.** Researchers need to keep useful papers, topics and maps rather than restart each time." ] }, "constraints": { "intro": [ "The product also has three hard limits:" ], "items": [ "**It was a solo capstone.** The scope had to fit research, product design, engineering and evaluation into one project.", "**Research Atlas depends on OpenAlex.** It can organise and relate the works and topics OpenAlex exposes, but cannot control the source's coverage.", "**The graph has to stay readable.** Adding works can reveal useful connections and add noise at the same time, so broad maps are capped at about 200 works and Analysis at about 100 per topic." ] }, "hypotheses": { "intro": [ "If the tool turns a rough question into a visible map of papers and topics, reveals relationships progressively, and saves useful connections, users should find unfamiliar fields easier to navigate and discover work they would not have thought to search for." ], "items": [] }, "interventions": { "intro": [ "I tested the relevance of OpenAlex search results using 30 queries across different subject areas. Those checks helped me decide how much material the maps could show before useful connections were lost in noise: about 200 works for broad exploration and 100 per topic in the more focused Analysis flow.", "I built the application with Next.js. Neo4j stores the network of papers and topics; Supabase handles accounts and saved content; D3 draws the maps; and Vercel hosts the application." ], "items": [] }, "walkthrough": { "intro": [ "The product has three workflows:" ], "items": [], "groups": [ { "heading": "01 — Search from a question", "intro": [ "Start with a keyword or phrase. The Search flow retrieves relevant works and maps the topics and relationships within them, providing a view beyond a ranked list." ], "items": [] }, { "heading": "02 — Analyse a paper", "intro": [ "Start with a paper's title and abstract. The Analysis flow identifies its core topics and surfaces related research around each one." ], "items": [] }, { "heading": "03 — Keep useful connections", "intro": [ "The Archive saves works, topics and maps for later sessions." ], "items": [] } ] }, "technologies": [ "Next.js", "D3", "OpenAlex", "Neo4j", "Supabase", "Vercel" ], "competenciesDemonstrated": [ "Independent research-to-product design", "Graph-based information visualisation", "Full-stack engineering across a graph, relational, and search data layer" ], "links": [ { "label": "Open Research Atlas", "href": "https://www.researchatlas.app" } ], "outcomes": { "intro": [ "I evaluated the tool with an academically oriented group and recorded usage and performance over a 30-day period." ], "items": [ { "id": "research-atlas-user-discovery", "kind": "qualitative_outcome", "claim": "Structured feedback repeatedly identified **unexpected discovery** as the strongest source of value.", "measurement": { "source_type": "user_research", "status": "author_reported" } }, { "id": "research-atlas-visits", "kind": "measured_outcome", "claim": "The application recorded **115 visits**.", "metric": "visits", "value": { "value": 115, "unit": "visit" }, "measurement": { "source_type": "product_analytics", "status": "author_reported", "comparison_period": "30-day evaluation period" } }, { "id": "research-atlas-real-experience-score", "kind": "measured_outcome", "claim": "Vercel Speed Insights reported a **96/100 Real Experience Score**.", "metric": "vercel_real_experience_score", "value": { "value": 96, "unit": "/100" }, "measurement": { "source_type": "product_analytics", "status": "author_reported", "comparison_period": "30-day evaluation period" } } ], "outro": [ "Users described finding connected research areas and papers they would not have thought to explore.", "The evaluation also highlighted areas to improve: map readability, relevance controls, source coverage, exports and the explanation of the tool's exploratory purpose." ] }, "evidenceScope": "An academic product evaluation. Search-result relevance was checked using 30 queries across different subject areas; user feedback came from an academically oriented group. Product analytics cover a 30-day evaluation period. Queries, visits and participants are different measures.", "limitations": [ "I did not test willingness to pay or institutional demand, so commercial viability remains an open question." ] }, "content_hash": "sha256:d52b45d0e18656942a865dc1e75875a2bd8d7c1d97db31be3b8e1e5a24f52ebb", "evaluation_scope": "An academic product evaluation. Search-result relevance was checked using 30 queries across different subject areas; user feedback came from an academically oriented group. Product analytics cover a 30-day evaluation period. Queries, visits and participants are different measures.", "limitations": [ "I did not test willingness to pay or institutional demand, so commercial viability remains an open question." ], "outcome_context": { "intro": [ "I evaluated the tool with an academically oriented group and recorded usage and performance over a 30-day period." ], "outro": [ "Users described finding connected research areas and papers they would not have thought to explore.", "The evaluation also highlighted areas to improve: map readability, relevance controls, source coverage, exports and the explanation of the tool's exploratory purpose." ] } }, { "id": "bankuet-portal", "slug": "portal", "title": "Bankuet: Giving food banks control over supply requests", "card": { "title": "Food bank request portal", "deliverable": "Led the shift from algorithmic allocations to quantities and visible prices.", "outcomes": "Weekly processing ~4h → 1h · average underspend ~7% → 0%" }, "seo": { "title": "Food bank request portal", "description": "How I replaced algorithmic allocations with exact quantities and visible prices, reducing request processing from about four hours to one." }, "canonical_url": "https://laurence-peberdy.com/w/portal", "markdown_url": "https://laurence-peberdy.com/w/portal.md", "project_context": { "type": "organization", "name": "Bankuet", "url": "https://bankuet.co.uk" }, "project_date": { "precision": "day", "value": "2024-07-09" }, "published": "2026-08-05", "updated": "2026-09-06", "role": [ "Product Lead" ], "responsibility_summary": "I set direction, priorities and scope, and worked with our in-house UX Lead in Figma. I directed an external 2–4-person team across business analysis, engineering and QA, bringing in architecture support as needed.", "description": "Food banks could set a budget but not choose exact quantities. I led the shift to visible prices and case quantities, reducing weekly request processing from about four hours to one.", "summary": [ "Before v3, a food bank did not tell Bankuet exactly how many cases of each product it wanted. It set a total budget and marked products high, medium or low priority. An algorithm chose the quantities, and our team often had to interpret or adjust the result.", "I replaced that model with visible prices and exact case quantities. Food banks could see the cost of their choices and submit the request they actually wanted; Bankuet spent less time fixing the output." ], "problem": "**Food banks could express priorities, not quantities.** They could say what mattered most, but not how many cases they wanted. **They could not see the cost of each choice.** Without unit and case prices, users could not tell how a product affected their budget. **Bankuet had to repair the algorithm's output.** Allocations could underspend the budget or need manual adjustment before ordering. **Precise requests needed better financial context.** Food banks had limited information about previous requests, spending and their available balance. The evidence came from food bank feedback and my own experience processing Bankuet's supply orders each week.", "constraints": [ "The request form is not an isolated interface; it feeds Bankuet's weekly ordering operation. Three constraints shape it:", "**Requests feed a live weekly workflow.** Food bank requests flow directly into Bankuet's supply-ordering process, so errors in the request flow can create operational work as well as user confusion.", "**Exact quantities depend on trustworthy financial context.** Food banks need reliable balances and visible prices before more granular control is useful.", "**Prices can change before fulfilment.** The design needs a workable tolerance for changes between request and fulfilment rather than implying every displayed price is fixed." ], "hypotheses": [ "If food banks can choose exact quantities against visible prices, requests should become more accurate and understandable, reducing manual intervention and algorithmic budget underspend." ], "interventions": [ "I did not jump straight to exact quantities. First I made balances, request history and spending clearer, because precise choices only help if the user can trust the budget they are spending.", "With those foundations in place, **v3.0 — Volumes and Values** launched on **9 July 2024**, with:", "unit and case prices alongside each product;", "exact case quantities rather than none/low/medium/high preferences;", "a persistent basket that could be continued across sessions and accounts;", "an additional-supplies route for needs outside Bankuet's normal range.", "I kept v3.0 focused on request creation, leaving better search, further request-history improvements and help content for later releases.", "I ran research with food banks to test what price changes between request and fulfilment they would accept. We also released v3 to a small group before wider rollout to reduce operational risk." ], "competencies_demonstrated": [ "Product leadership on a live, multi-tenant platform", "Financial and operational product design" ], "showcase": { "provider": "vimeo", "videoId": "1012782893", "name": "How Bankuet Works For Food Banks", "description": "An animated explanation of how Bankuet turns donations into the supplies food banks need most.", "pageUrl": "https://vimeo.com/1012782893", "embedUrl": "https://player.vimeo.com/video/1012782893", "thumbnailUrl": "https://i.vimeocdn.com/video/1930632673-ab039db9f2d1346954a81843c3c8eee2c3a98c2200f30f8bec3eb1e575053762-d_2400?region=us", "duration": "PT2M20S", "caption": "How Bankuet Works For Food Banks · 2:20" }, "outcomes": [ "bankuet-portal-processing-time", "bankuet-portal-budget-underspend", "bankuet-portal-support-queries" ], "case_study": { "id": "bankuet-portal", "title": "Bankuet: Giving food banks control over supply requests", "card": { "title": "Food bank request portal", "deliverable": "Led the shift from algorithmic allocations to quantities and visible prices.", "outcomes": "Weekly processing ~4h → 1h · average underspend ~7% → 0%" }, "seo": { "title": "Food bank request portal", "description": "How I replaced algorithmic allocations with exact quantities and visible prices, reducing request processing from about four hours to one." }, "projectContext": { "type": "organization", "name": "Bankuet", "url": "https://bankuet.co.uk" }, "projectDate": { "precision": "day", "value": "2024-07-09" }, "published": "2026-08-05", "updated": "2026-09-06", "blurb": "Food banks could set a budget but not choose exact quantities. I led the shift to visible prices and case quantities, reducing weekly request processing from about four hours to one.", "role": [ "Product Lead" ], "responsibilitySummary": "I set direction, priorities and scope, and worked with our in-house UX Lead in Figma. I directed an external 2–4-person team across business analysis, engineering and QA, bringing in architecture support as needed.", "decision": "Stop optimising an allocation algorithm and let food banks choose exact quantities against visible prices.", "summary": [ "Before v3, a food bank did not tell Bankuet exactly how many cases of each product it wanted. It set a total budget and marked products high, medium or low priority. An algorithm chose the quantities, and our team often had to interpret or adjust the result.", "I replaced that model with visible prices and exact case quantities. Food banks could see the cost of their choices and submit the request they actually wanted; Bankuet spent less time fixing the output." ], "heroImage": { "src": "/images/foodbank-service-request-a-delivery.png", "alt": "Bankuet's request interface, showing products that food banks can request by case quantity.", "caption": "Choosing products by case quantity in the redesigned request interface." }, "problem": { "intro": [], "items": [ "**Food banks could express priorities, not quantities.** They could say what mattered most, but not how many cases they wanted.", "**They could not see the cost of each choice.** Without unit and case prices, users could not tell how a product affected their budget.", "**Bankuet had to repair the algorithm's output.** Allocations could underspend the budget or need manual adjustment before ordering.", "**Precise requests needed better financial context.** Food banks had limited information about previous requests, spending and their available balance." ], "outro": [ "The evidence came from food bank feedback and my own experience processing Bankuet's supply orders each week." ] }, "constraints": { "intro": [ "The request form is not an isolated interface; it feeds Bankuet's weekly ordering operation. Three constraints shape it:" ], "items": [ "**Requests feed a live weekly workflow.** Food bank requests flow directly into Bankuet's supply-ordering process, so errors in the request flow can create operational work as well as user confusion.", "**Exact quantities depend on trustworthy financial context.** Food banks need reliable balances and visible prices before more granular control is useful.", "**Prices can change before fulfilment.** The design needs a workable tolerance for changes between request and fulfilment rather than implying every displayed price is fixed." ] }, "hypotheses": { "intro": [ "If food banks can choose exact quantities against visible prices, requests should become more accurate and understandable, reducing manual intervention and algorithmic budget underspend." ], "items": [] }, "interventions": { "intro": [ "I did not jump straight to exact quantities. First I made balances, request history and spending clearer, because precise choices only help if the user can trust the budget they are spending.", "With those foundations in place, **v3.0 — Volumes and Values** launched on **9 July 2024**, with:" ], "items": [ "unit and case prices alongside each product;", "exact case quantities rather than none/low/medium/high preferences;", "a persistent basket that could be continued across sessions and accounts;", "an additional-supplies route for needs outside Bankuet's normal range." ], "outro": [ "I kept v3.0 focused on request creation, leaving better search, further request-history improvements and help content for later releases.", "I ran research with food banks to test what price changes between request and fulfilment they would accept. We also released v3 to a small group before wider rollout to reduce operational risk." ] }, "comparison": { "intro": [ "The request model before and after v3:" ], "items": [], "groups": [ { "heading": "Before — describe priorities", "intro": [], "items": [ "The food bank chooses an overall budget.", "Products receive high, medium or low priorities.", "An algorithm allocates quantities; Bankuet interprets or adjusts the result." ] }, { "heading": "After — choose quantities", "intro": [], "items": [ "The food bank sees unit and case prices.", "It chooses exact case quantities in a persistent basket.", "The request expresses the supplies wanted rather than a set of relative preferences." ] } ] }, "competenciesDemonstrated": [ "Product leadership on a live, multi-tenant platform", "Financial and operational product design" ], "showcase": { "provider": "vimeo", "videoId": "1012782893", "name": "How Bankuet Works For Food Banks", "description": "An animated explanation of how Bankuet turns donations into the supplies food banks need most.", "pageUrl": "https://vimeo.com/1012782893", "embedUrl": "https://player.vimeo.com/video/1012782893", "thumbnailUrl": "https://i.vimeocdn.com/video/1930632673-ab039db9f2d1346954a81843c3c8eee2c3a98c2200f30f8bec3eb1e575053762-d_2400?region=us", "duration": "PT2M20S", "caption": "How Bankuet Works For Food Banks · 2:20" }, "outcomes": { "intro": [ "The strongest outcomes were operational:" ], "items": [ { "id": "bankuet-portal-processing-time", "kind": "measured_outcome", "claim": "Weekly request-processing time fell from approximately **four hours to one hour** — a 75% reduction.", "metric": "request_processing_time", "before": { "value": 4, "unit": "hour" }, "after": { "value": 1, "unit": "hour" }, "change": { "relative": -0.75 }, "measurement": { "source_type": "internal_operational_data", "status": "author_reported", "scope": "Weekly request-processing workflow" } }, { "id": "bankuet-portal-budget-underspend", "kind": "measured_outcome", "claim": "Average budget underspend fell from approximately **7% to 0%**, comparing the three months before launch with the three months after.", "metric": "budget_underspend", "before": { "value": 7, "unit": "%" }, "after": { "value": 0, "unit": "%" }, "measurement": { "source_type": "internal_operational_data", "status": "author_reported", "comparison_period": "3 months pre-launch vs 3 months post-launch" } }, { "id": "bankuet-portal-support-queries", "kind": "measured_outcome", "claim": "Finance- and request-related support queries fell by approximately **50%** across the wider v2→v3 programme — not v3 alone.", "metric": "support_queries", "change": { "relative": -0.5 }, "measurement": { "source_type": "internal_operational_data", "status": "author_reported", "comparison_period": "v2 → v3 programme" } } ] }, "evidenceScope": "Internal operational observations. Budget underspend compares three months before launch with three months after. The support-query reduction belongs to the wider v2→v3 programme." }, "content_hash": "sha256:a26750a10217edc085dc783c9b34b4ac46e8dca11a635f7af79fcc2a9ce428d9", "evaluation_scope": "Internal operational observations. Budget underspend compares three months before launch with three months after. The support-query reduction belongs to the wider v2→v3 programme.", "limitations": [], "outcome_context": { "intro": [ "The strongest outcomes were operational:" ], "outro": [] } }, { "id": "bankuet-funding", "slug": "funding", "title": "Bankuet: Creating more flexible ways to fund the mission", "card": { "title": "Flexible funding propositions", "deliverable": "Originated and launched the General Fund and Support Bankuet propositions.", "outcomes": "General Fund: flexible food bank funding · Support Bankuet: engineering capacity" }, "seo": { "title": "Flexible funding propositions", "description": "How I created Bankuet's General Fund for flexible food bank giving and Support Bankuet for direct, unrestricted donations to the organisation." }, "canonical_url": "https://laurence-peberdy.com/w/funding", "markdown_url": "https://laurence-peberdy.com/w/funding.md", "project_context": { "type": "organization", "name": "Bankuet", "url": "https://bankuet.co.uk" }, "project_date": { "precision": "year", "value": "2022", "start": "2020" }, "published": "2026-08-09", "updated": "2026-09-06", "role": [ "Product & Operations" ], "responsibility_summary": "I originated the **General Fund** and **Support Bankuet** propositions and led their product design, launch and messaging.", "description": "I introduced a general fund in 2020 for donors who did not want to choose a food bank, and Support Bankuet in 2022 for direct, unrestricted donations to the organisation.", "summary": [ "Bankuet's original donor journey began with a choice: which food bank do you want to support? That worked for donors with a specific food bank in mind, but not for everyone.", "I introduced two additional ways to give at different points in the journey. The General Fund let donors support food banks without choosing one. Standard donations already contributed to Bankuet through an operating fee; Support Bankuet added a separate, unrestricted way to support the organisation itself after the donor had funded food bank supplies." ], "problem": "**Some donors wanted to help without choosing a food bank.** The original journey still required them to select one before they could fund supplies. **Supporting Bankuet itself was a different ask.** Donors who wanted to support the organisation needed a route that could not be confused with money intended for food bank supplies.", "constraints": [ "Both propositions sit beside the main reason people come to Bankuet: funding food bank supplies. That created three constraints:", "**Keep the purposes distinct.** Donors needed to understand whether they were funding food bank supplies or supporting Bankuet itself.", "**Do not interrupt the primary donation.** Support Bankuet had to sit outside the main giving flow, so the additional ask came after the first donation was complete.", "**Keep the experiment cheap.** Support Bankuet was worth testing because it could use existing Beacon forms rather than require a bespoke payment build." ], "hypotheses": [ "For the **General Fund**, if we removed the need to choose a food bank, donors without a preferred destination could still complete a donation while giving Bankuet a flexible pool to direct where it was most needed.", "For **Support Bankuet**, if we made support for the organisation a separate ask after the primary donation, we could create unrestricted income without confusing it with money for food bank supplies." ], "interventions": [ "2020 — General Fund", "I introduced a shared fund for donors who wanted to support the wider food bank network. Instead of asking them to choose a destination, Bankuet could direct those donations towards food banks most in need.", "2022 — Support Bankuet", "I introduced a separate route for direct donations to Bankuet and showed it only after the donor had completed the primary donation. That kept the additional ask out of the main food bank giving flow.", "I used Beacon CRM donation forms for this route, providing a low-risk live implementation before the later donor-platform rebuild." ], "technologies": [ "Beacon CRM" ], "competencies_demonstrated": [ "Product proposition design", "Stakeholder recommendation and buy-in", "Low-cost product experimentation" ], "outcomes": [ "bankuet-funding-general-fund-durability", "bankuet-funding-support-bankuet-durability", "bankuet-funding-beacon-testbed" ], "case_study": { "id": "bankuet-funding", "title": "Bankuet: Creating more flexible ways to fund the mission", "card": { "title": "Flexible funding propositions", "deliverable": "Originated and launched the General Fund and Support Bankuet propositions.", "outcomes": "General Fund: flexible food bank funding · Support Bankuet: engineering capacity" }, "seo": { "title": "Flexible funding propositions", "description": "How I created Bankuet's General Fund for flexible food bank giving and Support Bankuet for direct, unrestricted donations to the organisation." }, "projectContext": { "type": "organization", "name": "Bankuet", "url": "https://bankuet.co.uk" }, "projectDate": { "precision": "year", "value": "2022", "start": "2020" }, "published": "2026-08-09", "updated": "2026-09-06", "blurb": "I introduced a general fund in 2020 for donors who did not want to choose a food bank, and Support Bankuet in 2022 for direct, unrestricted donations to the organisation.", "role": [ "Product & Operations" ], "responsibilitySummary": "I originated the **General Fund** and **Support Bankuet** propositions and led their product design, launch and messaging.", "propositions": [ { "id": "general-fund", "name": "General Fund", "decision": "Let donors support food banks without choosing an individual one.", "outcomeSummary": "A flexible pool of donations for food banks most in need.", "outcomeIds": [ "bankuet-funding-general-fund-durability" ] }, { "id": "support-bankuet", "name": "Support Bankuet", "decision": "Offer a separate direct-support donation after the primary donation.", "outcomeSummary": "Unrestricted funding for external engineering capacity.", "outcomeIds": [ "bankuet-funding-support-bankuet-durability", "bankuet-funding-beacon-testbed" ] } ], "summary": [ "Bankuet's original donor journey began with a choice: which food bank do you want to support? That worked for donors with a specific food bank in mind, but not for everyone.", "I introduced two additional ways to give at different points in the journey. The General Fund let donors support food banks without choosing one. Standard donations already contributed to Bankuet through an operating fee; Support Bankuet added a separate, unrestricted way to support the organisation itself after the donor had funded food bank supplies." ], "problem": { "intro": [], "items": [ "**Some donors wanted to help without choosing a food bank.** The original journey still required them to select one before they could fund supplies.", "**Supporting Bankuet itself was a different ask.** Donors who wanted to support the organisation needed a route that could not be confused with money intended for food bank supplies." ] }, "constraints": { "intro": [ "Both propositions sit beside the main reason people come to Bankuet: funding food bank supplies. That created three constraints:" ], "items": [ "**Keep the purposes distinct.** Donors needed to understand whether they were funding food bank supplies or supporting Bankuet itself.", "**Do not interrupt the primary donation.** Support Bankuet had to sit outside the main giving flow, so the additional ask came after the first donation was complete.", "**Keep the experiment cheap.** Support Bankuet was worth testing because it could use existing Beacon forms rather than require a bespoke payment build." ] }, "hypotheses": { "intro": [ "For the **General Fund**, if we removed the need to choose a food bank, donors without a preferred destination could still complete a donation while giving Bankuet a flexible pool to direct where it was most needed.", "For **Support Bankuet**, if we made support for the organisation a separate ask after the primary donation, we could create unrestricted income without confusing it with money for food bank supplies." ], "items": [] }, "interventions": { "intro": [], "items": [], "groups": [ { "heading": "2020 — General Fund", "intro": [ "I introduced a shared fund for donors who wanted to support the wider food bank network. Instead of asking them to choose a destination, Bankuet could direct those donations towards food banks most in need." ], "items": [] }, { "heading": "2022 — Support Bankuet", "intro": [ "I introduced a separate route for direct donations to Bankuet and showed it only after the donor had completed the primary donation. That kept the additional ask out of the main food bank giving flow.", "I used Beacon CRM donation forms for this route, providing a low-risk live implementation before the later donor-platform rebuild." ], "items": [] } ] }, "technologies": [ "Beacon CRM" ], "competenciesDemonstrated": [ "Product proposition design", "Stakeholder recommendation and buy-in", "Low-cost product experimentation" ], "outcomes": { "intro": [], "items": [ { "id": "bankuet-funding-general-fund-durability", "kind": "qualitative_outcome", "claim": "The **General Fund** created a flexible pool of donations that Bankuet can direct towards food banks most in need, while giving donors a route that does not require choosing an individual food bank.", "measurement": { "source_type": "author_observation", "status": "author_reported" } }, { "id": "bankuet-funding-support-bankuet-durability", "kind": "qualitative_outcome", "claim": "**Support Bankuet** generated unrestricted funding for external engineering capacity used in major iterations of the food bank portal.", "measurement": { "source_type": "author_observation", "status": "author_reported", "scope": "Operational contribution described in Laurence's CV and case-study account" } }, { "id": "bankuet-funding-beacon-testbed", "kind": "qualitative_outcome", "claim": "Using **Beacon CRM** for Support Bankuet provided an early live test of its forms, payment flows and CRM behaviour, reducing uncertainty before the 2025 donor rebuild.", "measurement": { "source_type": "author_observation", "status": "author_reported" } } ] }, "evidenceScope": "Author-reported operational outcomes. Standard donations already contributed to Bankuet through an operating fee; Support Bankuet added a separate route for direct, unrestricted support. Funding contributions are described qualitatively, without a donation total or revenue-growth estimate." }, "content_hash": "sha256:d13a370f51ad64e06768a59eba6421cb09014bc0779676c1d99cc5bd121de2c0", "evaluation_scope": "Author-reported operational outcomes. Standard donations already contributed to Bankuet through an operating fee; Support Bankuet added a separate route for direct, unrestricted support. Funding contributions are described qualitatively, without a donation total or revenue-growth estimate.", "limitations": [], "outcome_context": { "intro": [], "outro": [] } } ], "relationships": [ { "subject": "laurence-peberdy", "predicate": "led", "object": "bankuet-reliability" }, { "subject": "laurence-peberdy", "predicate": "built", "object": "bankuet-reliability" }, { "subject": "bankuet-reliability", "predicate": "produced_outcome", "object": "bankuet-reliability-shared-checks" }, { "subject": "bankuet-reliability", "predicate": "produced_outcome", "object": "bankuet-reliability-held-release" }, { "subject": "laurence-peberdy", "predicate": "led", "object": "bankuet-donor" }, { "subject": "laurence-peberdy", "predicate": "built", "object": "bankuet-donor" }, { "subject": "bankuet-donor", "predicate": "produced_outcome", "object": "bankuet-donor-onboarding-time" }, { "subject": "bankuet-donor", "predicate": "produced_outcome", "object": "bankuet-donor-campaign-setup-time" }, { "subject": "bankuet-donor", "predicate": "produced_outcome", "object": "bankuet-donor-checkout-steps" }, { "subject": "laurence-peberdy", "predicate": "led", "object": "research-atlas" }, { "subject": "laurence-peberdy", "predicate": "built", "object": "research-atlas" }, { "subject": "laurence-peberdy", "predicate": "designed", "object": "research-atlas" }, { "subject": "research-atlas", "predicate": "produced_outcome", "object": "research-atlas-user-discovery" }, { "subject": "research-atlas", "predicate": "produced_outcome", "object": "research-atlas-visits" }, { "subject": "research-atlas", "predicate": "produced_outcome", "object": "research-atlas-real-experience-score" }, { "subject": "laurence-peberdy", "predicate": "led", "object": "bankuet-portal" }, { "subject": "bankuet-portal", "predicate": "produced_outcome", "object": "bankuet-portal-processing-time" }, { "subject": "bankuet-portal", "predicate": "produced_outcome", "object": "bankuet-portal-budget-underspend" }, { "subject": "bankuet-portal", "predicate": "produced_outcome", "object": "bankuet-portal-support-queries" }, { "subject": "laurence-peberdy", "predicate": "led", "object": "bankuet-funding" }, { "subject": "bankuet-funding", "predicate": "produced_outcome", "object": "bankuet-funding-general-fund-durability" }, { "subject": "bankuet-funding", "predicate": "produced_outcome", "object": "bankuet-funding-support-bankuet-durability" }, { "subject": "bankuet-funding", "predicate": "produced_outcome", "object": "bankuet-funding-beacon-testbed" } ], "author_notes": { "projects": { "bankuet-donor": { "why_included": "A full-stack rebuild with concrete before/after operational metrics, and the clearest example of moving between product and engineering work." }, "bankuet-portal": { "why_included": "Product leadership on a live platform with measured financial and operational outcomes, not just a shipped feature list." }, "research-atlas": { "why_included": "Built entirely independently, end to end — evidence of technical range beyond product leadership." }, "bankuet-funding": { "why_included": "Two propositions he originated and sold to the CEO himself, not just delivered — evidence of product strategy and stakeholder influence rather than delivery execution." }, "bankuet-reliability": { "why_included": "Treats security and reliability as part of product delivery, with implementation evidence and a recorded production-release proof rather than an invented business metric." } } }, "experiments": [ { "id": "second-reader", "type": "interface_experiment", "question": "What does a personal portfolio become when one of its readers is a software agent rather than a human?", "audiences": [ "human", "software_agent" ], "description": "The portfolio exposes the same factual information through two representations: a visually designed human interface, and a parallel machine-readable layer (JSON-LD, llms.txt, and structured JSON resources) with no visual design of its own.", "implementation": [ "semantic_web_metadata", "llms_txt_v2_discovery", "structured_portfolio_json", "structured_claims", "project_json" ] } ] }, "claims": [ { "id": "bankuet-reliability-lead-role", "subject": "laurence-peberdy", "project_id": "bankuet-reliability", "kind": "responsibility", "claim": "I designed and implemented Bankuet.co.uk's CI/CD pipeline end to end.", "canonical_source": "https://laurence-peberdy.com/w/reliability" }, { "id": "bankuet-reliability-shared-checks", "subject": "laurence-peberdy", "project_id": "bankuet-reliability", "kind": "qualitative_outcome", "claim": "Local development and GitHub share **one acceptance command**, including source and build-output secret scans.", "provenance": { "source_type": "implementation_record", "status": "author_reported", "scope": "Shared CI command and sealed local/CI production-build runner" }, "context": { "evaluation_scope": "Implementation and documented release-proof evidence from Bankuet's repository at b7fc75fc300f9d8319cf7f5bbe4bd2e41d035192. The controlled production proof was recorded on 4 September 2026 in issue 71. Source and output secret scans cover the local/CI build; Vercel builds separately. No measured reduction in incidents, vulnerabilities or downtime is claimed.", "limitations": [], "outcome_intro": [ "The pipeline makes acceptance checks repeatable and holds normal releases until the required checks pass." ], "outcome_outro": [ "The layers reduce reliance on any single check. They do not prove the application is free of vulnerabilities or that a live payment will complete." ] }, "canonical_source": "https://laurence-peberdy.com/w/reliability#bankuet-reliability-shared-checks" }, { "id": "bankuet-reliability-held-release", "subject": "laurence-peberdy", "project_id": "bankuet-reliability", "kind": "qualitative_outcome", "claim": "A controlled production proof on **4 September 2026** recorded the previous deployment staying public while checks were pending. The candidate went live only after the required checks passed.", "provenance": { "source_type": "implementation_record", "status": "author_reported", "observed_at": "2026-09-04", "scope": "Recorded production-candidate proof in Bankuet issue 71; not a new experiment performed for this write-up" }, "context": { "evaluation_scope": "Implementation and documented release-proof evidence from Bankuet's repository at b7fc75fc300f9d8319cf7f5bbe4bd2e41d035192. The controlled production proof was recorded on 4 September 2026 in issue 71. Source and output secret scans cover the local/CI build; Vercel builds separately. No measured reduction in incidents, vulnerabilities or downtime is claimed.", "limitations": [], "outcome_intro": [ "The pipeline makes acceptance checks repeatable and holds normal releases until the required checks pass." ], "outcome_outro": [ "The layers reduce reliance on any single check. They do not prove the application is free of vulnerabilities or that a live payment will complete." ] }, "canonical_source": "https://laurence-peberdy.com/w/reliability#bankuet-reliability-held-release" }, { "id": "bankuet-donor-lead-role", "subject": "laurence-peberdy", "project_id": "bankuet-donor", "kind": "responsibility", "claim": "I led product direction and architecture, recommended the move from Squarespace and built the production application. I worked with our fractional UX Lead and secured CEO buy-in.", "canonical_source": "https://laurence-peberdy.com/w/donor" }, { "id": "bankuet-donor-onboarding-time", "subject": "laurence-peberdy", "project_id": "bankuet-donor", "kind": "measured_outcome", "claim": "Technical food bank setup time fell from approximately **45 minutes to 10 minutes**.", "metric": "food_bank_onboarding_time", "before": { "value": 45, "unit": "minute" }, "after": { "value": 10, "unit": "minute" }, "change": { "relative": -0.78 }, "provenance": { "source_type": "internal_operational_data", "status": "author_reported", "scope": "Technical food bank setup, not the complete onboarding lead time" }, "context": { "evaluation_scope": "Before-and-after operational observations and a donation-step count. Technical food bank setup is a different measure from end-to-end food bank onboarding lead time. Campaign setup timings are not a measured staff-hours saving. The look-and-feel upgrade is described qualitatively, not as a measured conversion improvement.", "limitations": [ "Conversion measurement remains limited: the embedded Beacon donation form and application analytics sit across different systems. This case does not establish a conversion uplift attributable to the rebuild." ], "outcome_intro": [ "The redesigned site launched in October 2025. The clearest measured gains were in technical food bank setup and the donation flow:" ], "outcome_outro": [] }, "canonical_source": "https://laurence-peberdy.com/w/donor#bankuet-donor-onboarding-time" }, { "id": "bankuet-donor-campaign-setup-time", "subject": "laurence-peberdy", "project_id": "bankuet-donor", "kind": "qualitative_outcome", "claim": "Fundraising campaign setup went from around **one day to effectively instant**.", "provenance": { "source_type": "internal_operational_data", "status": "author_reported", "scope": "Reported setup-time comparison; not a measured staff-hours saving" }, "context": { "evaluation_scope": "Before-and-after operational observations and a donation-step count. Technical food bank setup is a different measure from end-to-end food bank onboarding lead time. Campaign setup timings are not a measured staff-hours saving. The look-and-feel upgrade is described qualitatively, not as a measured conversion improvement.", "limitations": [ "Conversion measurement remains limited: the embedded Beacon donation form and application analytics sit across different systems. This case does not establish a conversion uplift attributable to the rebuild." ], "outcome_intro": [ "The redesigned site launched in October 2025. The clearest measured gains were in technical food bank setup and the donation flow:" ], "outcome_outro": [] }, "canonical_source": "https://laurence-peberdy.com/w/donor#bankuet-donor-campaign-setup-time" }, { "id": "bankuet-donor-checkout-steps", "subject": "laurence-peberdy", "project_id": "bankuet-donor", "kind": "measured_outcome", "claim": "The donation flow was reduced from **five steps to three**.", "metric": "checkout_steps", "before": { "value": 5, "unit": "step" }, "after": { "value": 3, "unit": "step" }, "change": { "relative": -0.4 }, "provenance": { "source_type": "internal_operational_data", "status": "author_reported" }, "context": { "evaluation_scope": "Before-and-after operational observations and a donation-step count. Technical food bank setup is a different measure from end-to-end food bank onboarding lead time. Campaign setup timings are not a measured staff-hours saving. The look-and-feel upgrade is described qualitatively, not as a measured conversion improvement.", "limitations": [ "Conversion measurement remains limited: the embedded Beacon donation form and application analytics sit across different systems. This case does not establish a conversion uplift attributable to the rebuild." ], "outcome_intro": [ "The redesigned site launched in October 2025. The clearest measured gains were in technical food bank setup and the donation flow:" ], "outcome_outro": [] }, "canonical_source": "https://laurence-peberdy.com/w/donor#bankuet-donor-checkout-steps" }, { "id": "research-atlas-lead-role", "subject": "laurence-peberdy", "project_id": "research-atlas", "kind": "responsibility", "claim": "I independently researched, designed and built Research Atlas as my Master's capstone at the London Interdisciplinary School.", "canonical_source": "https://laurence-peberdy.com/w/atlas" }, { "id": "research-atlas-user-discovery", "subject": "laurence-peberdy", "project_id": "research-atlas", "kind": "qualitative_outcome", "claim": "Structured feedback repeatedly identified **unexpected discovery** as the strongest source of value.", "provenance": { "source_type": "user_research", "status": "author_reported" }, "context": { "evaluation_scope": "An academic product evaluation. Search-result relevance was checked using 30 queries across different subject areas; user feedback came from an academically oriented group. Product analytics cover a 30-day evaluation period. Queries, visits and participants are different measures.", "limitations": [ "I did not test willingness to pay or institutional demand, so commercial viability remains an open question." ], "outcome_intro": [ "I evaluated the tool with an academically oriented group and recorded usage and performance over a 30-day period." ], "outcome_outro": [ "Users described finding connected research areas and papers they would not have thought to explore.", "The evaluation also highlighted areas to improve: map readability, relevance controls, source coverage, exports and the explanation of the tool's exploratory purpose." ] }, "canonical_source": "https://laurence-peberdy.com/w/atlas#research-atlas-user-discovery" }, { "id": "research-atlas-visits", "subject": "laurence-peberdy", "project_id": "research-atlas", "kind": "measured_outcome", "claim": "The application recorded **115 visits**.", "metric": "visits", "value": { "value": 115, "unit": "visit" }, "provenance": { "source_type": "product_analytics", "status": "author_reported", "comparison_period": "30-day evaluation period" }, "context": { "evaluation_scope": "An academic product evaluation. Search-result relevance was checked using 30 queries across different subject areas; user feedback came from an academically oriented group. Product analytics cover a 30-day evaluation period. Queries, visits and participants are different measures.", "limitations": [ "I did not test willingness to pay or institutional demand, so commercial viability remains an open question." ], "outcome_intro": [ "I evaluated the tool with an academically oriented group and recorded usage and performance over a 30-day period." ], "outcome_outro": [ "Users described finding connected research areas and papers they would not have thought to explore.", "The evaluation also highlighted areas to improve: map readability, relevance controls, source coverage, exports and the explanation of the tool's exploratory purpose." ] }, "canonical_source": "https://laurence-peberdy.com/w/atlas#research-atlas-visits" }, { "id": "research-atlas-real-experience-score", "subject": "laurence-peberdy", "project_id": "research-atlas", "kind": "measured_outcome", "claim": "Vercel Speed Insights reported a **96/100 Real Experience Score**.", "metric": "vercel_real_experience_score", "value": { "value": 96, "unit": "/100" }, "provenance": { "source_type": "product_analytics", "status": "author_reported", "comparison_period": "30-day evaluation period" }, "context": { "evaluation_scope": "An academic product evaluation. Search-result relevance was checked using 30 queries across different subject areas; user feedback came from an academically oriented group. Product analytics cover a 30-day evaluation period. Queries, visits and participants are different measures.", "limitations": [ "I did not test willingness to pay or institutional demand, so commercial viability remains an open question." ], "outcome_intro": [ "I evaluated the tool with an academically oriented group and recorded usage and performance over a 30-day period." ], "outcome_outro": [ "Users described finding connected research areas and papers they would not have thought to explore.", "The evaluation also highlighted areas to improve: map readability, relevance controls, source coverage, exports and the explanation of the tool's exploratory purpose." ] }, "canonical_source": "https://laurence-peberdy.com/w/atlas#research-atlas-real-experience-score" }, { "id": "bankuet-portal-lead-role", "subject": "laurence-peberdy", "project_id": "bankuet-portal", "kind": "responsibility", "claim": "I set direction, priorities and scope, and worked with our in-house UX Lead in Figma. I directed an external 2–4-person team across business analysis, engineering and QA, bringing in architecture support as needed.", "canonical_source": "https://laurence-peberdy.com/w/portal" }, { "id": "bankuet-portal-processing-time", "subject": "laurence-peberdy", "project_id": "bankuet-portal", "kind": "measured_outcome", "claim": "Weekly request-processing time fell from approximately **four hours to one hour** — a 75% reduction.", "metric": "request_processing_time", "before": { "value": 4, "unit": "hour" }, "after": { "value": 1, "unit": "hour" }, "change": { "relative": -0.75 }, "provenance": { "source_type": "internal_operational_data", "status": "author_reported", "scope": "Weekly request-processing workflow" }, "context": { "evaluation_scope": "Internal operational observations. Budget underspend compares three months before launch with three months after. The support-query reduction belongs to the wider v2→v3 programme.", "limitations": [], "outcome_intro": [ "The strongest outcomes were operational:" ], "outcome_outro": [] }, "canonical_source": "https://laurence-peberdy.com/w/portal#bankuet-portal-processing-time" }, { "id": "bankuet-portal-budget-underspend", "subject": "laurence-peberdy", "project_id": "bankuet-portal", "kind": "measured_outcome", "claim": "Average budget underspend fell from approximately **7% to 0%**, comparing the three months before launch with the three months after.", "metric": "budget_underspend", "before": { "value": 7, "unit": "%" }, "after": { "value": 0, "unit": "%" }, "provenance": { "source_type": "internal_operational_data", "status": "author_reported", "comparison_period": "3 months pre-launch vs 3 months post-launch" }, "context": { "evaluation_scope": "Internal operational observations. Budget underspend compares three months before launch with three months after. The support-query reduction belongs to the wider v2→v3 programme.", "limitations": [], "outcome_intro": [ "The strongest outcomes were operational:" ], "outcome_outro": [] }, "canonical_source": "https://laurence-peberdy.com/w/portal#bankuet-portal-budget-underspend" }, { "id": "bankuet-portal-support-queries", "subject": "laurence-peberdy", "project_id": "bankuet-portal", "kind": "measured_outcome", "claim": "Finance- and request-related support queries fell by approximately **50%** across the wider v2→v3 programme — not v3 alone.", "metric": "support_queries", "change": { "relative": -0.5 }, "provenance": { "source_type": "internal_operational_data", "status": "author_reported", "comparison_period": "v2 → v3 programme" }, "context": { "evaluation_scope": "Internal operational observations. Budget underspend compares three months before launch with three months after. The support-query reduction belongs to the wider v2→v3 programme.", "limitations": [], "outcome_intro": [ "The strongest outcomes were operational:" ], "outcome_outro": [] }, "canonical_source": "https://laurence-peberdy.com/w/portal#bankuet-portal-support-queries" }, { "id": "bankuet-funding-lead-role", "subject": "laurence-peberdy", "project_id": "bankuet-funding", "kind": "responsibility", "claim": "I originated the **General Fund** and **Support Bankuet** propositions and led their product design, launch and messaging.", "canonical_source": "https://laurence-peberdy.com/w/funding" }, { "id": "bankuet-funding-general-fund-durability", "subject": "laurence-peberdy", "project_id": "bankuet-funding", "kind": "qualitative_outcome", "claim": "The **General Fund** created a flexible pool of donations that Bankuet can direct towards food banks most in need, while giving donors a route that does not require choosing an individual food bank.", "provenance": { "source_type": "author_observation", "status": "author_reported" }, "context": { "evaluation_scope": "Author-reported operational outcomes. Standard donations already contributed to Bankuet through an operating fee; Support Bankuet added a separate route for direct, unrestricted support. Funding contributions are described qualitatively, without a donation total or revenue-growth estimate.", "limitations": [], "outcome_intro": [], "outcome_outro": [] }, "canonical_source": "https://laurence-peberdy.com/w/funding#bankuet-funding-general-fund-durability" }, { "id": "bankuet-funding-support-bankuet-durability", "subject": "laurence-peberdy", "project_id": "bankuet-funding", "kind": "qualitative_outcome", "claim": "**Support Bankuet** generated unrestricted funding for external engineering capacity used in major iterations of the food bank portal.", "provenance": { "source_type": "author_observation", "status": "author_reported", "scope": "Operational contribution described in Laurence's CV and case-study account" }, "context": { "evaluation_scope": "Author-reported operational outcomes. Standard donations already contributed to Bankuet through an operating fee; Support Bankuet added a separate route for direct, unrestricted support. Funding contributions are described qualitatively, without a donation total or revenue-growth estimate.", "limitations": [], "outcome_intro": [], "outcome_outro": [] }, "canonical_source": "https://laurence-peberdy.com/w/funding#bankuet-funding-support-bankuet-durability" }, { "id": "bankuet-funding-beacon-testbed", "subject": "laurence-peberdy", "project_id": "bankuet-funding", "kind": "qualitative_outcome", "claim": "Using **Beacon CRM** for Support Bankuet provided an early live test of its forms, payment flows and CRM behaviour, reducing uncertainty before the 2025 donor rebuild.", "provenance": { "source_type": "author_observation", "status": "author_reported" }, "context": { "evaluation_scope": "Author-reported operational outcomes. Standard donations already contributed to Bankuet through an operating fee; Support Bankuet added a separate route for direct, unrestricted support. Funding contributions are described qualitatively, without a donation total or revenue-growth estimate.", "limitations": [], "outcome_intro": [], "outcome_outro": [] }, "canonical_source": "https://laurence-peberdy.com/w/funding#bankuet-funding-beacon-testbed" }, { "id": "laurence-peberdy-bankuet-tenure", "subject": "laurence-peberdy", "kind": "responsibility", "claim": "He joined Bankuet as a Business Analyst in March 2020, became Product & Operations Manager in October 2020, and has led product since April 2022.", "canonical_source": "https://laurence-peberdy.com/llms.txt" } ] } ``` ## Canonical resources - [Human portfolio](https://laurence-peberdy.com): The homepage and selected work. - [Portfolio Markdown](https://laurence-peberdy.com/portfolio.md): The introduction and all selected-work reading copies in one document. - [Portfolio JSON](https://laurence-peberdy.com/portfolio.json): Complete structured case studies. - [Claims JSON](https://laurence-peberdy.com/claims.json): Outcomes, provenance and evaluation context. - [Continuous integration and deployment (CI/CD)](https://laurence-peberdy.com/w/reliability.md): Complete Markdown case study. - [Donor experience rebuild](https://laurence-peberdy.com/w/donor.md): Complete Markdown case study. - [Research Atlas](https://laurence-peberdy.com/w/atlas.md): Complete Markdown case study. - [Food bank request portal](https://laurence-peberdy.com/w/portal.md): Complete Markdown case study. - [Flexible funding propositions](https://laurence-peberdy.com/w/funding.md): Complete Markdown case study.