Sign in
Let them cook.
I built this because coding agents got ridiculously good at writing code, and I got tired of teaching every new one how I actually build a consumer app. Onboarding. Paywalls. Activation. App Review. Launch. All the stuff around the code that still decides whether the app is any good.
So I wrote it down. It got a little out of hand.
Hosted gives your agent my maintained workflows and sourced references, kept current. The open-source version is the same system under the MIT licence, free to run on your own setup. Your model usage, repo access, and whatever your app runs on stay yours.
I keep running into questions the SDK docs cannot answer. What should count as first value? Is the paywall too early? What does activation mean for this app? What am I about to forget before launch? This is the kind of review I want back.
The example below is mine, not a customer result or a cherry-picked agent run. I’m showing the shape of the work so you can decide whether it is useful before paying me.
Use B2C App Builder to review this app’s onboarding. Inspect the existing project and relevant guidance before recommending changes. Identify first value, activation, paywall timing, the biggest gaps, and the checks needed to verify the recommendation.
Loading a workflow does not magically make the answer right. I expect the agent to inspect the project, separate facts from guesses, and show its work.
Current screens, events, purchase boundaries, and behavior verified in the project.
Anything the project cannot prove gets called out instead of quietly becoming a “fact.”
Find the moment the user gets the thing they came for, before asking them to judge an upgrade.
Tie activation to that useful result instead of account creation because it happens to be easy to measure.
Put the upgrade ask at the intended value boundary, then check that against the actual access model and economics.
Call out missing evidence, questionable paywall timing, unproven events, and recovery paths nobody has tested yet.
Trace a first session, prove the activation event fires on success, verify the paywall appears where intended, then test back, retry, restore-purchase, and interrupted states.
My brother Alejandro is an English professor. He used B2C App Builder, with help from me, to build Phoneme and get it onto iOS, Android, and the web.
He is my brother, so I’m not going to dress this up as some independent customer case study. But it was a pretty good test of whether the system made sense outside my own head.
See what he built ↗I use the same system from the first dumb idea through the annoying parts of running a live app. Start wherever your app is right now.
Figure out what you actually believe, what would kill the idea, and what is worth validating before you disappear into the codebase for a month.
Review onboarding, monetization, launch readiness, or the thing your agent confidently implemented before anybody asked whether it was a good idea.
Dig into activation, retention, experiments, store problems, or whatever is currently making you stare at a dashboard and swear.
I keep the workflows and references available to your agent and maintain the knowledge behind them.
Your coding agent, project access, model bill, infrastructure, judgment, and the final call on what ships.
After building Clueless, Ocho, Banded, and enough half-finished experiments to know better, I kept running into the same work. Research the market. Figure out onboarding. Decide what activation actually means. Wire subscriptions without making a mess. Survive App Review. Launch. Measure what happened. Fix what broke. A coding agent can nail the implementation and still have no idea whether the thing it just implemented was a good product decision. I stopped organizing my guidance around features and started organizing it around the jobs that show up in basically every consumer app I build.
Tickets in, plates out. Nothing leaves unchecked.
The chef's station. Every ticket starts here, and every plate is checked here before it goes out.
From menu planning to the plate. What you serve, how it feels, how it reads.
The ticket lands here first. Menu planning, the prep table, the walk-in.
Build, prove, sign, package, submit.
Prep comes down from the kitchen; the finished dish goes back up to the pass.
The register, the door, and the covers count.
Plates leave here for the business, and the covers count comes back to the pass.
Founder access, accounts, licenses, the health-code binder. Menu planning starts here.
Off the line, behind the kitchen. No ticket passes through here, and nothing opens without it.
Sharpen the knives, calibrate the ovens, keep the sources honest.
Off the line, between services. Nothing here goes on a plate, and every plate depends on it.
The contributors' station. The people who build the kitchen keep it sharp, and every chef who runs it gets the technique.
This is why the kitchen metaphor survived. A feature is one plate. Building the business means deciding who owns each kind of work, what they should know before they start, and what gets checked before anything leaves the pass. Once that is written down, I can stop hovering over every prompt and let the agents cook.
Most agent demos jump from prompt to shiny answer. I care a lot about the middle, because the middle is where an agent reads the wrong thing, skips a dependency, invents a requirement, or decides it is done because the prose sounds convincing. This is a founder request from 6 September 2026, routed through B2C App Builder as written. I trimmed the trace for length; the values themselves are unchanged.
We're three weeks from submitting our iOS habit-tracking app. Before I write the onboarding screens, define what first value and activation mean for this app and tell me where the paywall goes.
"Onboarding ONB-10: first value and activation" best matches what you asked for, sharing terms: onboard, define, first. It scored clearly ahead of every other workflow, so it is returned as the one recommendation.
artifact-contracts, launch-phases, launch-coverage. Open "Onboarding ONB-10: first value and activation" and follow it — you can skip the extra reference material listed alongside it unless the work actually needs it.
product/onboarding/graph/ONB-09-evidence-join.md first.Separately define first value rendered (the real, personalized result the user sees), first value engaged (the meaningful action they take on it), activation (the retention hypothesis and its derived condition), habit signal, monetization, review eligibility, and onboarding completion — first value must be real, actionable, persistent, recoverable, and visible inside the populated normal product experience, not a canned demo. Write the milestones to product/onboarding/graph/ONB-10-first-value-activation.md; check:onboarding-evidence-onb-10 rejects a stub packet, and ONB-15's architecture decision depends on these being real, distinct milestones.
Required guidance was truncated. Follow coverage.incomplete before the work.
product/onboarding/graph/ONB-10-first-value-activation.mdb2c check onboarding-evidence-onb-10 --workspace <registered-workspace> --json Deterministic. Fails closed.Some outputs do not yet have an indexed artifact specification; do not infer acceptance from file existence.
A workflow pass is not a business-completion verdict. Use the selected workspace plan for executable next work.
Pass the check, or the work stays pending.
This trace deliberately stops before the final onboarding recommendation. I built the part you
see here: decide where the work belongs, load the right context, respect dependencies, say what
needs to be produced, and make the agent prove the work before it counts. The agent still has to
do the actual product work. This was read through b2c_plan and b2c_workflow,
engine 0.214.0. I left out ids, hashes, and the full reference cart because nobody
needs that much mise en place on a landing page.
I publish every title because you should be able to see the shape of the thing before paying for it. These counts come from the live catalog as of 6 September 2026. Hosted access includes the workflow bodies and 140 sourced references behind them.
is this idea even worth pursuingroutes to Consumer app opportunity and product research
decide what activation actually means for this approutes to Onboarding ONB-10: first value and activation
design how every screen in the app looks and feelsroutes to Design Room
set up subscriptions and pricingroutes to Revenue monetization
get the ios build signed and to testersroutes to Apple signing & release readiness
make sure this can't be hacked before we shiproutes to Security architecture & release gate
write our privacy policy and terms of serviceroutes to Privacy & terms
make demo videos from our real app screensroutes to Content assets / Remotion / generated visuals
These are the catalog’s trigger phrasings, quoted as written. Talk to the agent like a founder, not like a router.
I built this to sit inside the tools I was already using. Claude Code, Codex, Cursor, or plain HTTP. Pick the one you actually use, paste the snippet, and get back to the app.
Google sign-in opens the console. Hosted is $19 a month or $190 a year, billed by Stripe. Cancel any time.
You see it once. Revoke it and make another whenever you want.
Claude Code, Codex, Cursor, or plain HTTP. Paste the snippet and get back to building.
claude mcp add --transport http b2c-app-builder https://mcp.clueless-creations.com/mcpRun /mcp inside Claude Code and choose the server to authorize. The authorization page asks for your API key once, then gives Claude Code its own revocable connection.
codex mcp add b2c-hosted --url https://mcp.clueless-creations.com/mcp --oauth-client-registration dcr
codex mcp login b2c-hosted --scopes b2c:read --oauth-client-registration dcrThe authorization page asks for your API key once and gives Codex a separate revocable connection. Codex never gets the key itself.
{ "mcpServers": { "b2c-app-builder": { "url": "https://mcp.clueless-creations.com/mcp" } } }Add this to ~/.cursor/mcp.json or the project’s .cursor/mcp.json, then approve the connection from Cursor settings when it asks.
curl https://mcp.clueless-creations.com/api/v1/catalog \
-H "Authorization: Bearer <your API key>"Same catalog, same workflows, plain web request at https://mcp.clueless-creations.com/api/v1. Use the API key from the console.
Hosted access gives your agent workflows and references. It cannot read your files or repository, run anything on your machine, or store your project data. I do not keep a log of what you or your agents ask. References include their sources and last-reviewed dates, and responses identify the edition they came from. The boring-but-important version is in the Terms.
I use tools like Context7 too. They're great when an agent needs to know how a library works. I built B2C App Builder for the questions I kept answering myself: what should activation mean, is this paywall way too early, what purchase states did we forget, what will App Review care about, what should we measure after launch? They work well together.
Yep. Every one of the 111 workflow titles is on this page, grouped the same way I use them, and the ticket above is a real trace through the system. I want you to be able to decide whether I have anything useful to say before you give me $19. The full workflow bodies and 140 references are in hosted access.
No. This is the system I use, packaged so your agents can use it too. You still make the product calls and ship the app. If you want me in the room helping with the product or launch, I do that separately. Here are the ways I work with people.
It can't see your machine, files, repository, or project data. It returns workflows and references when your agent asks for them. I also don't keep a log of the questions you or your agents send it.
Because I don't want my way of building apps to turn into scripture. If another builder has a better onboarding loop, App Review checklist, subscription practice, or launch process, I want that improvement in the system. The code is at https://github.com/Clueless-Creations/b2c-app-builder. Hosted access saves you from maintaining the knowledge service yourself.
Run the open-source version yourself for free. Hosted access is $19 a month or $190 a year, billed by Stripe. Sign in, choose monthly or annual, create a key, connect your agent.
Alejandro is my brother, and I helped him along the way, so I am not pretending this is an independent customer case study. He is also an English professor who started with a clear product idea and no software-development experience. These are his words about building Phoneme.
As an English teacher, I had a clear vision for a pronunciation app, but no experience with software development or launching a commercial product. What I needed wasn’t just AI to generate code, I needed a process. This framework gave me exactly that. It walked me through planning, technical setup and launch, so I could spend my time on the learning experience, not on trying to learn full stack development from scratch. The result is Phoneme, live on web, iOS, and Android. I think it’s clear that with the right structure, domain experts can bring serious products to life.
Phoneme is live on the web, iOS, and Android. The part of his quote I keep coming back to is simple: domain experts already have the scarce knowledge. The process should help them turn it into a real product.
The same approach, with Eduardo working beside you.
Focused counsel, a product sprint, or a build and launch we run together, with someone beside you who has shipped this way before.
Start a projectHosted is $19 a month or $190 a year. Or grab the open-source version and run it yourself. Either way, I hope it saves you a few hundred rounds of explaining to an agent why the paywall should not be on screen two.
By signing in you agree to the Terms of Service and Privacy Policy.