Nine. That’s how many revisions BJJ.onl needed after its first working delivery.
Not nine prompts. Nine separate, named requirements, each one worked through a defined loop after the app was already live and doing its job. If you’re evaluating an AI builder and wondering what happens after the demo, here’s what that looked like on BJJ.onl: a real list, with real items on it, resolved one at a time.
What “first working delivery” meant
BJJ.onl is a training diary for jiu-jitsu practitioners: log sessions, track technique, record belt promotions. TalkIDE built it. It’s live on its own domain: bjj.onl for the landing page, app.bjj.onl for the product, with GA4 wired across both. That build is documented in How We Built BJJ.onl With TalkIDE.
The first delivery wasn’t a click-through demo. It was a working app. Accounts, sessions, techniques, goals and navigation were all functioning, and it already had a multi-profile system, event-sourced belt-promotion history and a coach-access permission model reviewed by Security before shipping. That’s the detail that matters here. You can’t file “the Add button is the wrong color” against a mockup. You file it against something a user is actually trying to use.
That’s also why the list below reads the way it does. It’s not architecture feedback. It’s the feedback a real product gets in its first week.
The loop: state the requirement, re-plan, implement, QA-verify
Every one of the nine items ran the same four steps, in this order:
- State the requirement. The client says what’s wrong, in their own words, no ticket template required.
- Re-plan. Mara, the PM agent, updates the implementation plan against the new requirement.
- Implement. The team makes the change.
- QA-verify. QA checks the change against the plan before it ships again.
No step got skipped because an item looked small. A button color runs the same four steps as a backend bug.
The list, as the client actually wrote it
Here’s what came back after the first delivery, unedited:
- In navigation, Log session must be the first item, then Sessions.
- In Techniques, the form to log a technique has a strange dashed border. Remove it.
- Goals: the listed goals have the actions edit, mark achieved and remove. Add a check icon for Mark as achieved, and move edit and remove under a three dots icon.
- Goals: the Add button is green. It must be the same red as every other action button.
- My profile is built for mobile only. It does not adjust to bigger screens the way every other page does.
- Create account must contain Full name, email and password. No confirm password.
- App name is BJJ.onl and it will run on that domain later.
- Profiles: I cannot add a profile, it throws a backend error.
- On big screens the belt and name show at the bottom of navigation. This must follow the mobile view: name first, then belt below the name. Also remove the label on the belt, same as on mobile. This must be the same component everywhere, including Profile and Profiles.
No product manager wrote that list to sound tidy. It sounds like a person clicking around their own app and writing down what bothered them, because that’s what it is.
One item, traced end to end
Take item 4. “The Add button is green. It must be the same red as every other action button.”
State the requirement: the client names the exact inconsistency: one button, one color, wrong.
Re-plan: Mara updates the plan against that requirement. A one-word note like “must be the same red” still has to be checked against how the rest of the button styling is built before anyone touches code.
Implement: the team makes the change.
QA-verify: QA checks the result against every other action button on the page, not just the one the client mentioned.
That’s four steps for one color. It’s also the difference between a fix and a fix that produces the same complaint again.
Item 8, the backend profile-creation bug, ran the identical loop. Stated, re-planned, implemented, verified. The loop doesn’t change shape for a styling note versus a 500 error. Only the work inside each step does.
Why nine gets published instead of rounded off
BJJ.onl’s nine is a high number to put on your own page. We’re putting it there anyway.
A page that says “revisions are part of the process” and stops there is telling you nothing. A page that names the project, gives the actual number and shows the actual list is telling you what happened on one real build. That’s the whole difference between a claim and a record.
BJJ.onl’s nine revisions aren’t a sign the first delivery missed. They’re a sign someone was actually using the app and writing down what was wrong with it, and that every single note got tracked through to a verified fix instead of getting lost in a chat thread. A team that can hand you that list, for that project, is a team that knows what changed and why.
Where some of this gets caught earlier
Not every requirement has to surface after delivery. Some of it gets caught before a line of code exists.
On the Business side, Vera runs the requirements conversation with the client directly, before any build starts. She asks the questions that would otherwise turn into a revision later, like whether a belt change is an edit or a permanent event. Once that’s approved, the plan hands off to Mara’s team, where Iris, the Analyst, turns it into testable requirements before any code is written.
That earlier stage doesn’t replace the revision loop. It shrinks what’s left for it to catch. Some of BJJ.onl’s nine were things an earlier conversation would have caught; most of BJJ.onl’s nine were things nobody sees until they’re clicking through a real app.
See how a project gets scoped
If you want to see how the requirements conversation works before your client is the one asking for revision nine, start there.