Starter and Workers are different jobs

Product split

Starter and Workers are different jobs

One path starts from an idea. The other starts from an existing repo. They should not be forced through the same page, price, or promise.

Ship by Sunday is splitting around the moment a builder is actually in.

If you have an idea, a Lovable-style prototype, or a pile of prompts, you need a starter path. You need product truth, a generated repo, guided videos, setup docs, and a way to keep AI tools working from the same source of truth.

If you already have a repo, you need a worker path. You do not need another starter. You need a private diagnosis, ranked findings, boundaries, source truth, one approved worker loop, and proof that the loop either worked or hit a real blocker.

Starter starts before the repo is real

Starter is for zero-to-one builders. The job is to turn an idea into a codebase that has enough structure for a human and an agent to keep improving it.

That means the questionnaire matters. It captures the user, problem, promise, scope, design direction, pricing, setup assumptions, and proof strategy. The generated repo should reflect those answers in its source truth, docs, Program, ExecPlans, and starter app shell.

The videos belong here too. They are not a separate product. They are the guided path for people who need to understand the system while they build.

Starter

The output is a generated app plus an operating spine

Starter should help a new builder move from product idea to AI-ready repo without burying them in the internals of the worker system.

The point is not to sell forty videos as the headline. The point is to give a new builder the next real step after vibe coding: a repo that can keep product truth and implementation work in the same place.

The generated repo carries product facts, design truth, docs, Program, ExecPlans, and the first app shell.

Workers starts after the repo is messy

Workers is for existing repos. The buyer already has code, users, bugs, half-finished AI changes, or a working product that is getting harder to move safely.

That path should begin with diagnosis, not loop configuration. The first thing to know is what the repo needs: source truth, a proof harness, observability, broken-app triage, revenue path review, UX conversion review, test hardening, or something else.

The first paid promise is bounded: local runner setup, private doctor pass, Top findings, one approved worker loop, and proof or blocked proof.

Workers

The output is one approved worker loop with proof

Workers is not a course, a starter, or a prompt pack. It is the install path for making an existing repo ready for AI worker execution.

This is why Workers needs its own landing page. The person with a live repo is not asking for beginner lessons. They are asking whether AI can safely help move the repo they already have.

The Worker path starts from the repo as it exists, then narrows toward one approved loop.

The split makes the product easier to buy

The public site should route by intent.

I have an idea goes to Starter.

I have a codebase goes to Workers.

The Man Meets AI homepage can explain the thesis, media, and technology. The product pages can sell the specific job. Docs can remain available for support. Blog can carry the thinking behind the system.

That is cleaner than forcing every buyer through one page and hoping they find the part meant for them.