Hubs

Creators were already building communities. They were building them somewhere else, then linking to them from Nestuge.

---

At a glance

Role	Product Manager. Author of the Hubs PRD, the Calendar spec, the paid group pricing spec and the Leaderboard PRD. Ran testing and QA.
Collaborators	Nelson, CTO (architecture and engineering delivery). Timi Dolor (design collaborator).
Timeline	Build start 22 August 2025 → MVP to a closed cohort 1 October 2025 → public relaunch 18 March 2026
What it is	Paid membership communities: tiered access, a social feed, a resources library of member-only courses and digital products, an events calendar, paid sub-groups, and a leaderboard
What I owned	Scope, the tier and access model, pricing rules, phasing, visual design direction, and the decision to hold the product back from general release for five months
What I did not own	Architecture and engineering delivery

---

Context

Nestuge creators sell products, courses and events. What they did not have was anywhere for the people who bought them to gather.

So they built communities elsewhere, and their audience relationship ended up split: the transaction on Nestuge, the community on a different platform, and the creator maintaining a consistent presence across both. They were also asking us for it directly, and telling us they would rather have it from Nestuge than from a dedicated community tool, because the audience and the payments were already here.

That preference is the whole opportunity, and it was also a deadline. A creator who wants this from you and cannot get it does not wait indefinitely.

---

The problem

Fragmented presence, and a request we were already receiving. Creators had no effective way to engage an audience, share content and build community inside the platform where that audience already existed. Communication scattered across multiple platforms made a consistent connection with members hard to maintain.

Worth noting because it is the third time it appears in my work: the pattern is the same one that justified our AI agent and our CRM. The job was already being done, elsewhere. Creators were using general AI tools for product ideation, exporting contacts into Mailchimp, and hosting their communities on dedicated platforms. In each case the question was not whether to build the capability but whether the platform holding the relationship would also be the platform where the work happens.

---

Stage one: the MVP, and its deliberate limits

Built between 22 August and 1 October 2025. Hub creation with branding and membership tiers, tier-based access and posting permissions, three pricing modes on hub products, email notification on publish, and hub-level analytics.

The hub is organised into sections: Community, the social feed where members and creators post and reply; Resources, where creators publish products for members, courses and other digital products, gated by tier; and Calendar, where creators schedule events and members register and attend.

The first release shipped with two of them. See decision 4.

Decision 1: release it to five to ten creators, not to everyone

At stake: how long to keep a finished product away from the people who wanted it.

The MVP shipped on 1 October to a closed cohort of five to ten creators.

The number came from Nielsen and Landauer’s model of usability problem discovery, which finds that five users surface roughly 85% of usability problems in an interface. Beyond that, added participants mostly rediscover what earlier ones already found.

The part I would defend hardest is not the number. It is the channel design. Each creator had their own tight-knit feedback channel. They sent feedback unprompted, in their own words, at the moment something bothered them, without seeing what any other creator had said.

That structure was the point. Put ten creators in a shared channel and you do not get ten signals. You get one, because the first confident voice frames the problem and everyone else agrees or stays quiet. Separate channels cost more to run and produce independent observations, which is the only kind that tells you whether a problem is real or one person’s preference. When the same complaint arrives three times from three people who could not have coordinated, you know.

What I gave up: roughly five months of general availability for a product creators were actively asking for, in a category where they had alternatives.

Decision 2: Community is text only

Posts were text, with links and emojis. Images and file uploads were blocked at the data layer, not just hidden.

The scope discipline is defensible on paper: text-only removes moderation surface, storage questions and a whole class of upload failures from a six-week build.

It did not survive contact with real communities. See stage two.

Decision 3: posts can be deleted but not edited

Feed posts in Community could be published and deleted. There was no editing.

I wrote the cost of this into the PRD’s own risks section: no editing or versioning might increase deletes and reposts. That is exactly what someone does when they spot a typo and deleting is the only tool they have. I shipped it anyway, because editing raises questions an MVP has no business answering yet. If a post can change after people have replied to it, the replies can be made to look like responses to something that was never said.

Naming the likely failure in the document is what makes it a decision rather than an oversight. It also meant that when it happened, nobody had to be convinced.

Hubs+ resolved it with a bounded window rather than by reversing it: posts can be edited within 30 minutes of posting. That is long enough to fix a typo and short enough that a conversation cannot be rewritten underneath the people in it. The answer to “should posts be editable” was neither yes nor no, it was for how long.

Decision 4: cut the calendar and ship what they were waiting for

At stake: whether to hold the release for a complete section, or ship without it.

Calendar was scoped for the initial release. It did not make it. Against the timeline we had, something was going to be late, and the question was which thing.

I asked the creators. Not in a formal study, in conversation, about what they were actually waiting to use on day one. Events were not it. What they wanted was somewhere for their members to talk and somewhere to put the things their members had paid for. Community and Resources shipped on 1 October. Calendar was specified and built from 10 October, arriving while the cohort was already using the product.

Why this matters more than it looks: the creators had been asking for hubs for a while, and the instinct under that pressure is to deliver everything you promised so the first impression is complete. Asking them what they would use first is a cheap question that reorders the whole build, and it can only be asked before you ship rather than after.

It also meant Calendar was specified against a live community rather than an imagined one, which is a better position to design an events feature from.

The related constraint: these sections were also a ceiling. Every subsequent request during the cohort period had to justify itself against Community, Resources and Calendar rather than being added beside them. The three cover what a paid community actually does, which is talk, learn and gather. A request that did not fit one of those had to argue that a hub needs a fourth kind of activity, and that is a much higher bar than arguing a feature is useful.

---

What the cohort changed

The second version was scoped 11 to 20 March 2026 and went public on 18 March 2026. Its scope is almost entirely legible as a response to five months of feedback.

Critical bugs, confined to two areas: access and payment. Those are the two things that must not be wrong in a paid community. A member who paid and cannot get in, or got in without paying, is the failure that ends the relationship. That the critical list was short and concentrated there is the clearest evidence the cohort worked.

A UI redesign, covering layout, topic tabs acting as filters, an admin’s desk, a right-hand panel surfacing upcoming events and top discussions, and the membership card. Note what those additions have in common: they are all about making a busy hub navigable. That is a problem that does not exist until a community is actually active, which is precisely what five months of real use surfaces and no amount of internal review does.

Threaded replies. Replies to posts, replies to comments, and likes on replies. The MVP had flat comments. Real conversations are not flat.

A 30-minute edit window on posts. The resolution to decision 3, and a better answer than the one I would have given if asked in the abstract.

Media upload, including video. The reversal of decision 2, on first contact with the public. A community where members can only type is not a community, it is a message board.

Groups. A new top-level menu, group listing, a join flow, and multimodal chats. The single largest addition, and it came from creators wanting subdivision inside their communities rather than one undifferentiated room.

---

Stage three: judgment after opening the doors

Three pieces of work after the public launch, each with a decision worth showing.

Decision 5: groups reuse the hub’s tiers, and never get their own

Paid groups needed pricing. The obvious approach is to give each group its own tiers.

I locked the opposite: groups do not have their own tiers. A group priced by tier keys off the member’s current hub tier, using the same pattern hub resources already used. A fixed-price group gets exactly one active plan. A tier-priced group gets exactly one plan per eligible hub tier, and duplicates for the same tier are rejected.

The reasoning is the same as a decision I made on our CRM, where I forbade segments from containing other segments. Where a hierarchy already exists, do not introduce a second one next to it. Two tier systems in one hub means every question about access has to be asked twice, and every answer has to reconcile them. One system, extended, keeps the number of states the product can be in small enough to reason about.

What I gave up: creators cannot price a group on a dimension unrelated to hub membership.

Decision 6: paying does not get you in

For private paid groups, payment and approval are separate. A member can pay before being approved, and their membership stays pending until the creator or admin approves it.

This is the sort of decision that looks like a bug if you do not state it deliberately, so it was locked and specified in full:

• Before paying, the member is told explicitly that payment does not guarantee immediate access
• After paying, they land on a success state that says the payment succeeded and the join is awaiting approval
• If they become ineligible before approval, the pending paid access is disabled
• If approval is attempted after they have become ineligible, the approval fails with a clear error

Public paid groups grant access immediately. Owners and admins bypass payment. Invited members do not.

Why the friction is correct: a private group is private because the creator chose who belongs. Letting money override that turns approval into theatre. The cost is a member who has paid and cannot yet enter, and the answer to that is not removing the rule, it is telling them before they pay.

Decision 7: force the irreversible choice into the open

When a creator changes group pricing in a way that affects existing members, the save cannot complete until they decide what happens to those members: grandfather them at the old price, or require repurchase.

The interface must state which members are affected, which action is selected, and that the choice cannot be edited afterward. The decision is then stored against that specific pricing change, permanently.

This is the decision in these documents I am most pleased with. The easy version is a setting somewhere in group configuration called “grandfather existing members,” defaulted to on, that a creator never sees. It would have been simpler to build and it would have been a trap: the consequence lands on real people who paid, months later, with no record of who chose it.

Put irreversible decisions in front of the person making them, at the moment they make them, and record the answer. A choice that cannot be undone should not be reachable by accident.

---

The leaderboard

Phase 1 shipped: a points system with default weights and daily caps, weekly and all-time leaderboards, a creator settings panel, and rank-based rewards. Later phases were scoped and deliberately held.

Decision 8: defer the parts people expect

Badges and levels were originally scoped earlier and pushed to a later phase to protect the simplicity of the MVP. They are also the two things anyone imagines first when you say “gamification,” which is exactly why they were the right things to cut.

The PRD states the reason plainly: Phase 1 exists to answer one question, does giving members a visible rank, with a meaningful reward tied to it, increase engagement? Everything else waits on the answer. Badges added in the same release would have made that question unanswerable, because a lift could be attributed to either.

Decision 9: rewards come from inside the hub

Creators reward top-ranked members with access to things that already exist in their hub: a resource, a paid event, a group, or a discounted subscription period. External rewards like gift cards were out of scope.

The constraint is the design. A reward that costs the creator nothing out of pocket is a reward every creator can actually offer, and rewards nobody uses are not a feature. It also means the reward pulls the member deeper into the hub rather than out of it.

Decision 10: a rule I shipped knowing it was unfair

When a post is reported and removed, its author loses the points from it, and everyone who commented on that thread loses their comment points too, regardless of what they wrote.

That punishes a member who commented in good faith to flag the content. I documented it as a known limitation rather than quietly shipping it, and flagged it to be raised at grooming for wider team input.

The alternative was per-comment adjudication of every removed thread, which is a moderation system, not a leaderboard rule. Given the choice between a simple rule with a known unfair edge and a fair system nobody had time to build, I took the simple rule and wrote the unfairness down.

I am not certain that was right. It is the decision here I would most want to revisit with data on how often it actually bites.

Smaller decisions

Decision	Reasoning
Weekly leaderboard resets, all-time as secondary	Prevents permanent elite lock-in; a new member can win this week
Your own rank always visible, with distance to the next milestone	“You are #24, 15 points away from Top 10” is a reason to come back; a list you are not on is not
Points weighted toward engagement received, not actions performed	Rewards being useful rather than being loud
Nothing on the page labelled “Settings” or “Profile” unqualified	Collides with hub settings and the user’s global profile. Ambiguous labels in a product with real settings elsewhere are a support ticket waiting to happen
Point weights visible to members, unobtrusively	Members should know how to earn points without being lectured on arrival
Every hub gets a default free tier	A hub with no free tier has no way in
Downgrade removes access to higher-tier content	Access must always match what the member currently pays for

---

Testing it myself

For the Calendar release I ran the test pass and logged roughly thirty findings. Most were not defects.

A sample of the judgments rather than the bugs:

• The Join button should not appear at all until an event is ready to be joined, rather than appearing disabled
• “Attend” and “Attending” should be “Register” and “Registered,” because attendance is what happens later and registration is what the button does
• Registering should raise a confirmation, and un-registering should too
• The all-day toggle should invalidate the time picker rather than sitting alongside it
• Remove the “secondly” and “minutely” repeat options, which no human event needs
• Recurring events were not listing on their recurrence, which meant recurrence needed an end date and not just a start

The bugs were found by testing. The rest were found by using it as a creator would and noticing where the product’s language did not match what the person was doing.

---

Research and theory

Informed the decisions

Heuristic evaluation of established community platforms. Structured heuristic work on Skool and Circle before and during the build. Not feature-copying, which produces a worse version of someone else’s product. The value of walking a mature product against a set of heuristics is that it shows you where a category has already settled a question, and where every player is still getting something wrong. The first tells you what not to spend invention on. The second is where the opportunity is.

This is the third case in my work where the same method preceded the build: heuristic evaluation of leading generative AI interfaces before designing our AI agent, of SendGrid and Mailchimp before the CRM, and of Skool and Circle here. It has become the thing I do before writing a spec in a category that already exists.

Nielsen, J., & Landauer, T. K. (1993). A mathematical model of the finding of usability problems. Proceedings of ACM INTERCHI ’93, 206–213. See also Nielsen, J. (2000), Why You Only Need to Test with 5 Users, Nielsen Norman Group.

The model holds that the proportion of usability problems found with n users is a function of the per-user discovery rate, and that with a typical rate of 31%, five users surface about 85% of the problems available for discovery. This is the direct basis for the cohort size.

Two caveats I want on the record, because both are checkable:

Nielsen’s own guidance is to run several rounds of five with a redesign between each, not one long round. We ran a single extended cohort over roughly five months and then rebuilt once. That is closer to continuous beta feedback than to the iterative testing the model describes, and the fit is approximate rather than exact.

And the 85% figure depends on the discovery rate. The better the interface already is, the lower that rate and the more users you need. Applying it to a first MVP, where problems were plentiful and easy to hit, is the most favourable case for the model. I would not reach for the same number on a mature product.

---

What I would do differently

The cohort answered the question it was designed to answer, and I treated it as answering a larger one.

Five to ten engaged creators, in private channels, over five months, are extremely good at finding usability and functional problems. Access bugs, payment bugs, the flatness of comments, the fact that a text-only feed is not a community. That is Nielsen’s domain and it worked exactly as advertised.

What that structure cannot tell you is whether the product works at scale or in the market. Ten friendly creators are not a sample of the public. A hub with twenty members does not behave like a hub with two thousand, and the navigation problems we fixed in the redesign, topic tabs as filters, a panel for top discussions, are the visible edge of a category of problem that only grows with size. We addressed the version of it that ten creators could show us.

I would still run the cohort. I would be clearer, at the time, about which questions it was answering and which ones remained open, and I would have planned the scaling questions as separate work rather than assuming a successful closed beta had settled them.

The smaller one: text-only Community lasted five months and was reversed at the first public release. The constraint bought a faster MVP and cost a distorted picture of how communities behave, because the cohort spent five months in a product that could not do the thing communities do. Some of what we learned in that period was learned about a product we then stopped shipping.

---

Artifacts

• Hubs PRD (redacted), including the permissions matrix, edge cases and the risks section
• Paid group pricing spec (redacted), including the locked decisions
• Leaderboard & Gamification PRD (redacted), Phase 1
• Calendar test log (redacted), the full findings list

---

Attribution: I wrote the specifications, set scope and phasing, made the access, pricing and gamification decisions, led visual design, and ran the test passes. Nelson (CTO) owned architecture and engineering delivery. Timi Dolor collaborated on design. Where this case study describes system behaviour, it describes the behaviour I specified, not its implementation.