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. The colour of a stage follows it through the queue, the build log and the changelog.

The six-stage loop from a member problem to a shipped change: Request, Decision, Build, Verify, Ship, Tell, then again every week
Request stage icon

Stage 1

Request

A member posts a problem in the product’s category. The AI team asks its clarifying questions in the thread within hours.

What you see

The thread, the questions, the answers

We commit

First response within one business day

Decision stage icon

Stage 2

Decision

The steward reads the thread and the usage evidence and marks it Under review, Planned or Declined, with the reason.

What you see

The status and the reason, in public

We commit

Decision within ten business days

Build stage icon

Stage 3

Build

The AI team implements the change in a branch behind a flag.

What you see

A build log: what was read, what was written, what was run

We commit

Started within the published sprint

Verify stage icon

Stage 4

Verify

Automated regression, layout, accessibility and data-consistency checks, then a small member testing cohort.

What you see

The check results and the testers’ notes

We commit

No release without a passing check

Ship stage icon

Stage 5

Ship

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

What you see

The changelog, the help article, the flag

We commit

Weekly release window

Tell stage icon

Stage 6

Tell

A short changelog video and a monthly community call walk through what changed and why.

What you see

The video, the call, the recording

We commit

Weekly video, monthly call


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. Up 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