Rebuilt Three Times: What a Membership Platform Taught Us About Maturing Requirements

Some products are designed once and extended for years. Others need to be rebuilt as the people using them learn what they actually need. A membership platform we built for an occupational safety and health association was the second kind: it went through three builds as requirements matured, before settling into its final form on Laravel 11 and Filament.

That sounds like waste, and a rebuild is never free. But for a system replacing years of spreadsheet administration, working versions are how the real requirements come out. This post covers what is worth protecting through a rebuild and what we would do earlier next time.

What the platform does

The association had been running its administration on spreadsheets. The platform replaced that with a self-service member portal and a full admin back office, covering:

• Tiered memberships with subscription billing through Laravel Cashier.
• A jobs board, community groups with articles, and events.
• Support ticketing and internal member messaging.
• A bilingual member portal that is aware of Arabic right-to-left layout.
• Per-resource authorisation policies across more than 30 models.
• Automatically generated OpenAPI documentation for the API.

Why the requirements kept moving

When an organisation replaces spreadsheets, the spreadsheet encodes years of informal decisions: which members count as active, who can see what, how exceptions are handled. Many of those rules are never written down. They surface when someone uses the new system and says "that is not how we do it".

That is normal, and it is the main reason a first version of a replacement system rarely matches the final one. Every working version gives people something concrete to react to, which is how unwritten rules become written requirements.

What is worth carrying through a rebuild

When a system is rebuilt, two things deserve to carry forward, and they are where we would invest first on any similar project.

The domain model

Members, membership tiers, subscriptions, groups, events and tickets are the nouns of the business. Once those are right, screens can change freely around them. Getting the model right is cheaper than getting the interface right, and far more durable.

The permission rules

With more than 30 models, access control could not be an afterthought. Per-resource policies give each kind of record its own explicit rules for who can view, create, update and delete it. Those rules describe the organisation, not the framework, so they can survive a rebuild intact.

Where the final build landed

The parts of a system that change most between versions are usually the ones closest to daily use: the admin experience, the member portal and the way features are grouped. The final build runs its back office on Filament, which gives the association's staff a consistent admin interface without every screen being hand-built.

The final stack also includes Laravel Reverb for real-time features and React with Tailwind CSS and MUI for member-facing pieces. Interface decisions like these are the ones that benefit most from watching people use a working version.

What we would do earlier

Looking back, three practices would have made the path shorter:

1. Map the spreadsheet rules explicitly before the first build. Sit with the people who maintain the spreadsheets and write down every rule and exception they apply by hand.
2. Treat the first build as a learning stage. If a rebuild is likely, plan for it: keep the first version narrow and focused on the workflows that teach you the most.
3. Stabilise the model and permissions before the interface. They are the parts you keep.

Is a rebuild a failure?

Not necessarily. A rebuild is a failure when nobody expected it and the second version repeats the first version's mistakes. It is a reasonable investment when each version is based on real usage and the lasting parts, the model and the rules, improve every time.

We generally argue for stabilising and extending existing software before rewriting it. We make that case in when rewriting a mobile app is the right call. Replacement systems for spreadsheet-run organisations are one of the exceptions, because the first version is how the real requirements are discovered.

A checklist for replacing spreadsheet administration

• Interview the people who maintain the spreadsheets, not just the people who read them.
• Write the unwritten rules down before designing screens.
• Model the core entities and permissions first.
• Keep the first version narrow and learn from its use.
• Plan the budget knowing a second iteration is likely.

The anonymised write-up is in our work library. Building a first version that is designed to learn is the heart of our MVP service.