Three AI App Foundations in Five Days - The Build Diary

By day 5 of a 30-day product experiment, I had three working application foundations in local development. I did not have three launched products.

One dated build day within that period is directly countable: on 4 February 2026, the AgentPersonalities, PromptDuels, and TaskBounty repositories recorded 153 commits in total. That count describes repository activity across those exact three projects. It does not describe deployment, reliability, users, or revenue.

This is the useful version of the build diary: the architecture decisions, the coordination method, and the missing steps that separated green local builds from products in the market.

The experiment setup

The 30-day experiment used agent-assisted development to test product ideas in public. I directed the work rather than writing every change in one continuous manual coding session.

The working stack included:

• Claude and Codex for implementation, research, and review tasks
• Next.js for the application interfaces
• Convex for data and application workflows
• OpenClaw for coordinating queued agent work

My background in solo consulting and development shaped the process: define the scope, build an inspectable increment, review it, and hand the next decision back to a person.

The three foundations

AgentPersonalities

A marketplace concept based on SOUL.md files that describe an agent's capabilities, tone, and boundaries.

PromptDuels

A prompt-comparison concept with head-to-head duels and rating logic.

TaskBounty

A task-and-reward concept for work that could be claimed by a person or an agent.

The concepts were designed to explore related mechanics, but the proposed connections between them remained a product hypothesis.

Architecture decisions that helped

1. A consistent application stack

Using Next.js and Convex across the three repositories reduced the number of architectural decisions needed for each foundation. Repeated patterns could be reviewed in a familiar shape.

The trade-off was coupling the prototypes to the same platform choices before user needs had been validated.

2. Shared interface patterns

Common buttons, cards, forms, and layout conventions reduced duplicated design work. The shared patterns were internal build infrastructure, not evidence that the products were polished.

3. Bounded agent assignments

OpenClaw coordinated scoped tasks such as repository exploration, scaffolding, feature drafts, checks, and documentation. Each assignment named the permitted area and the point where a human decision was required.

4. Workflow before polish

The early work prioritised:

• data-model direction
• typed application paths
• core interaction loops
• local build health

The interfaces were foundations. They had not yet passed a production launch, accessibility review, external user test, or reliability period.

What did not work

Feature abundance

Fast draft generation made it easy to expand the backlog before the core loop had been tested. More implementation did not create stronger evidence.

Early refactoring

Agents could propose broad cleanup before the product direction was stable. Keeping refactors behind an explicit decision reduced churn.

Building without deployment pressure

The biggest gap was not code volume. Deployment was still pending, so the work had not reached real users and could not establish demand.

The queued-work pattern

A typical cycle looked like this:

1. Write a clear queue of issues or missing flows.
2. Split only independent tasks into parallel assignments.
3. Set file and decision boundaries for each assignment.
4. Collect incremental commits and review notes.
5. Run local checks and decide what to keep.

The process extended the amount of work that could be prepared between review sessions. It did not make output trustworthy without inspection.

What the commit count means

The 153-commit count is exact for the three primary repositories on the documented build day:

• many commits were small checkpoints or fixes
• some represented incomplete feature work
• none, by count alone, proved a product outcome

Commit history can show activity and chronology. Product evidence requires deployment state, usage, reliability, and customer feedback.

The commercial context

At the time, I was testing a $10K MRR target and an AI Development Sprint offer. Those were experiment goals and proposed commercial framing, not achieved recurring revenue or completed-engagement performance.

Current services and pricing decisions are owned by the live Services and Contact pages rather than this historical diary.

What came next

The next priorities were clear:

• deploy one foundation deliberately
• test onboarding with external users
• measure activation rather than repository activity
• narrow the product set using feedback

Final thoughts

The experiment demonstrated that I could coordinate substantial local implementation across three repositories. It did not establish that three products were production-ready, launched, or commercially validated.

That distinction is the main lesson. The build was ahead of the proof, and the work after a green local build was the part that mattered most.