Kitsuly 1.43.95 built directly on the membership and reward foundation from the previous release. Once memberships existed as a working customer feature, the next job was to make them flexible enough for different business models and polished enough to look like part of the storefront rather than an administrative add-on.

What changed

Membership tiers introduced a clearer hierarchy for stores that need more than a single member state. A merchant could structure levels with different names, positioning and benefits, making the system useful for businesses that want a progression model rather than a simple yes-or-no membership flag.

Reward presentation received the same attention. The card designer was expanded so customer-facing membership and reward cards could be styled deliberately instead of inheriting a generic box. Typography, spacing, visual emphasis and layout choices matter because a reward only feels valuable when the customer can understand what it is and how to use it.

The release also tightened persistence around the designer so saved card choices could survive normal editing and publishing cycles. That kind of work is less visible than adding a new control, but it is what turns a designer from a prototype into something a merchant can trust after a page reload, plugin update or later content edit.

Build 1.43.95 changelog

• Added support for multiple membership tiers rather than a single undifferentiated membership state.
• Expanded tier administration so names, positioning and benefit structures can be managed more clearly.
• Extended the reward-card designer with stronger layout and visual controls.
• Improved persistence so card design choices remain attached to the saved reward configuration.
• Kept tiers, rewards and reusable customer-facing components connected to the existing Kitsuly account workflow.

The important change in 1.43.95 was not that Kitsuly could display another card. It was that membership became something a merchant could shape around the business model. A coffee subscription, trade account, paid club and VIP loyalty program may all use the word membership, but they need different levels of structure and presentation.

Why this build mattered

Tiered programs only work when the customer can understand the difference between levels. A complicated ladder of benefits can create more confusion than loyalty, so the system needs to support clear presentation rather than force merchants into a particular program design. Giving the merchant control over the tier structure keeps the platform flexible while still providing enough organisation for reporting and customer communication.

Reward cards are part of that communication. They may appear inside an account page, campaign or membership area, which means their visual language needs to match the store. A reward that looks disconnected from the rest of the brand can feel like a coupon widget bolted on at the end. Better design controls help the customer read the reward as part of the same store experience.

What the release meant in day-to-day use

For day-to-day administration, the build made it easier to separate program logic from presentation. The merchant can decide what each tier means, then decide how that information should look to a customer. Those are related decisions, but they are not the same decision, and mixing them into one rigid template makes both harder to manage.

For the customer, the benefit is clarity. A tier name, current level, available reward and next step should be understandable without reading an instruction manual. The card designer gives the store more room to establish hierarchy visually, while the membership data underneath remains structured enough to power the account experience.

How it fits into the wider Kitsuly release path

Build 1.43.95 also demonstrated a recurring development pattern in Kitsuly: functionality first, then control. The earlier release proved the membership/reward workflow; this release made it more adaptable. Later builds would continue the same pattern in other parts of the platform, especially around site identity, documentation and WordPress.org compatibility.

That sequence matters for a large plugin. Adding everything at once often creates a collection of impressive screens that do not survive real use. Iterative builds make it possible to observe where merchants need more control, where settings need to persist more reliably and where a feature needs to integrate more deeply with the rest of the store.

What to take forward

A tier system should also be understandable to staff. If support cannot quickly tell why a customer belongs to one tier or what a reward is meant to provide, the program will eventually create more questions than loyalty. Clear names, deliberate rules and consistent card presentation help the customer and the team interpret the same membership state in the same way.

Build 1.43.95 therefore pushed the membership system toward something that could be presented, explained and maintained rather than merely stored. That distinction is important in ecommerce software: data structures are only useful when the surrounding interface makes them practical. The tier and card work turned the earlier membership foundation into a more usable customer experience.

One final benefit of the tier work is that it gives the merchant a clearer path for experimentation. A store can start with a small number of levels, watch how customers respond and refine the benefits without rebuilding the surrounding account experience. That is healthier than launching an over-engineered loyalty program on day one. The system should make iteration easier: clear tiers, understandable rewards and presentation controls that can evolve as the business learns what customers actually value.