Turn “build an app” into a change someone can accept
A community photography club wants an equipment-loan page. Members browse equipment and submit requests; an administrator records decisions and returns. The owner has limited development experience and wants to work with an agent. This exercise uses test data and includes no real deployment. The first target is one runnable slice: submit a request and find its result again.
The source covers product scope and architecture, implementation and delivery, debugging and quality, Skill discovery, and effective iteration. Nine package names represent different workflow roles, not a requirement to install nine tools. Here those roles become concrete handoffs within one example. Download totals, universal security-review claims and promises of production-ready generation are not repeated as verified facts. Execution depends on the host, project environment and actual permissions, not the phrase “full stack.”
Scope the user action and its failure cases
Clarify who submits a request, how the administrator identifies it and what happens when dates conflict. Write observable acceptance conditions: a test member chooses available equipment, supplies valid dates and receives a request identifier; the record remains visible after refresh; invalid dates are rejected; a network failure cannot display success. Exclude payments, text notifications, recommendations and a public social community from the first slice.
Resolve business vocabulary before coding. A request is not an approved reservation. Until an administrator decides, its state is pending. Returned equipment is not necessarily inspected equipment. Build a state table for pending, approved, rejected, cancelled and returned, with the actor allowed to make each transition. Deliver a short scope document, three user paths and an unresolved-question list so the generator does not invent approval policy.
A nontechnical owner can express results and counterexamples without selecting every library. “Repeated submission of the same request creates one record” is more testable than “use the best reliable architecture.” Unknown permissions and retention periods remain visible questions. The planning handoff should narrow the product into something buildable, rather than expand a wish list each time the agent suggests another feature.
Compare architecture against the actual constraints
Inspect existing code, run instructions and locked dependencies first. A new page does not automatically justify recreating the project. If a club site already exists, compare reusing its identity and database with a separate prototype. For a local exercise, test accounts and isolated storage may be sufficient. Record the deployment environment, maintainer experience, persistence and concurrency needs, recovery plan and cost behind the choice.
Draw the boundary between interface, request API and storage. The server validates identity and dates. Disabling a browser button can improve interaction but cannot independently prevent duplicate writes. Define equipment ID, request ID, applicant, date range and state. Do not collect private contact details merely because they might be useful later. Document request idempotency separately from conflicting reservations: returning the same request safely and allocating the last available item are different problems.
The architecture output is a decision record, field model and API contract. Include the rejected option and its consequence. For example, a local JSON demonstration is not evidence of safe concurrent writes across several processes. Prefer a design the owner can explain and run. Before a real launch, authentication, access control, data lifecycle and operations need their own acceptance; this example does not substitute for those reviews.
Implement slices that cross the necessary boundaries
Sequence the work as a test equipment list, request submission and retrieval, then administrator state changes. Each slice traverses the interface, API and persistence it needs. Generating every screen first and guessing the backend connection later creates attractive fragments rather than a working workflow. A task card should identify allowed changes, inputs, expected behavior, run commands and acceptance conditions. Keep one writer for the same files; record review suggestions before applying another set of edits.
A useful implementation request is: “Add test request submission within the existing project. Change only the UI, API and tests needed for this slice. Validate dates on the server, return the original record for a repeated request, and retain input while showing a network error. Explain affected files and data changes, implement, then report actual checks. Add no payments, notifications or new account service.” The wording cannot guarantee correctness, but it makes scope drift observable.
Check dependencies, environment variables and the test database before running. Example configuration must not contain real credentials. Creating an environment file does not establish an external connection. Any service that costs money or receives data needs the appropriate authorization. Label placeholder endpoints as simulated rather than completed integrations. When dependencies conflict, inspect the project's versions and lockfile instead of upgrading the entire chain to silence one error.
Review the diff after a slice. Look for unrelated configuration changes, removed functionality and temporary data accidentally included. The handoff lists files, schema changes, startup command, checks actually executed, untested cases and recovery instructions. A successful build establishes that artifacts can be produced. It does not establish that user behavior, permissions and persistence are correct; those need separate observations.
Accept a slice with evidence at the right layer
Use Webapp Testing at the local browser-acceptance step. Its pinned workflow uses Python Playwright to inspect the rendered application, select controls, interact and collect screenshots and logs. Prerequisites include a runnable local app, its startup command and port, Python, Playwright, appropriate browser binaries and permission to use the fixtures. It does not choose the product requirements or prove backend concurrency and authorization from a page alone.
Inspect the actual DOM before selecting a role or label locator. Exercise “choose equipment, enter dates, submit, read the request ID, refresh and retrieve.” Also check invalid dates, an API error and repeated submission. A screenshot records the interface state; an API response or storage query establishes a different part of the claim. Tie evidence to the same request identifier. A success notification on screen is insufficient proof that a record was committed.
Browser checks can observe the double-submit interaction. A server-side check should separately establish that the same idempotency key produces one request. Test authorization with another member who must not read or modify someone else's record. Report “selected cases passed,” not “the system is secure” or “every browser works.” If one browser configuration ran, name that configuration. Keep cases that were never executed explicitly unverified.
Save application revision, command, inputs, expected and actual outcomes, logs and failure evidence. A retry that passes does not erase the first failure or prove the behavior is stable. Accept or return this slice against the previously written criteria before moving on. That prevents a queue of unconfirmed edits from making every later defect harder to locate.
Debug the first divergence, rather than rewriting everything
Suppose the interface reports success but the request disappears on refresh. Fix the reproduction environment, input, path, version and time first. Preserve request status and relevant logs. Candidate causes include an in-memory-only UI update, a request never reaching the server, an error response ignored by the client, an uncommitted write or a retrieval filter hiding an existing record. These are hypotheses, not conclusions available from one screenshot.
Create a check that reproduces disappearance and trace the call chain until expected and actual behavior first diverge. If the UI treats every response as success, repair that handling and add failure feedback. Then determine whether a separate persistence problem remains. A delayed refresh is not a valid substitute for identifying the fault. After the patch, rerun the original reproduction, error path and nearby behavior, and inspect the diff to ensure the repair stayed bounded.
Change Skills when the method cannot support the real stack or required artifact. First rule out input, environment and invocation errors rather than swapping tools after every failure. Preserve reproduction and attempted explanations before changing methods, or the next tool will merely start guessing again. Several debugging packages editing the same files simultaneously make cause and effect harder to distinguish; assign the active writer and review order.
Discover Skills by the current gap
A useful discovery request names the user, stack, current state, blocker and artifact: “Existing local equipment-loan page with a Python backend; requests disappear after refresh; need reproducible steps and browser regression evidence.” Compare public source, SKILL.md, license, runtime dependencies and actual access requirements. Record which step a candidate supports and which parts still need ordinary implementation work. Popularity alone does not establish fit.
The verified SkillPI association here is the browser-testing workflow used after implementation. This article has not established matching source evidence for the source's planning, blueprint, full-stack builder or debugger package names in the SkillPI catalogue. It therefore does not add guessed links to reach a count of nine. Finding a candidate is not installation; installation is not activation; reading instructions is not an accepted execution result.
If a discovery helper is used, verify its official source, host installation path and required access, then test discovery behavior on a reversible, non-sensitive example. Automatic search does not authorize automatically installing every result. Static source review is not runtime safety certification. Keep the chosen version and trial evidence, and revisit the association when a package update changes scope or dependencies.
Keep recovery points for code and data
Each accepted slice becomes a version checkpoint with the previous runnable revision, dependency changes and migrations recorded. Reverting code does not necessarily restore a database. If fields or states changed, explain whether the old application can read the new data and whether a forward repair is needed. Rehearse recovery on an isolated copy. Do not delete real loan requests to restore a demonstration.
Deployment preparation includes a reproducible build, environment instructions, backup and recovery, logs and health checks. Preparation is not publication. A real launch would require authorized test accounts, observation of the deployed revision and key paths, and a recovery decision if the checks fail. No such deployment occurred for this fictional club. The artifact is a reviewable workflow, not a claim that a production application exists.
Frequently asked questions
Where should an idea-only builder start? Define the user action, result and failure examples, then choose a scoping method. Can a PRD become an app? It can be input, but fields, permissions, states and runtime assumptions still need implementation and staged acceptance. Can a non-developer participate? Yes, through clear user paths and reviewable outcomes; migrations, permissions and operational risks may require someone with the relevant expertise.
What if generated code keeps failing? Capture the smallest reproduction, logs and version, distinguish environment from business behavior, repair one issue and rerun. What if the third revision becomes confusing? Return to the last accepted checkpoint, compare scope and change reports, and place new wishes in a separate task card. What counts as done? A runnable artifact, evidence for the specified paths, visible unverified scope and an explainable recovery method—not the agent's statement that everything is finished.
Sources
The English source provides the planning, building, quality and discovery scenarios. GitHub's Playwright project offers an inspectable browser-testing implementation and documentation, making it a suitable reference instead of inventing another browser framework. No dependency installation or club-app test run was performed for this article. The pinned Webapp Testing source supports the bounded local-browser step; review its Apache-2.0 license and dependencies before adoption.