Non-Profit Digital Footprint Overhaul

The Problem

A museum non-profit with several historic sites and retail shops was running on a patchwork of disconnected tools: WooCommerce for online sales, an events plugin for ticketing, Clover for in-person sales, and a WordPress site with years of accumulated content. None of these systems shared a common picture of customers, products or revenue. Staff bridged the gaps with spreadsheets, double entry and knowledge that lived in a few people’s heads.

The organization knew it needed to modernize but couldn’t describe what it had, how it connected, or what needed to change. That was where I came in, and it shaped everything after.

My part of the project shifted as it went: discovery and documentation first, then project management on the pieces that touched staff directly, inventory and acceptance testing, while our technical lead and a partner agency built the platform.

Phase 1: The Documentation Site

The first deliverable was a documentation website rather than software: about 30 pages that mapped the whole digital footprint and gave a development team something to plan against.

• Platform reviews for WordPress, WooCommerce, the events plugin and Clover, what each does, what data it holds, and where migration gets hard
• Schema mapping across all four systems
• A migration plan with the phased-versus-all-at-once trade-offs written out so the client could choose
• POS planning, scope and roadmap pages for leadership

Every stakeholder call was transcribed, and AI turned the transcripts into structured pages. That let me spend the calls asking better questions instead of taking notes, and nothing said in a meeting got lost on the way to the page.

The docs site outlived its original purpose. When Phase 1 closed in April, the project agreed to use it as the shared reference for everyone working on the build.

The Commerce Decision

The original plan put the organization on Shopify for both the website and in-store sales. In April, during what was meant to be POS planning, the client pushed back: website benefits alone weren’t enough, and any change had to fix the real Clover pain points, moving stock between shops, cost changes, reorder visibility and reporting.

The room asked for the comparison in writing, and the platform research and POS vendor analysis were committed the next day. After a short Clover proof of concept against the hardest ticketing and membership workflows, Clover became the platform being built. The new website, CMS and portals were built around it.

What the project became:

• A new public website and a content management system that staff edit directly
• A staff portal for inventory, tickets, checklists and reporting
• A board governance portal for meetings, documents, resolutions and committees
• Online shop, ticketing and membership on Clover, across six merchant accounts
• A single sign-in system across all of it

The Inventory Count

Inventory was the part of the project that touched staff most directly, and the part I owned most. The shops had years of drift between what Clover said and what was on the shelf, and inventory moved between shops without a clean record.

I wrote the inventory entry process and the count plan, and worked the count through with the shop manager and two of our developers. In July the shops closed for two days and staff physically counted everything:

Measure	Result
Items counted	1,238
Units counted	about 21,000
Shops	4
Suspect items recounted	91
Time to load counts into Clover	more than a day → about 90 minutes

The recounts were worth doing. One item counted at 20 came back at 232 after someone found boxes in the back room, and several hundred “missing” units of another were all accounted for.

The load itself was done carefully: a dry run, a single-item test push confirmed four ways, then each merchant account in turn, smallest first, with every write read back. It still went wrong once. A blank cell in the source data was treated as zero, and a few hundred items showed empty shelves that afternoon. The shop manager caught it in a by-store report within hours. Because every write had a before-and-after record, we found exactly which items were affected and restored 372 of them in about 15 minutes.

The retrospective afterwards covered every mistake, including one of mine: an AI-assisted edit to the workbook had quietly dropped some count columns, and I had to recover the earlier version from the file history. The write-up turned each mistake into a rule for the next count, such as re-running the workbook’s tie-out checks after any bulk or AI-assisted edit and rebuilding any load that was prepared before a sheet changed.

Running Acceptance Testing

From August I ran user acceptance testing. The structure was one plan per workstream, three named roles for each, and results recorded against content, visual and functional parity with the old site. The first version was too much for staff who had an hour at a time and were not technical, so I cut it to two pages and moved the detail behind it.

That work grew into:

• Nine domain test plans and a coverage-gap register
• Staff testing sessions through September
• A 19-area maturity assessment of the platform
• A classification of all 750 manual test steps by whether they could be automated

The last item led to the largest piece of work I did on the project, an automated Playwright suite of about 650 tests run against the deployed test site.

Keeping the Record

Two things made the project easier to run in its second half. The first was a rule the client asked for after an expectation gap in June: if it wasn’t discussed in the meeting, it didn’t happen. The second was that nothing is marked done until it has been built and reviewed.

Both depended on a reliable record, so I wrote one. The build record reconstructs the project from 35 recorded meetings and 121 pull requests. It shows what was decided and why, when the work actually landed, and where the two disagree. It became the reference for questions like “when did we agree to that?”

Current Status

Launch is scheduled for mid-October, with the old WordPress site retired a few weeks later. My current work is the pre-launch plan, the post-launch backlog and support list, and handing the automated testing to the development team.