Prototype and Port: The Best Way to Use Claude for Personal Projects

A developer building a beat-maker web app used Claude to prototype JSON manipulation logic in small Python scripts before porting it into a 1500-line HTML file. By testing the concept in isolation, the developer ensured the logic was correct and understood before integrating it, demonstrating an effective workflow for using AI assistants on personal projects.

I was building a beat-maker web app and needed to add a feature that let me replace or append presets in a JSON array — wired up to a dropdown in a modal inside a 1500-line HTML file. I didn't start there. Here's what I did instead. When you drop a big file in front of Claude, there's a lot of noise — styles, event listeners, utility functions — that can pull the logic in unexpected directions. See the live project at famous-beats-maker https://vercel-youtubeviewer.vercel.app/famous-beats-maker 1.html — specifically the "Edit JSON" modal. The goal was to be able to change and swap out any beat in the dropdown, like "Four-on-the-floor house ". The fix: prototype the concept first in the simplest possible environment, then port it. I had a beats.json file — a JSON array of preset drum patterns. Before writing anything, I just asked: "in beats.json for example how do I access with python the first item in the json" beats.json is an array of objects, each one a full drum preset: { "name": "Four-on-the-floor house ", "bpm": 92, "desc": "Steady kick on every beat with off-beat hi-hats — the backbone of house and disco.", "kick": 1,0,0,0,0,0,1,0,1,0,0,0,0,0,0,0 , "snare": 0,0,0,0,1,0,0,0,0,0,1,0,1,0,0,0 , "hat": 1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0 , "crash": 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 , "tone": 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 }, ... 70 presets total I needed a way to access this JSON because I'd eventually be replacing items in it. Once Claude explained it, I followed up with: "write this out as access beats.py please" That gave me a 10-line Python script. One file in, print to terminal, done. I could run it against real data immediately and see exactly what I was working with. Once I could read the data, I added an argument so I could pick which item to access: "great add an argument so I can choose — I will use notation 0 instead of 1" Now I had: python access beats.py 0 first preset python access beats.py 3 fourth preset Short prompt, small change. I understood every line. I had a replacement.json file — a single preset object I wanted to swap in. I asked: "great see I got replacement.json and if I want to replace can you give script replace beat.py with argument 0-based pls" replacement.json is just one object from the array — the same shape as any item in beats.json . Claude gave me a script that opens beats.json , swaps in replacement.json at the given index, and writes it back. I tested it. It worked. The logic was proven in about 15 lines. This is the key step. Before touching the big file, I mapped what each piece of the prototype was equivalent to in the web app: | Prototype | Web App | |---|---| beats.json | presets array in memory | replacement.json | Current board state | sys.argv 1 index | <select dropdown in the modal | | Append new name | <input field in the modal | | Write back to file | Save to Dropbox | Once the map was clear, I wrote one bigger prompt that described exactly what I wanted in the real project — referencing the elements by their HTML IDs, explaining the replace vs. append distinction, and specifying the 0-based index format: "so json-schema will be replacement.json and then instead of the textarea I get a dropdown that I can select which I want to replace... and I can choose dropdown to add and how would if I wanted to append a new one I guess let me have an input where if I write something in the input will append to object +1 to the array" Because the concept was already clean and proven, Claude could focus entirely on finding the right hooks in the existing code — the event listeners, the state variables, the UI elements — and slot the logic in accurately. Small files = better context. Claude reads a 10-line script cleanly. The concept lands without distraction. You stay in control. You understand the logic before it touches your real project. Errors are cheap. Breaking a standalone script costs nothing. Breaking a 1500-line file costs debugging time. Claude can mirror the pattern. Once the archetype is proven, Claude knows exactly what shape the solution should take in any environment. 1. Ask about the data — understand the shape before writing anything 2. Build the archetype — smallest standalone version in Python, one operation 3. Add arguments — make it flexible enough to test properly 4. Map to the real project — identify what plays each role 5. Port with full context — one prompt that references the real hooks Use this any time you're adding logic to an existing complex file. You don't need it for small edits — a colour change or a typo fix doesn't need a prototype. But for anything involving data flow, state, or multi-step logic, the archetype step pays for itself every time.