Zagvo
← BUILD STORIES
BUILD STORY 03ILLUSTRATIVE BUILD JOURNEY

INDIE HACKER · A MICRO-SAAS DASHBOARD · REPLIT · BUILD → DEBUGGING

I HAVE THE IDEA.
I JUST DON'T KNOW
WHAT TO BUILD FIRST.

The idea was clear enough to explain in a sentence. The problem started when the builder opened Lovable and had to decide what the first prompt should actually build.

This is an illustrative build journey based on common builder patterns. Real customer stories will be published as Zagvo launches.

THE LOOP

Four fixes. One symptom that would not leave.

Login worked on the first try, then broke on refresh. The AI builder confidently proposed a fix. It worked briefly. The same symptom returned in a slightly different form. Another fix followed. Same pattern.

  1. REPORT 01

    The login page keeps redirecting me back.

    RESULT

    Authentication redirect logic was changed.

  2. REPORT 02

    It still happens after refresh.

    RESULT

    Session persistence handling was changed.

  3. REPORT 03

    Now the dashboard logs me out on its own.

    RESULT

    The auth-state listener and route guard were changed.

  4. REPORT 04

    It still logs me out.

    RESULT

    Loading and hydration logic were changed.

The code kept changing. The evidence did not get stronger.

Each fix sounded confident because it referenced real code. None of them referenced a reproduced failure with captured evidence.

THE THREE LAYERS

Symptom. Assumption. Evidence. They are not the same thing.

THE WEAK LOOP

"Symptom, assumption, code change. Repeat."

SYMPTOMASSUMPTIONCODE CHANGE

Six competing directions. No obvious next.

THE STRONGER LOOP

"Reproduce, capture, classify, then change one thing."

  1. SYMPTOM
  2. REPRODUCE
  3. EVIDENCE
  4. CLASSIFY
  5. FIX

One linear path. One decision.

THE CLAIM

"I found the issue."

The AI may have found suspicious code. It may have found a plausible race condition, an outdated pattern, a nearby error, or a code path that looks capable of producing the symptom. None of that is proof of the root cause.

BEFORE ANOTHER FIX

Classify the failure before changing any code.

Classification is not about blame. It decides where to investigate. If the wrong category is picked, every fix targets the wrong system.

THE PROTOCOL

The stop-fixing checklist.

CURRENT TASK

Stop changing code. Return to evidence.

DONE WHEN
  • 01 · Freeze all code changes
  • 02 · Write the exact symptom in one sentence
  • 03 · Start from a known state, such as a signed-out browser
  • 04 · Reproduce the behaviour on purpose
  • 05 · Capture runtime evidence for that reproduction
  • 06 · List every code path capable of producing it
  • 07 · Eliminate the paths the evidence rules out
  • 08 · Identify the exact transition or caller involved
  • 09 · Fix one proven cause, not several suspected ones
  • 10 · Re-run the original reproduction
DONE WHEN

The original reproduction no longer reproduces.

WHERE ZAGVO FITS

Sometimes the next step is not a better prompt. It is a better investigation.

The user tells Zagvo what happened, what has been tried and what evidence exists. Zagvo does not read logs automatically. It does not inspect Replit automatically. It helps reason about the next useful diagnostic action so the next prompt to the AI builder targets a proven cause instead of a suspected one.

BEFORE

Fix authentication again.

ZAGVO'S DECISION FRAME

What evidence would distinguish an application defect from an environment issue or a test-side observation?

NEXT TASK

Freeze changes. Reproduce from a known account. Capture session state before refresh, the network request during refresh, auth events emitted, and the route transition reached after hydration.

THE OUTCOME

The bug did not need another fix. It needed evidence.

BEFORE
  • Four speculative fixes across four systems
  • Multiple changed auth paths
  • No stable reproduction
  • No proof of root cause
  • A prompt loop that always sounded confident
AFTER
  • One exact symptom in one sentence
  • One reproducible sequence from a known state
  • A list of possible callers to eliminate
  • Evidence to classify the failure
  • One bounded diagnostic task
When the same bug is "fixed" for the fourth time, stop changing code. Return to evidence.

STUCK IN A FIX LOOP?

Stop changing code before you know what is broken.

Tell Zagvo what happened, what you tried and what evidence you have. Work through the next useful diagnostic action.

ILLUSTRATIVE STORY
MORE BUILD STORIES