James Nocode, a YouTube creator who builds and reviews AI development tools, published a full end-to-end build to demonstrate the stack he's settled on for 2026. The subject of the video is the stack itself, not the app: three tools with clear boundaries, one agent driving all of them.
The app he uses to demonstrate it is Creator Circle — a gated community where members request access, take courses and lessons, track progress, and post in discussions, with an admin view that approves or revokes membership. It's a vehicle for showing how the pieces connect, and it's deliberately a shape that can't be faked with a frontend alone.
Three tools, three jobs
- Codex (GPT-5.6) — the only agent in the build. It plans, writes the React and TypeScript frontend, and provisions the backend. Everything else is a tool it operates rather than a service the builder wires up by hand.
- Momen — a managed visual backend, consumed over its auto-generated GraphQL API. Codex builds inside it through the Momen no-code plugin; the result stays open in the Momen editor afterward.
- Google Stitch — interface design from a prompt. James is direct about why it's in the stack: Codex is improving at UI but still isn't as good as a dedicated design tool, so Stitch produces the screens and Codex imports them.
His framing for the division of labor: Codex builds every layer, Momen stays visual, Stitch shapes the UI. Backend first, because the backend is the source of truth the frontend has to match — a point Momen has made in Why Backend Structure Always Matters.
Four documents before a single line of app code
The most transferable part of the video isn't the tooling, it's how much James writes down before building. Four planning passes, each in plan mode so Codex can ask clarifying questions, and each explicitly instructed not to install or build anything:
- V1 scope — member and admin roles, gated community, courses and lessons, progress tracking, discussions, one admin access view, plus an explicit list of what's being left out. His reasoning: Creator Circle could balloon into a full course-platform competitor, so the boundary gets fixed first.
- Product spec — screen list and user flows, saved into the repo as a file so a later agent or developer can read what is and isn't in scope.
- Backend plan — the entities and relationships in plain English, reviewed and saved before anything is provisioned.
- Repo instructions — an AGENTS.md and spec.md covering how to run the app, how to re-read the Momen backend after a change, and the hard rule that no admin token ever reaches the client.
He calls that last step harness engineering: files that exist for the agent's benefit, so it stays consistent across a long build. The pattern is the counter-argument to one-shot prompting, which Momen has written about in Stop Prompting, Start Architecting.
Paying for reasoning only where it changes the outcome
Codex exposes three model tiers, and James switches between them deliberately rather than staying on the strongest one:
- Top tier, high effort — for the four planning passes and for provisioning the Momen backend, where a wrong architectural call is expensive to undo later
- Balanced tier, medium effort — for most implementation work, including the Stitch import and fleshing out screens
- Cheapest tier — for the initial React scaffold and other boilerplate
His rule of thumb is that anything architectural gets the strongest model, and everything downstream of a locked decision does not.
What the plugin gives the agent that it would otherwise invent
This is the part of the stack that does the most work, and James spends real time on why. Without a plugin, a coding agent guesses at the shape of your API from context. The Momen plugin replaces the guess with three things:
- A Momen platform skill — the interface through which Codex builds and operates a Momen project: creating tables, configuring relations, setting up auth, adding Actionflows. Not just reading an existing schema.
- A Momen MCP command-line tool — handles execution: table creation, schema code generation, GraphQL operations, Actionflow calls. Codex drives this rather than calling Momen's APIs directly.
- Session-start schema loading — the agent reads the current backend state before the first prompt, so frontend code references real fields from the beginning.
Setup is a marketplace install plus a browser login that returns a token, then pasting the Momen project URL into the prompt so the plugin knows which project to operate on. The step-by-step setup for Codex covers the same flow in writing.
The backend Codex provisioned, watched live
James keeps the Momen editor open while Codex works, and the build appears in it as it goes. What the video shows landing in the project:
- Momen's built-in account table plus seven application tables — community, membership, course, lesson, lesson progress, post, comment — with the one-to-many relationships between them
- Membership as a row, not a role — community access is represented by a membership record rather than creating a separate Momen permission role per community, so joining never grants access automatically. States are requested, active, and removed.
- Four Actionflows — Join community, Mark lesson complete, Grant or remove access, and a Creator Circle Gateway, each with typed inputs, execution nodes, and bound return fields
- Permissions per role, table, column, and operation — direct table writes default to deny, preserving scoped reads and author-owned discussion edits; Actionflow access is also scoped by role, so the non-logged-in role can reach almost nothing
- Email-and-password sign-in only, with the other default methods disabled to avoid duplicate account identities
- Seed data — five demo accounts, one published community, two courses, seven ordered lessons, and memberships covering every state, so the frontend has something real to render
The point James returns to is that none of it is opaque. The tables, flows, and permission rules are all sitting in the editor afterward, inspectable and editable by hand or by another agent — which is not true of a backend an agent scaffolds into code you then own outright.
Wiring the frontend one slice at a time
Rather than connecting the whole UI at once, James builds the interface against local mock data first — including mock sign-in personas so role-gated screens can be demonstrated — then replaces the mocks slice by slice:
- Momen auth plus the member dashboard
- Community discovery and joining, through the Join community Actionflow
- Courses, lessons, progress marking, and discussions
- The admin access view and end-to-end verification
Each slice goes all the way down — API call, UI, states — before the next one starts. Deployment is the last step, to Vercel through Codex, since the frontend lives outside Momen and so doesn't use Momen's own one-click deploy.
How Momen charges for a backend like this
Momen prices per project per month, and every plan includes a baseline of resources rather than metering from zero:
- Free — $0. The full visual builder, one API, one Actionflow, one AI agent, and publishing on a Momen subdomain. Enough to build and explore.
- Basic — $33/project/month billed annually, $39 monthly. Unlimited APIs, Actionflows, and AI agents, a custom domain, white labeling, and SEO controls.
- Pro — $85/project/month billed annually, $99 monthly. Adds Stripe payments, single sign-on, multiple frontends on one backend, more collaborators, and higher throughput.
For a project shaped like Creator Circle, the binding constraint is the Actionflow count, not storage: four flows is past the Free plan's single Actionflow, so Basic is the realistic entry point. There are no payments in this build, so nothing here requires Pro. Frontend hosting on Vercel is free at this scale. Full details are on Momen's pricing page.
James walks through the entire build — the four planning passes, the Stitch handoff, Codex provisioning the Momen backend live in the editor, and each frontend slice — in his video.
To try the same split: install the Momen plugin in your coding agent, write the scope and backend plan down before building, let the agent provision the backend first, and only then point it at the frontend.
