A Board Member Shouldn’t Have to Go Find the Book.

The cemetery had operated for more than a hundred years using paper records: ledger books, plot maps, and index cards. Later, board members also emailed spreadsheets back and forth.

The records were there, but a board member at the cemetery couldn’t always get to them. If a family called to ask whether there was space beside a grandmother’s plot, someone had to go find the book. I wanted the board member with the phone to be able to look up the answer.

The board was made up of volunteers, and volunteers changed. A new member might not know where to find things. I needed the records to be available to whoever had the question, including on a phone at the cemetery.

I built two applications sharing one database: a public site for families and the community and an administrative portal for the board. The portal held member records across four categories, plot and burial-position assignments, and a financial ledger. Roles controlled the work available to the treasurer, secretary, and officers.

The burial rules took the most care. A plot could hold a full burial, a full burial with a cremation at the foot, or up to four cremations in defined positions. The positions already occupied determined what remained available. If I got that wrong, a family could be told there was room when there wasn’t.

I calculated plot status from the burial assignments instead of asking a volunteer to update another field. Burial records permanently blocked the positions they occupied. There was no soft delete or archive path that could make occupied space look free.

Other records could be archived and restored. Volunteers make mistakes, and I didn’t want a wrong click to permanently remove the association’s records.

Board members used it from their phones for member records, plot lookups, burial positions, and the ledger. I designed around that use: in the cemetery, at a meeting, or on a call with a family.

The public site delivered messages from families and the community to the board.

The next board would have the same place to find the records.

I audited and repaired the system in two days with eleven parallel AI workers managed by a tool that ran checks on their work. Each worker owned separate files. Before merging, each task had to pass an executed command. If it failed, the next attempt received the failure output.

The audit found several problems that could interfere with the board’s work:

The public contact form logged submissions instead of sending them. It thanked the sender, but the board didn’t receive the message. The page gave no indication that delivery hadn’t happened.

The documentation, API, and interface described three different sets of permissions. Board members could see buttons for actions they weren’t allowed to complete.

Member deletion was permanent. The ledger’s foreign key had no cascade rule, so trying to remove a member with financial history returned a server error. Depending on the member’s history, deletion either lost the record permanently or failed.

Sessions expired after thirty minutes. The API had a refresh endpoint, but the front end didn’t use it, so volunteers could lose work during data entry.

Half the production database schema wasn’t in version control, and real member data had been committed to the repository.

I closed those findings with nine guarded migrations, consistent permission rules, soft deletion for administrative records, derived plot status, a nineteen-test integration suite, and working email delivery. All nineteen tests passed against production. I attached the verification results to each issue.

The tests also found something the audit missed: a production plot-type constraint contained values meant for an entirely different kind of data.

I didn’t find either problem in code review or the local checks. I found them by querying Application Insights after deployment. That was why I kept checking after the deployment succeeded.