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

Stanley — Fri, 28 Aug 2026 06:34:25 +0000

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.

The Problem with Going Straight to the Complex Project

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 — 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.

Step 1 — Ask Claude about the data first

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.

Step 2 — Add just enough to prove the concept

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.

Step 3 — Write the operation as a standalone script

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.

Step 4 — Map the archetype to the real project

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

Step 5 — Give Claude the full context for the port

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.

Why This Works

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.

The Template

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.

DEV Community: Stanley