How it works

We decide in ten days and tell you why.

The MeYouSocial operating model in one page: the loop from a member’s problem to a shipped change, the commitments we publish, the guardrails that keep the products from becoming the sum of every request, and the numbers that say whether any of it is true.

Read the changelog


The loop

Six stages. Each has an artifact members can see and a time commitment the company publishes.

Stage What happens What members see Commitment
Request A member posts a problem in the product’s category. The AI team asks clarifying questions in the thread within hours. The thread, the questions, the answers First response within one business day
Decision The steward reads the thread and the usage evidence and marks it Under review, Planned, or Declined with a reason. The status and the reason, in public Decision within ten business days
Build The AI team implements the change in a branch behind a flag. A build log: what was read, what was written, what was run Started within the published sprint
Verify Automated regression, layout, accessibility and data-consistency checks, then a small member testing cohort. The check results and the testers’ notes No release without a passing check
Ship Flag on for testers, then for everyone. The changelog entry names the member who raised the problem. The changelog, the help article, the flag Weekly release window
Tell A short changelog video and a monthly community call walk through what changed and why. The video, the call, the recording Weekly video, monthly call

1 · Request

Post a problem, not a feature, in the product’s category. The AI team asks clarifying questions in the thread within hours. First response within one business day.

2 · Decision

The steward reads the thread and the usage evidence and marks it Under review, Planned or Declined, with the reason, in public. Decision within ten business days.

3 · Build

The AI team implements the change in a branch behind a flag. You can read the build log: what was read, what was written, what was run.

4 · Verify

Automated regression, layout, accessibility and data-consistency checks, then a small member testing cohort. No release without a passing check.

5 · Ship

Flag on for testers, then for everyone, in the weekly release window. The changelog entry names the member who raised the problem.

6 · Tell

A short changelog video every week and a community call every month walk through what changed and why.

Declines are published with reasons.

A community that only sees acceptances learns nothing about the product’s direction and assumes the silence means nobody read the request. A community that sees “Declined: this would make Velocity a helpdesk, and it is a revenue tool” understands what the product is.

The changelog names the member.

Credit is the cheapest and most durable reward a community can offer, and it turns a changelog from a list of fixes into a record of the community’s influence.


Product charters

Every product carries a one-page charter that the steward maintains and the community can read. A request that fits the charter gets built quickly. A request that breaks it gets a public, reasoned decline.

1 · What it is for

One sentence.

2 · Who it is for

The practitioner it serves and the practitioner it does not.

3 · What it will never become

The three or four adjacent products it will refuse to turn into.

4 · The opinions it holds

The defaults it will not remove even if asked.

Guardrails

Five failure modes, and what stands in front of each.

Against bloat

The charter is the guardrail. Every accepted request cites the charter line it serves. Once a quarter the steward reviews usage and proposes removals, and removals get changelog entries like additions.

Against fragility

The Velocity test report from August is what fast building without verification looks like: data that disagrees across modules, a critical send path unguarded, a mobile layout that does not work. The verification stage exists so that never happens to a community-shipped change. Regression, layout, accessibility and data-consistency checks run on every build. Releases go behind flags. Rollback is one action.

Against capture

A vocal minority can dominate any queue. Decisions weigh usage evidence alongside thread volume, and the steward’s reasoning is public. A decision that cannot be explained in a sentence is not made.

Against over-promising

The commitments in the loop table are the only promises. The site never says “we build whatever you ask.” It says “we decide in ten days and tell you why.”

Against the vibe-coded objection

Sceptical buyers hear “AI dev team” as “nobody qualified is watching.” The answer is evidence, not argument: published test reports, the verification log on every change, security and data-handling documentation, and a human release gate.

Usage intelligence with consent

Telemetry is a shared instrument, or it is surveillance. The difference is whether members chose it.

Opt-in, per workspace, with a plain list of what is collected.

Aggregate only. No member’s content, contacts, keys or money is ever part of it.

Published findings, in the same form the stewards see them: “Forty percent of Velocity workspaces never open Forecast. Here is what we are doing about it.”

Linked from the changelog. Every analysis that led to a change is linked from the entry, so members can see what their usage taught the product.


The scorecard

Four headline numbers, published monthly on the site, from the first month. If they are good, the concept is true. If they are bad, the concept is a slogan, and the numbers will say that first.

Number Why it matters
Median time from request to decision Proves someone is reading
Median time from decision to ship Proves the AI team is real
Changes shipped this month Proves cadence
Share of changes that came from members Proves the community steers

Supporting numbers for the stewards, published quarterly: regressions per release, rollbacks, time to first response in the community, and the number of declines with reasons.


How it compares

The rare combination is the last column read top to bottom.

Traditional SaaS Open source Agency or custom build No-code platforms Member-evolved
Who decides what gets built Product management Maintainers and contributors The client The user, within the platform’s limits Practitioner stewards, from member problems
Who builds it Engineering team Volunteers and sponsors The agency The user AI development team, human gate
Request to ship Quarters Varies widely Weeks to months, paid Immediate, limited Days, verified
Visibility of the process Roadmap page at best Full, if you read code Private None needed Public loop, build log, scorecard
Who owns the data and keys The vendor The user Depends on contract The platform The member
What the money funds Access and usage Donations or support The build Seats The evolution of the product

The first ninety days

The model needs proof before it needs scale. This is the order we are running it in.

  1. Recruit a founding cohort. Twenty to fifty practitioners who already use at least one product. Founding tier, named on the site.
  2. Pick one problem per product. Four real problems from the cohort, each fitting its charter.
  3. Run the loop in public. Request thread, decision with reasoning, build log, verification results, flagged release, changelog with the member’s name, changelog video.
  4. Publish the scorecard from month one, even when the numbers are small. Four changes shipped from four member problems in a month is a true story.
  5. Hold the first community call with the stewards walking through what shipped and what was declined.
  6. Write the charters with the cohort and publish them.
  7. Only then open the community to everyone. New members arrive to a loop that has already run, with evidence on the wall.

Have a problem worth solving?

Post it in the community. Say what it costs you, not what to build.

Membership and pricing