One Household, One Login, One Ledger: Rebuilding a Nonprofit’s Membership Platform on Wix Velo
About the Client
Our client is a long-established, dues-based nonprofit whose members gather regularly to hear outside speakers on a shared field of professional and public interest. Two things define how it works.
First, membership belongs to households, not individuals. A person can join alone or with a partner, and a couple is one membership, not two. Second, the year runs on a steady rhythm of paid dinner and luncheon meetings, with members renewing annually.
For most of its history, the organization has been run by committed volunteers. When it set out to put day-to-day administration on a more structured, digital footing, its website was the obvious place to start. It was also where things had quietly started to come apart.
Executive Summary
The real trouble was record-keeping, and it was hiding inside the website. The Wix site had grown two separate ways to become a member, neither aware of the other. Its events tool couldn’t say who was coming to dinner, who was bringing a guest, or who had already paid.
Rather than move the organization off a platform it knew and trusted, we built what Wix couldn’t provide out of the box: a custom membership, events, and credit system written in Wix Velo and layered onto the existing site. At its center sits one idea: the household is the record everything else hangs from. That gives the organization one application flow, one approval pipeline, one login per household, and one ledger for every credit and refund.
Two engineering choices make that idea last. The architecture is modular, so each capability can grow or change without disturbing the others. The database is built around a single household record with defined relationships, so data stays consistent as membership and event volume increase.
Just as important as the software was how it came together. The system was shaped with the client at every step: mapping their real-world processes, working through the rules behind each feature, and reviewing progress milestone by milestone.
The core modules are built, and the remaining components are rolling out in phases. What follows is how we arrived at the design, the calls we made along the way, and why keeping the platform while rebuilding the logic turned out to be the right trade.
The Challenge
Two front doors, no shared hallway. Membership sign-up had split into two paths: Wix’s native membership system, and a custom application form built on top of it. Each held part of the picture, and neither held all of it. The result was duplicate member records and logins that drifted out of sync. Nobody could reliably answer a simple question: who, exactly, is a current paying member?
A household the system couldn’t see. The organization thinks in households, but Wix’s native membership tools think in individual accounts. A couple who joined together could show up as two unrelated people, or as one person with a partner tucked into a form field. Every downstream task, from renewals to the roster, inherited that mismatch.
Events that stopped at the RSVP. Meetings ran through Wix’s built-in Events app, which handled a sign-up and little else. It couldn’t capture guests or per-person meal choices, and it had no link to payments or any notion of credit. There was no structured way to see who was actually attending a given dinner or luncheon, which is the part that matters most for a calendar of paid, catered meetings.
Cancellations with nowhere to go. When a member cancelled a paid reservation, the system had no answer. Each cancellation became a one-off decision and a manual refund.
Reconciliation as a standing chore. All of this landed on whoever was handling administration at the time. They cross-checked records across systems, merged duplicates, and pieced together each household’s status by hand. That was workable at a small scale. It wasn’t going to stay workable as membership and event volume grew.
What We Brought to the Table
Wix experience beyond the page builder. Wix is one of the platforms we build on regularly. We know where its native tools stop, and where Velo, its custom code layer, can take over.
A model-first mindset. We treat the client’s real-world structure as the starting point for the data model, instead of squeezing it into whatever a plugin happens to support.
Scoping as a conversation. We refined requirements with the client, workflow by workflow, before development began. That way the build reflected how the organization actually operates, and did not lean on how a template assumes it does.
Scalable architecture. We separate what a platform already does well from the business rules it can’t express, and build those rules as independent modules. New capabilities plug in beside existing ones instead of forcing rework.
Robust database design. We model data around how a client’s organization is actually structured, with clear relationships and controlled statuses, so records stay consistent and traceable as volume grows.
How We Worked Together
This project was shaped as much in conversation as in code. The organization knew its members, its meetings, and its pain points better than anyone. We knew what Wix and Velo could be made to do. The build worked because both kinds of knowledge stayed in the room.
- Their operations, their language. We started by learning how the organization runs day to day: how a couple joins, who approves a new member, how a dinner is priced, and what happens when someone cancels. We used their terms for things, so requirements read the way their team talks.
- Scope refined together. Requirements weren’t a fixed list to sign off and forget. We walked through each workflow with the client, asked questions where the rules had never been written down, and brought options back where more than one answer made sense. When new detail surfaced, we folded it in openly and talked through what it meant for the plan.
- Decisions made with the reasoning on the table. The biggest calls were explained, discussed, and agreed before we committed to them: staying on Wix, building a custom layer instead of stretching native tools, and putting the household at the center of the data model. The client understood what we were building and why.
- Plain, steady communication. A volunteer-led organization doesn’t have an in-house technical team to translate for it. We kept updates clear and jargon-free, flagged changes early, and made sure timelines and scope were understood on both sides, including when new requirements meant the plan needed to adjust.
What We Did
We started with the model, not the features
Before talking about screens, we mapped how the organization really runs against what Wix’s native membership and events tools could represent. That meant households of one or two people, an approval step before anyone becomes a member, and a recurring calendar of paid meetings.
The gap between the two told us what to build. Faking households inside an individual-account system, or bolting approval onto a tool that assumes instant sign-up, would have meant living with workarounds forever.
Scoping ran as a genuine back-and-forth. We wrote our understanding of each workflow back to the client, so they could correct anything we’d got wrong before it became code. A detailed clarification round then surfaced specifics a feature list alone would have missed: the fields needed to register guests, how events should be listed and sorted, and which payment options members would need. Each was discussed, agreed, and folded into scope before development picked it up. It added work to the plan, and it meant the system would match how meetings actually run.
We kept Wix and rebuilt the logic
The decisive call was to stay put. The organization already relied on Wix for hosting, page building, and payments, and those parts worked well, with no servers for a volunteer team to manage. The business logic sitting on top was what needed replacing.
So we built the membership, approval, events, and credit rules as a custom Velo application layered onto the existing site. That gave us full control over the data model and rules, with no disruption to infrastructure the client already trusted and no new payment gateway to introduce.
Inside that layer, each capability is its own module with clear boundaries: registration and approval, the admin backend, events, the credit wallet, the member dashboard, and the roster. Shared logic such as household lookups, pricing, and credit calculations is written once and reused, so new features plug in beside existing ones instead of forcing rework.
At the data level, the household sits at the center. Members, applications, event registrations, and credit-ledger entries each live in their own collection and link back to a single household record. Rules for approval, pricing, credit and status changes run in backend code, so behavior is the same however a member reaches the site. That one structural decision keeps every other feature consistent.
We collapsed two sign-up paths into one, and made “member” mean something precise
A single “Join Membership” flow replaced both old paths. Applicants choose Single or Couple membership, and the form adapts, showing a second applicant’s fields only when needed. How a partner is added, who acts as the primary member, and what each person can change were settled with the client, so the form reflects their policy, not a software default.
Submitting creates a pending application, not an account. Nothing reaches the live membership data until an admin has reviewed it, so incomplete or rejected applications never clutter the roster. Every application then moves through a defined lifecycle:
Submitted → Admin Review → Approved (Pending Payment) → Active (or Rejected at review)
Approval automatically creates the household and member records and issues login credentials. A membership only turns Active once payment is complete, so “active member” always means reviewed and paid.
Each household gets a single login linked to both members’ email addresses, and only the primary member can change the password. Duplicate accounts are no longer something admins have to clean up, because the system doesn’t allow them.
Cyblance Technologies partnered with the client to design and develop this platform on Laravel, chosen for its maturity, security defaults, and ability to scale cleanly as auction volume and user roles grew. The result was a purpose-built marketplace where bidding logic, payments, and role-based dashboards worked together as one coherent system rather than a collection of bolted-on features.
We rebuilt events around the people attending
A custom events module replaced Wix’s native Events app. Members can now do all of this in one flow:
- register for a meeting
- add guests
- choose a meal for each attendee
- pay
Pricing adjusts to who’s actually coming, with member and guest rates and meal choice where it applies. Checkout runs through the site’s existing Wix payments rather than a separate system. For the first time, the organization can see who is attending each meeting, who they’re bringing, and what everyone is eating.
Much of this module’s detail came straight from the client. They knew which guest details their organizers needed, how meetings should appear in the listing, and which payment options members expected. Our job was to turn that knowledge into a registration flow that feels simple from the member’s side.
We turned cancellations into credit
This is the feature that removes the most manual work. When a member cancels a paid registration before the event’s deadline, the amount automatically becomes household credit, which is then applied to future event payments.
Credit is stored as individual ledger transactions, so every balance can be traced back to a cancellation, a payment, or an admin adjustment. Admins can still make manual adjustments for genuine exceptions, and every transaction, automatic or manual, lands in a transparent, auditable ledger. There are no one-off refunds to track and no guesswork about who is owed what.
The rules behind the wallet were worked through with the client: when a cancellation qualifies, how credit is applied, and where an admin should be able to step in. A credit system only works if members trust it, so the logic had to match the organization’s own sense of what’s fair.
We gave admins one clear view, and members the keys
The admin backend organizes each household into three tabs:
- Profile: household and member details, status, and admin actions
- Events: each member’s registration history and cancellations
- Credits: the full ledger
Understanding a household used to mean cross-referencing separate systems. Now it takes one screen, laid out around the questions administrators actually ask: Is this household current? What have they signed up for? What are they owed?
Members get a dashboard showing their membership status, credit balance and history, and upcoming and past registrations. Self-service cancellation is available right up to each event’s deadline. A member-only roster directory lists active households and basic contact details for networking, and deliberately leaves out anything financial or attendance-related.
We built QA into every module and delivered in milestones
Data integrity is the point of a system like this, so QA ran alongside development for every module. Testing concentrated on the places most likely to break:
- Single-vs-Couple household handling
- Credit-ledger calculations
- Consistent behavior when membership or event statuses change
Rather than disappearing for months and returning with a finished system, we’re delivering the work module by module: registration and approval first, then the admin backend, then events and credit, then the member dashboard and roster. Each milestone gives the client a concrete piece of the system to review before the next one builds on it. That rhythm keeps surprises small and feedback early, and when scope changes come up, their effect on the timeline is made clear at the time.
This was a functional and architectural rebuild, not a redesign. Design effort went into usability, layout, and responsive behavior inside the new modules, all matched to the organization’s existing visual identity.
The Outcome
The organization now has one system that mirrors how it actually works: built around the household, gated by approval, and tied together by a single ledger.
It’s also a system the organization helped design. The rules it enforces are their rules: who counts as a member, how a couple joins, what happens when a dinner is cancelled. They were worked out together and built in.
| Area | Result |
|---|---|
| Platform | Wix + custom Velo development |
| Architecture | Layered and modular, with each capability built as its own module |
| Database | Household-centered design, separate collections per entity, transaction-based credit ledger |
| Core model | Single or Couple membership, one login per household |
| Registration paths | 2 disconnected paths → 1 unified flow |
| Membership lifecycle | Application → Approval → Payment → Activation |
| Events | Custom module with guests, per-attendee meals, member/guest pricing |
| Cancellations | Automatic conversion to household credit, with an auditable ledger |
| Core modules built | Registration & approval, admin backend, events, credit wallet, member dashboard, roster |
What the system is designed to change
- Far less reconciliation. With one household record and one login, duplicate and conflicting member data stops being created in the first place.
- Cancellations without the admin overhead. Credit is issued and applied automatically, with manual control kept for real exceptions.
- Self-service for members. Households can check their own status, credit, and registrations without contacting an admin.
- Room to grow. New event types, membership categories, and features can be added without rebuilding what already works.
- A foundation for going digital. The organization’s move toward structured, digital administration now has a system built to support it.
We haven’t put numbers on these outcomes yet. We won’t until the system has been in regular use long enough to measure them properly, and this case study will be updated with real results when that happens.
What’s Next
The remaining components are being completed and rolled out in phases. Because every feature draws on the same household record, each addition extends the system without working around it. Once the full platform is live and in everyday use, the focus shifts to measuring the difference: admin hours saved, cancellations handled without intervention, and how members use their dashboard.
That next stage will be as collaborative as the first. We’ll keep working alongside the organization as the remaining pieces go live, gathering feedback from the people who use the system every day and refining it where real-world use points the way.
Conclusion
Not every broken system needs to be replaced. Sometimes the platform is fine, and what’s missing is a way for it to understand how the organization actually works.
We kept what Wix does well and built the part it couldn’t do: a membership model centered on the household, an approval gate that means something, and a ledger that turns cancellations into credit instead of paperwork. All of it sits on a modular architecture and a carefully structured database, so the platform can keep growing without losing the consistency that made it worth building.
Running on a platform that almost fits? Talk to Cyblance about building the part that doesn’t, without starting over.
