How We Built BJJ.onl With TalkIDE

BJJ.onl is a training diary for jiu-jitsu practitioners: log your sessions and techniques, set goals and record every belt promotion.

It was built the same way every product we ship on TalkIDE gets built: a conversation with a product agent, a clickable mock, a handoff to an engineering plan, then rounds of delivery, testing and new requirements until it was live on its own domain.

No tickets written by hand. No design files thrown over a wall. Just a team of agents that stayed on the job.

Step 1: Talking it out with Vera

Every build starts with Vera. You don’t write a spec for her, you talk to her.

For BJJ.onl, the opening was roughly: “I want a training diary for jiu-jitsu. People log what they train, and it should notice what they’re neglecting.”

What Vera does with that is the part people underestimate. She asks the questions a good product person asks before anyone writes code:

• What happens when a parent tracks a kid’s training, and then that kid wants their own account?
• When someone changes their belt, is that an edit or an event?
• Does a coach need to edit a trainee’s diary, or only read it?

Those three questions alone shaped the product. Belt changes became promotions with a permanent timeline, not a field you overwrite. Managed profiles got a one-way “graduate into your own account” path. Coach access became strictly read-only with revoke.

By the end of the conversation, Remy, our mockup designer, had produced a clickable mock, not a document. Otto, our maintainer, deployed it live. Real screens, real navigation, real flows you can walk through yourself and react to.

That’s where the disagreements happen, and that’s the cheapest possible place to have them. We moved the AI advice off its own buried screen and surfaced the top suggestion on the dashboard, because clicking through the mock made it obvious nobody would go looking for it. That change cost one sentence. After a build, it would have cost a sprint.

The scope that came out of the mock:

• Account and profile management, multi-profile, promotion history, profile graduation
• Session logging: date, duration, Gi/No-Gi, class type, notes, intensity
• Technique logging across the 10 standard categories
• Goals: preset or custom, active vs. achieved
• AI coaching: coverage gaps, consistency nudges, goal-focused suggestions (the interface is live in BJJ.onl, but it is in an empty state and does not yet generate real advice)
• Home dashboard: recent sessions, streak signal, top suggestion
• Read-only coach access by invite

Step 2: The handoff to Mara

This is the part that makes TalkIDE different from a prompt-to-app tool.

Vera doesn’t build. When the mock is right, she hands off to Mara, our PM agent, and Mara turns the approved mock into an actual plan of work: data model, screen-by-screen implementation detail, sequencing and what each specialist agent picks up.

Mara is also the one who pushes back. She flagged that “mark a goal achieved” needed to be irreversible with an automatic achieved-date, otherwise the goal history would become meaningless. She scoped the AI advice as three concrete rule families rather than an open-ended “give advice” prompt, so it could actually be tested.

From there the team ran:

• Designer turned the mock into a real system
• Engineer built the schema, the API and the screens
• QA tested against the plan and the mock, not against vibes
• DevOps stood up the environments
• Security reviewed the coach-access permission boundary before it shipped

Step 3: Delivered, tested, revised

The first delivery was a working app, not a demo. Which meant the feedback was real feedback.

A few adjustments that need to be done before AI insights:

1. In navigation, Log session must be the first item, then Sessions.
2. In Techniques, the form to log a technique has a strange dashed border. Remove it.
3. 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.
4. Goals: the Add button is green. It must be the same red as every other action button.
5. My profile is built for mobile only. It does not adjust to bigger screens the way every other page does.
6. Create account must contain Full name, email and password. No confirm password.
7. App name is BJJ.onl and it will run on that domain later.
8. Profiles: I cannot add a profile, it throws a backend error.
9. 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.

Each of those went back through the same loop: state the requirement, Mara re-plans, the team implements, QA verifies. Small requirements land in a single pass. Nothing needed a rewrite, because the data model came out of a conversation that had already asked the hard questions.

Step 4: Domain and production

bjj.onl for the landing page, app.bjj.onl for the product. DevOps attached the domain, provisioned the production environment, wired GA4 across both subdomains so acquisition and in-app conversion sit in one funnel and shipped it.

Hands-on human time: 1 to 2 hours (the builds themselves ran longer, but unattended in the background, so that time isn’t counted here). Total cost: ~$592 in credits, broken down by deliverable:

• Landing page mock: $29
• Landing page build: $73
• App mock: $74
• App build: $416

The mock is cheap. The build is where the money goes, which is exactly why it pays to get the mock right first.

Step 5: And then again, and again

A product isn’t done when it launches, and this is where the workflow really pays off. Each new round of features runs the identical loop:

• Round 2 (AI coaching): back to Vera for the requirements conversation, Remy mocked the advice cards, handoff to Mara, three rule families implemented and tested. The interface is live in BJJ.onl, but it sits in an empty state and does not yet generate real advice.
• Round 3 (coach access): roster, invite, accept, revoke. Security reviewed the boundary again because the permission surface changed.
• Round 4 (landing page): built around the belt-progression motif, converted to SSG for SEO. See the mock.

The agents remember the product. Round four doesn’t start from zero.

What this actually proves

BJJ.onl isn’t a to-do app someone generated in a browser tab. It’s a multi-profile system with an event-sourced promotion history, a permission model and a public marketing site.

Other tools hand you a code generator. TalkIDE hands you a team: a product agent who asks the awkward questions before you’re committed, a PM who turns agreement into a plan and specialists who execute it and test it.

And you own the whole thing. Full-stack code, your repo, your infrastructure, your domain.

Want to see it? BJJ.onl is live. If you have a product like this in your head, start with a conversation: talkide.app ($10 in credits gets you far enough to feel how the workflow runs).