8 Tests, 2 Blockers, 0 Projects Created
I ran DreamSparrow's first-project flow eight times with Menso. None of the eight included runs created a project.
DreamSparrow is a project-management product for builders. I'm building Menso to find friction in live product flows with synthetic target users. Menso gives an AI user a target persona and task. The user operates the product in a browser while Menso records the replay and its decisions, then turns that evidence into a prioritized friction report.
For this test, the user was Sam Rivera, an operations lead. His task was:
Create a product-launch project, open it, and add “Draft announcement post.”
I kept the persona and task fixed. One run exposed a circular setup path. Seven surfaced the same project-creation error.
Blocker 1: The empty workspace had no valid first step
The Create Project form required a team, but the workspace had none. The form showed:
No teams available. Create a team first.
Sam followed that instruction. The Team page then showed:
Create a project first — then you can invite members and manage roles.
Each page pointed to the other. In that empty workspace, Sam could not satisfy either prerequisite.
Blocker 2: The form accepted the input, then the account failed at submit
In seven clean follow-up runs, a team was available. Sam entered the project name, selected the team, and reached an enabled Create button.
All seven follow-up runs eventually surfaced the same error:
new row violates row-level security policy for table "projects"
In the longest run, the interface labeled Sam as workspace Owner and team Lead. The same error then appeared through several visible project-creation entry points.
The replay does not expose DreamSparrow's backend policy, so I can't name the root cause. It does show that the interface's role labels and the create result conflict.
What worked
The project form gave Sam clear field labels, exposed the team requirement, and enabled Create after the required inputs were present. The error also remained visible in the form. Those details made the failure easy to reproduce and document.
What I would change first
- Give a new account one valid starting point. Create a personal team by default, or make team creation the only empty-workspace action.
- Check project-creation permission when the user enters the flow. Do not wait until the completed form reaches the database.
- Replace the database-policy message with an account-specific explanation and recovery action.
- Track successful first-project creation by account state. A signup or enabled Create button does not prove activation.
Sam completed every visible requirement before the product rejected the project. A pre-submit validation could surface the problem earlier and give the user a recovery step.
Scope of this test
These were eight synthetic runs using the same operations-lead persona, captured from July 23 to July 26, 2026. They are not eight human users or population statistics.
We excluded a ninth run because its later steps contained automation input anomalies. No included run reached task creation, so this report makes no claim about the downstream project workflow. DreamSparrow may also have changed since capture.
If you owned this flow, which would you fix first: the empty-workspace model or the permission preflight?
I'm using August to test Menso's paid model: $9.90 for one synthetic-user test of a core flow in your live product. I'll deliver the replay, screenshots, and prioritized friction report within 24 hours. If you want me to test yours next, DM me the link and one task a new user should complete.
