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

> Source: <https://dev.to/stanley_f57ec6c939e0e82db/prototype-and-port-the-best-way-to-use-claude-for-personal-projects-3ceb>
> Published: 2026-08-28 06:34:25+00:00

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.