A solo builder’s notes on using GPT-5.6 as a product reviewer, code reviewer, and design partner—not just a code generator.

In 2025, I wrote about using Cursor and AI to build Focero, a small web-based focus timer.

That first phase was mostly about creation.

I was generating layouts, implementing timer logic, adding multilingual pages, fixing bugs, and trying to turn a simple idea into a working product.

The next phase was very different.

By 2026, the app was no longer a blank project. It already had an existing codebase, working pages, search visibility, returning users, design decisions, technical debt, and features that should not be casually replaced.

Starting over would have been easy.

It would not necessarily have been correct.

So instead of asking AI to build another version of Focero from scratch, I used GPT-5.6 Sol in ChatGPT as a product reviewer, code reviewer, and design partner.

The goal was no longer to generate more.

The goal was to understand what already existed, identify what was weak, preserve what was working, and upgrade the product without damaging its foundation.

Building Is Easier Than Upgrading

A blank project is surprisingly comfortable.

There are no users to disappoint, no existing URLs to preserve, no old components to understand, and no previous decisions to respect.

You can change the architecture, redesign the interface, rename everything, or replace the entire stack.

An existing product is different.

Every change has consequences.

A new visual design might make the interface more attractive, but it could also make the timer harder to read.

A cleaner component structure might improve maintainability, but a large refactor could introduce regressions.

A rewritten page might look better, but it could change what search engines and existing users already understand about the product.

This was the first major lesson of the upgrade:

The question was not “What can GPT-5.6 build?”
The question was “What should remain untouched?”

That distinction changed how I worked with the model.

Using GPT-5.6 as an Auditor

My earlier AI workflow often looked like this:

1. Describe a feature.
2. Ask AI to generate it.
3. paste the result into the project.
4. Fix obvious errors.
5. Move to the next feature.

That workflow is fast, but it encourages accumulation.

More pages. More components. More settings. More animations. More code.

For the upgrade, I used a different sequence:

1. Inspect the existing implementation.
2. Describe the real problem.
3. Separate product problems from code problems.
4. Propose multiple approaches.
5. Choose the smallest useful change.
6. Apply a focused patch.
7. Build and test the result.
8. Review a real screenshot.
9. Reject anything that still looked wrong.
10. Repeat.

GPT-5.6 was most useful when I gave it constraints rather than open-ended creative freedom.

For example:

• Do not change existing URLs.
• Do not redesign the entire site.
• Do not add a new dependency unless it is necessary.
• Do not increase the number of rendering layers without a performance reason.
• Preserve the current timer behavior.
• Modify only the files required for this iteration.
• Verify the production build after every change.

These constraints made the output more useful.

They turned AI from a feature generator into an engineering collaborator operating inside an existing system.

The Timer Was Not Just a Countdown

A basic timer is easy to demonstrate with setInterval:

let remainingSeconds = 25 * 60;

setInterval(() => {
  remainingSeconds -= 1;
  renderTimer(remainingSeconds);
}, 1000);

This works in a simple demo.

It is not a reliable source of truth.

Browsers can throttle inactive tabs. Devices can sleep. A page can be hidden and restored. Rendering can pause. A user may return several minutes later.

If the timer depends entirely on the number of interval callbacks that happened to run, the displayed time can drift away from reality.

A better model is based on timestamps:

const timerState = {
  status: "running",
  phase: "focus",
  startedAt: Date.now(),
  endsAt: Date.now() + 25 * 60 * 1000
};

The remaining time is calculated from the target end time:

function getRemainingMs(state) {
  if (state.status !== "running") {
    return state.remainingMs;
  }

  return Math.max(0, state.endsAt - Date.now());
}

The interval still exists, but its responsibility changes.

It updates the interface.

It is not the clock.

The interval is the rendering loop.
The timestamp is the source of truth.

GPT-5.6 helped me reason through recovery states, pause behavior, break transitions, and the difference between UI refreshes and actual timer state.

But the important improvement did not come from generating a larger amount of code.

It came from choosing a better mental model.

Visual Effects Were Harder Than They Looked

The app is not only a numerical timer. Part of the product direction involves calm visual environments that can sit behind a focus session.

One scene included rain, water, firelight, a lamp, foliage, and a reading cat.

At first, the goal sounded simple:

“Make the scene feel alive.”

That request produced several technically valid but visually poor results.

A procedural flame looked like a yellow geometric sticker placed over the original fire.

A moving cat ear looked like a clipped section of the background rotating independently from the animal.

Water ripples were technically interactive, but they became too large and repetitive.

More movement did not automatically create more atmosphere.

In some cases, it made the scene less believable.

This became one of the most useful parts of the process. I could show GPT-5.6 a screenshot and describe the problem in ordinary language:

• The fire looks artificial.
• The ear movement feels detached from the cat.
• The water reacts, but it looks like a radar interface.
• The interaction exists, but it is too weak to notice.
• The scene feels technically animated but not natural.

The model could then translate that dissatisfaction into implementation changes:

• reduce the opacity and size of generated flames;
• preserve the original illustrated fire as the visual base;
• remove fake cropped-body animation layers;
• lower ripple density and duration;
• expand pointer-sensitive areas without adding more rendering loops;
• use irregular target-driven light changes instead of constant random flicker;
• reduce movement amplitude while increasing responsiveness.

The model was useful at converting subjective feedback into specific variables and code changes.

But it could not decide what looked good on its own.

That still required a person looking at the result and saying:

No. This is technically working, but it still looks fake.

Learning to Reject AI Output

AI-assisted development becomes dangerous when every generated output is treated as progress.

Some outputs compile.

Some outputs pass tests.

Some outputs satisfy the written request.

They can still be wrong for the product.

During the upgrade, I rejected several types of output:

Overengineered solutions

A small interaction did not need a new rendering engine, state library, or large dependency.

Decorative motion

An animation that exists only to prove that something is animated can make a focus tool more distracting.

Confident visual mistakes

A model can describe a result as natural, warm, polished, or subtle even when the screenshot clearly shows otherwise.

Unnecessary rewrites

A working component should not be replaced merely because the model can produce a more modern-looking implementation.

Premature feature expansion

When improving one timer, it is easy for the discussion to expand into tasks, accounts, analytics, achievements, collaboration, and AI planning.

Those ideas may be reasonable.

They were not the current problem.

The ability to reject generated work became as important as the ability to request it.

Preserving What Was Already Working

One of the strongest temptations in AI-assisted development is the complete rebuild.

A model sees an inconsistent codebase and naturally suggests cleaner architecture, renamed components, consolidated routing, new design tokens, and rewritten content.

From a purely technical perspective, some of these suggestions may be correct.

From a product perspective, they can be risky.

M already had pages that users and search engines were beginning to discover. Some sections were imperfect, but they were stable.

I did not want to disturb them only because a new model could generate a cleaner replacement.

So the upgrade followed a simple rule:

Experimental work stays isolated until it is clearly better than the current product.

New visual ideas were tested on a separate demo route.

The existing public experience remained stable.

A change had to prove that it improved the product before it earned the right to replace anything.

This approach is slower than a dramatic redesign, but it produces less accidental damage.

GPT-5.6 helped compare possible changes, but the decision to preserve stability was a product judgment, not a model capability.

A Better AI Development Loop

The most effective workflow I found was not a single perfect prompt.

It was a controlled iteration loop.

1. Start with evidence

Use the existing code, a screenshot, an error message, performance data, or an observed user problem.

Avoid starting with a vague request such as “make it better.”

2. Define what must not change

Preserving behavior is often more important than specifying the new behavior.

Examples:

• keep the existing route;
• keep the current timer controls;
• do not add dependencies;
• do not change the saved data format;
• maintain mobile performance;
• preserve the current public page.

3. Ask for alternatives

A single answer encourages premature commitment.

Comparing two or three approaches makes trade-offs clearer.

4. Apply a narrow patch

Small changes are easier to inspect, test, and reverse.

5. Verify technically

Run the build. Check syntax. Inspect console errors. Confirm that the expected files changed.

6. Verify visually

A successful build does not prove that the interface looks good.

7. Give direct feedback

“The motion is wrong” is less useful than:

“The ear moves independently from the head and exposes the edge of the clipped background layer.”

Specific criticism creates better iteration.

8. Remove bad features

Not every failed attempt needs to be improved.

Sometimes deletion is the correct upgrade.

What GPT-5.6 Did Well

In this project, GPT-5.6 was particularly useful for:

• reading and reasoning across multiple related files;
• identifying hidden coupling between UI and timer state;
• comparing implementation approaches;
• translating visual criticism into concrete parameters;
• maintaining constraints across an iteration;
• generating focused code patches;
• reviewing likely edge cases;
• explaining why a technically simple solution might fail in a real browser;
• helping separate immediate fixes from future ideas.

Its value was not limited to writing code faster.

It reduced the cost of exploring alternatives.

That matters because good product decisions often require comparing several plausible directions before choosing one.

What Still Required Human Judgment

GPT-5.6 did not decide:

• who Focero should be for;
• which existing pages deserved protection;
• whether an animation felt calm or irritating;
• whether a feature added value or merely added complexity;
• whether a visual result felt warm or artificial;
• whether a redesign was worth the risk;
• whether the product needed more functionality or more restraint.

It also did not experience the interface like a user trying to focus for 50 minutes.

A model can inspect visual hierarchy, CSS properties, and animation timing.

It does not become distracted, tired, annoyed, or emotionally comfortable in the same way a person does.

That is why human taste still matters.

The Result Was a Better Process, Not a Finished Product

I do not claim that GPT-5.6 finished the build for me.

The product is still evolving.

I also do not have evidence that every change improved retention, rankings, or long-term user behavior.

What clearly improved was the iteration process.

I could inspect more implementation options, identify more edge cases, and move from vague dissatisfaction to testable changes more quickly.

The model made it easier to ask:

• What exactly is wrong here?
• What is the smallest responsible fix?
• What must remain stable?
• Which output should be rejected?
• Which experiment is ready for the real product?
• Which idea should remain a prototype?

These questions are more valuable than simply asking AI to generate another feature.

Lessons for Other Solo Builders

My main lessons are simple.

Use AI to understand before using it to generate

A good model can help map an unfamiliar or increasingly complex project.

Let it inspect the system before asking it to replace the system.

Constraints improve output

Tell the model what it must preserve, not only what it should add.

Keep experiments isolated

A demo route, feature flag, or separate branch creates room for exploration without destabilizing the product.

Treat screenshots as evidence

Visual work must be reviewed visually.

A passing build is not a design review.

Delete confidently

A bad AI-generated feature does not deserve another five iterations simply because time has already been spent on it.

Do not confuse speed with direction

AI can help you move faster in the wrong direction.

Product judgment determines whether the direction is worth pursuing.

Final Thoughts

My first phase with AI was about proving that I could build something.

This phase was about learning how not to destroy what I had already built.

GPT-5.6 did not magically transform my app into a finished product.

What it changed was the speed and depth of the iteration loop.

It helped inspect more code, compare more options, identify edge cases, and turn vague dissatisfaction into specific changes.

But the most important decisions still came from human judgment:

• What should remain simple?
• What feels calm?
• What looks artificial?
• What is worth rebuilding?
• What should be left untouched?

The lesson was not that AI can build a product alone.

The lesson was that a stronger reasoning model can help a solo builder move from generating features to making better product decisions.

Focero is my ongoing attempt to build a calm focus tool that users can open, trust, and then almost forget about while they work.