Case study · an Oʻahu neighborhood organization

How an Oʻahu neighborhood organization retired the spreadsheet only one person understood

The fix wasn’t custom software. It was choosing the right off-the-shelf tool, and doing the unglamorous work of making it fit.

The situation

A neighborhood association, volunteer-run for decades: a park and beach access to maintain, a community to speak for, a craft fair and events to run. For over thirty years, one committed volunteer ran membership herself, most recently in two spreadsheets she built and understood. Her system worked, for her, for a long time. The strain only showed when she was ready to step away: lists that disagreed, no backup, and no way to hand a system shaped around one person to anyone else.

A system that works and a system that can be handed on are two different things. Every organization has a version of this.

What we did

  1. Mapped what the organization needed, first

    Before looking at a single product, I mapped everything the organization needed its systems to do: membership management, automatic payments, a website, member email, park reservations. The map came first; the shopping list fell out of it.

  2. Chose off-the-shelf, deliberately

    Nothing on that list needed to be custom. So instead of building, I evaluated ten to fifteen membership and HOA products against the map, on price and feature coverage, and picked one.

  3. Hit the real problem: the software assumed a traditional HOA, and this was a community

    The product assumed flat annual dues, standard for HOAs. This organization runs on tiered giving instead (several named levels, from annual tiers up to lifetime members), and the treasurer needed everyone’s existing renewal dates preserved, so dues income would stay spread across the year.

  4. Made it fit, with many bill types

    The setup that worked was a distinct bill type for every combination of giving tier and renewal month. It wasn’t as elegant as we’d hoped, but it works, and the organization’s cash flow didn’t need to change to accommodate the software.

The result

3–4 people

now share what had been a near-full-time job for one volunteer

Self-serve

members update their own contact details, with fewer typos and stale records than spreadsheet entry ever managed

Mostly automated

payment collection, with far fewer paper checks to handle and deposit

The new system also unlocked things the spreadsheets never could: filterable member data for outreach, and the groundwork for online park reservations and a searchable member directory.

Why this is how Kuriri works

This is the Kuriri process: map how the organization runs and what it needs, then choose the fix that fits. This time the fix wasn’t custom software at all. Kuriri isn’t a software shop with software to sell you. When the right answer is a product that already exists, that’s the recommendation. Kuriri can then help with the real work of onboarding an organization into a new software system.

Systems before software.

What’s the system in your business only one person understands?

More case studies

A small product company

The busywork taken out of every order

Manual steps that scaled badly. A small tool, grown into a pipeline, absorbed peak season without a single new hire.

A global advertising business

A process no one could see whole, mapped

The whole process on a wall before anyone proposed a tool. The same move Kuriri makes with a local business, at enterprise scale.

An enterprise software maker

Development time, cut by two-thirds

Nothing was replaced: the existing work was inventoried and unified into shared parts.

All case studies →