Jump to a section
Your first screen came together quickly. Then search broke the layout, a cart change lost someone’s items, and progress turned into a loop of repairs. Here is a way to make the next change small enough to understand—and keep.
Take this with you
When features start depending on each other, speed comes from a smaller change and a clearer check. Start with one behavior you can prove.
01
The work changes when features connect
A new page can be mostly visual. A shopping cart reaches into product data, quantities, account ownership, and totals. A change that looks small on screen may affect several parts of the application. There is no universal hour when progress stops: the useful signal is that you can no longer explain what a change touches. At that point, another broad request usually adds more uncertainty.
02
Choose one behavior to recover
Suppose the cart total is wrong. Leave search, styling, and checkout alone for a moment. Write down one product, its saved price, the quantity, and the total you expect. That gives you a repeatable example. Ask your assistant to trace that example before it edits anything. A correct number is only part of the result; you also want to know where it came from.
A prompt to try in your project
The cart total is incorrect. For a product priced at $20 and quantity 2, I expect $40. Trace the request from the quantity form to the displayed total. Identify where the saved price and quantity are read. Propose the smallest fix and a check that fails before the fix and passes afterward. Do not change styling or add features.
Want to see this teaching style before buying?
The free sample turns a vague design request into a change you can check.
Read the free course lesson →03
Keep a short project note
Write down the decisions that the next session needs: your framework, where product prices live, what checkout does, and what already works. Include the current bug and the last working commit. Ask the assistant to inspect the actual files as well. The note is a map to the project, not a replacement for reading it.
04
Check the failure case, then save the working slice
After the normal quantity works, try a value your app should reject. Does zero, a negative number, or a quantity above stock produce the expected response? Ask for a focused automated check where the behavior matters. Then review the changed files and commit the repair. Keeping that save point lets you return to something known if the next experiment fails.
- Repeat the original example and compare expected and actual results.
- Try one relevant invalid input and check the response.
- Review the diff for unrelated edits.
- Commit the working change and record the next small step.
05
Practice the process before expanding the app
A smaller learning project gives you room to rehearse this routine. Northstar, the marketplace used in Build Your First Real App, introduces the catalog, cart, practice checkout, and background jobs in separate stages. The point is to understand each connection as it appears. If your existing project already serves real customers, isolate your experiments in a development environment and get a review for changes you cannot yet assess.
Build Your First Real App
Give your next build a sequence you can follow.
Practice the same inspect, check, and save routine through a complete learning project, with reference examples to compare against your own work.
- Source control and save points · pp. 31–34
- Catalog through practice checkout · pp. 35–59
- Debugging workshop · pp. 70–95
120-page PDF + visual kit · $29.99 · one-time purchase
Self-paced reading and building. The kit is a browser prototype; you build the Rails app. Checkout uses practice orders.
Questions you might have
Should I start the entire app again?
First identify what works, reproduce the failure, and inspect the affected files. A small repair may be enough. A rewrite is a decision to make after understanding the problem, not an automatic response to frustration.
Will a longer prompt solve it?
More detail helps when it describes the current behavior, the expected result, and the boundaries of the change. Extra instructions without a concrete example can make the request harder to review.
Where should a beginner start?
Start with one visible behavior, such as displaying a product and its saved price. Once you can explain and check that feature, build the next one.
