The project
Why gFactory
The problem I'm actually solving
I have more product ideas than hours in a week. That's true of most people who build things, so on its own it isn't interesting. What made it worth solving properly is where the hours actually go. It's rarely the hard engineering. It's the setup around it: getting a new agent session up to speed on what already exists, what conventions the codebase follows, what's already been tried and rejected, before it can do anything useful. That overhead doesn't show up as a line item anywhere, it just quietly taxes every session, on every project, every time I sit down. Multiply that across several projects and most of a week disappears into re-explaining rather than building.
I didn't want to trust my own irritation with this, so I talked it through with other builders in the community before committing serious time to it. The pattern held. Almost nobody pointed at difficult algorithms or hard problems as their real bottleneck. Everyone pointed at scaffolding, context, and the tax of picking a project back up.
Why this needed rethinking, not just more automation
My first instinct was to treat this as an agent orchestration problem: which model, which agent, how do they hand off to each other. That instinct was wrong, or at least incomplete. If the real cost is re-establishing context and re-checking whether the output can be trusted, then the choice of agent is almost a side issue. The actual hard problem is everything that has to be true before an agent's output is good enough to ship without me personally checking every line: a way to hand off well scoped work without re-explaining the world, and a way to decide, consistently, what's trustworthy enough to merge and what isn't. Agents turned out to be the easy part. Organizing and reviewing their work is the actual product.
What changes
Left alone, my week runs as a single queue. One project gets my attention while the others sit frozen, not because they're less important, but because there's only one of me. An idea that isn't currently "up" doesn't lose value, it just loses time, and time is the one thing I can't get back for it.
gFactory turns that single queue into several parallel lanes. Instead of one project moving while the others wait, more than one project can be actively worked at once, each moving at its own pace, each eventually converging on the same review step before anything ships. The goal isn't to make any single project faster in isolation. It's to stop unrelated projects from blocking each other just because they share the same one person.
How it actually works
Every project, regardless of size, moves through the same five stages.
- Plan.
- A product idea becomes a working plan: what's being built and why it's worth building. This stage stays deliberately human. Deciding what matters is not something I want to hand off, even to myself in a hurry.
- Break down.
- The plan splits into work packets, pieces scoped tightly enough that picking one up doesn't require re-absorbing the whole project first. This is the stage that directly attacks the re-explaining tax. Get the packet right, and an agent can act on it without a long onboarding conversation. Get it wrong, and all the same overhead comes right back.
- Build.
- Idle capacity claims the next packet the moment it's free. Several packets, on different projects, can move at the same time. This is where the actual parallelism lives, but it's the least interesting stage philosophically. It's the payoff of getting the earlier stages right, not a breakthrough on its own.
- Test and review.
- A finished packet isn't a finished product. It has to build, pass its tests, and survive review before it counts as done. Anything that doesn't loops back through refine rather than shipping as is. This is the stage I trust least by default, on purpose, which is worth its own explanation below.
- Ship.
- Only work that survives build, test and review goes out the door. Nothing skips ahead because it looked close enough.
Why the review stage matters more than it looks
Every packet, regardless of which project it came from or how small it looks, passes through the same checks. Nothing gets a pass because it seemed simple or because the output looked confident. The default posture is conservative: a project's very first pieces of work require my sign off before they ship, and that default only loosens as a specific project earns a track record, not because loosening it would look more impressive.
I'm being explicit about this because "autonomous" is an easy word to oversell. Speed here is supposed to come from running more lanes in parallel, not from trusting any single lane more than it's earned. If those two ever trade off against each other, trustworthiness wins.
Why this is worth building
- More shots on goal. Ideas that would otherwise sit untouched for months get worked on in parallel instead of waiting for a single queue to clear. The cost of starting something is lower, so more things actually get started.
- Less time re-explaining, more time deciding. The context that used to get rebuilt every session gets captured once, in the plan and the packet, and reused from there. What's left for me is the part that actually needs judgment: is this the right thing to build, and is the result good enough to ship.
- A visible track record. Every decision, dead end and course correction gets logged in the open rather than living only in my head. That matters less for marketing and more for honesty. It's much harder to quietly redefine success after the fact when the reasoning at the time is already public.
- Not just a personal fix. Anyone with more ideas than hands runs into the same constraint eventually. If this holds up for me, it's evidence toward a real answer to a common problem, not a productivity trick that only works because it's tailored to one person's habits.
What this project doesn't cater to
This section exists because it's easy to let a project like this sound bigger than it is. A few honest limits:
- It doesn't replace product judgment. Deciding what's worth building, for whom, and why, stays entirely human work. gFactory changes how something gets built once that decision is made. It has no opinion on whether the decision itself is a good one.
- It isn't unsupervised, and that's deliberate, not a temporary limitation. The default is a human checkpoint before anything ships, and I don't intend to strip that out just to make the system look more autonomous on paper. Loosening it happens project by project, as trust is actually earned, not as a default setting.
- It isn't equally good at every kind of work yet. Some kinds of output, particularly anything visual or interface heavy, are harder to verify automatically than backend logic is. Those areas get more manual attention right now, not less, precisely because the review step can't yet lean on the same checks that work well elsewhere.
- It isn't free to run carelessly. Every packet that runs costs real time and real money, so there are guardrails on how much any single piece of work is allowed to consume before it has to stop and surface the problem instead of quietly continuing.
- It isn't a service or a product you can use today. This is personal infrastructure I'm building for my own backlog of projects, documented in public because the documentation is useful on its own, not because it's being offered or sold as a tool.
- It isn't proven yet. Everything above is the reasoning behind the bet, not evidence that the bet has paid off. That evidence, if it shows up, will show up in the journal, not in this page.