ablefyCommunity 0→1AI-nativeShipped2025–2026

A community that starts from the product you already sell

Problem: Sellers had their products, their audience and their payments on one platform, and the conversation around all of it somewhere else. A rebuilt community had to solve the cold start: a new community is an empty room, and nobody wants to be the first one in it.
Solution: A setup flow that starts from what the seller already has. Pick the product, and the system drafts the community's name, description, vision and first rooms from it; the seller edits and approves before it exists. Underneath, a design system built from scratch for the new stack the community runs on.
Result: MVP and MLP — the minimum lovable product, the version worth launching with — inside three months, validated with twelve moderated beta sessions before launch. I handed the product over at that point, as planned from the start.

Role & team

Sole designer on the product

Scope on this page: the community setup experience, rooms, posts and comments, members, and the product and account sync behind them.
Built the community product's own design system for the new stack — a separate thing from the platform's component library.
Ran the beta programme myself, then handed the product over and moved on to build the customer-insights system.

Duration & scope

The community product itself

132 published components across the concept, MVP and MLP pages of the design file.
Two research rounds: five sellers on the MVP while it was still a prototype, July 2025; then twelve moderated beta sessions, 25 November to 8 December 2025.
Part of a wider community research programme: 40+ interviews across the work.

Key metrics

MVP and MLP inside three months

Every AI step in the setup flow shipped with its failure state designed, not bolted on.
The beta programme ran before public launch, not after it.
No adoption numbers on this page — I handed the product over before there were any.

At ablefy, a creator-commerce platform, sellers already had the hard parts in one place: a product, an audience who had paid for it, and the payments behind that. What they did not have was anywhere for those people to talk to each other — the conversation happened on other platforms, or it did not happen at all.

I was the only designer on the rebuild: a community product from scratch, on a new tech stack, in a new squad. The MVP and the market-launch-ready product were delivered inside three months, and then I handed it over so I could take on customer insights full time.

The empty room came first: a new community had to be worth opening on day one, before a single member had joined or posted. The seller had already done most of that work — their product, its description, its audience — so the setup flow should read all of it rather than ask for it again. And on the new stack there was no component library, no patterns and no precedent, which made the design system part of the deliverable rather than a follow-up.

The empty-room problem

Every community product looks the same on the day it launches: a blank feed, no members, and a seller staring at a form asking them to name something that does not exist yet.

So the design question was not “what does a community need” but “what can we hand the seller that is already worth something”. The answer was sitting in their account: the product they had already written, priced and sold.

Setup starts from the product the seller already sells

The setup flow starts by asking which product the community is for, then reads it — name, description, positioning — and drafts the community around it: what it is called, what it says about itself, what it is for, and which rooms it opens with. The seller edits any of it and approves before the community exists.

The seller never gets a community they did not read first, and every generated field is an editable draft rather than a fact.

Pick a product, watch the community draft itself

The seller chooses what the community is for; everything below it is a draft they can edit, and nothing is published until they say so. Switch the state to see what happens when the draft comes back incomplete, or not at all.

Which product

State

Community namedraft · editable

Beginner Riders Club

Descriptiondraft · editable

For everyone working through the 8-week course — ask anything, post your progress, ride better.

What it's fordraft · editable

A place where a nervous first-timer can ask the question they think is stupid.

Opening roomsdraft · editable

Introductions
Week-by-week
Ask the coach

Review and publishNothing exists until this is pressed.

Reconstruction, simplified for the story · synthetic products and copy · the three states are the ones the design file carries

Designing the half-finished answer

Anything generative fails in ways a form does not. It half-finishes. It produces something confident and wrong. It takes long enough that people assume it has broken.

So every step in the flow shipped with the state where it does not work. A generation that completed some steps and not others keeps what landed and offers a retry on the rest. A sync that is still running has its own screen, and a longer-than-expected wait has another. A failed sync says which part failed. And an account or product that was never connected is designed in every combination — none connected, one, several.

The design file carries those failure states as their own components, rather than as footnotes on the version where everything goes right.

The shipped review-your-setup modal with one section marked 'This section couldn't be generated — we couldn't generate content for this section automatically, please fill it in yourself', while the generated sections around it stay editable — The shipped version of the same rule · a generation that half-finished keeps what landed, and the failed section says so and hands over

Four designed states of the AI setup banner, exported from the Figma file: the URL ask, the failed extraction offering a screenshot upload instead, the analyzing wait against the action plan, and the review gate with keep-or-edit — Four states of one AI step, from the design file · the ask · the failed extraction with its recovery path · the wait · the review gate

Tested as a prototype, tested again before launch

The first round came early, while the MVP was still a prototype: five sellers, July 2025, walking through it before there was a product to defend.

The second round ran right before public launch — twelve moderated usability sessions during beta onboarding, with real sellers, between 25 November and 8 December 2025. Each was a recorded walkthrough of setting up their own community rather than a scripted test of ours.

Running the second round that tightly was the point: a change made after session three could be watched failing or working in session four, with a tracking sheet holding what was still open. The findings themselves belong to the company and stay there. What belongs on this page is the shape — tested at the prototype, tested again before launch, and not once in between as a formality.

The design system was the deliverable too

A new stack meant no inherited component library — the platform's existing one did not reach here — so the community product's own system and the product itself were designed together. The design file carries 132 published components across the concept, MVP and MLP pages, each a decision I made: the surfaces themselves, but also the states around them — the invite modal in its valid and invalid forms, profile in empty, valid and invalid, the plan expired, the trial expired, the product disconnected.

Three pages of the community design file zoomed out, left to right: the concept board, the MVP page with its authentication, main page and rooms sections, and the far denser MLP page with the AI onboarding sections — The design file's three eras, zoomed out: the concept board (June 2025) · the MVP (July, tested with five sellers) · the MLP (August). Zoomed out on purpose — the pace and the growth, not the contents.

Leaving on purpose

At the MLP I handed the product over and moved to customer insights full time. That was the plan from the start: the community had a system, a validated setup flow and a squad who could carry it, and the larger unsolved problem at the company was that nobody could hear what customers were saying across the whole platform.

The product kept going. The research programme on it kept going too, through waves I was no longer part of — which sets the boundary of this case: everything above is the concept, MVP and MLP era, and nothing after it is mine to claim.