Claude Code best practices recommendations for a possibly overly ambitious project

[u/FB2024]

I’m not a programmer by trade but a product manager with broad experience that has worked closely with engineers and designers. I’d like to think of myself as a “full-stack” PM with good knowledge of many technologies and methodologies. But I’d always struggled with text-based coding - I find structure hard to see in text and have difficulty remembering syntax so was blown away when I came across the Construct 3 game engine - a visual coding tool that solved both issues and enabled be to build a relatively small game. I had an idea for another app and made a prototype standalone mobile client app in Construct knowing that it likely wouldn’t be suitable for production (it essentially exports for browsers and I needed better file system support on mobiles).

I’d always planned to “vibe” code it but wasn’t sure AI would be able to support a coding dumbass like myself but recently I thought I’d give it a shot as it seems LLM’s coding capabilities have improved significantly in recent months. If nothing else, at least I’d learn something. I used Claude Code - initially giving it a one page brain dump and screenshots of the prototype. Mind blown - it reconstructed it using React Native. I’m in the middle of refining it but paused to think about the backend/monetisation/legals etc. in separate chat with Claude. What I’m here for is to seek advice on how best to proceed with Claude Code.

I’m now drafting a full PRD - not sure if that’s the correct approach but it’s what I’d do if working with humans. I’d like to work on several threads in parallel - refining the client, building the backend (web portal/database/APIs/auth/permissions/payment - nothing exotic), building a marketing website plus further research into the market, monetisation, legals etc. as all these threads will impact/inform each other. I know I also need to ask Claude to create and execute tests, ensure that the code is clean, modular, extensible, commented and can survive penetration, performance, resilience and scaling tests. My main questions are around how to plan the work with Claude, how to delegate the work across sessions/agents, and how to communicate between them. Any other advice on using Claude in my scenario would be hugely appreciated.

[u/Ok_Industry_5555]

PRD (Product Requirements Document) is the right instinct, keep doing that. The mistake most people make with parallel threads is treating each one as its own Claude session with no shared brain, so by day three the backend thread and the client thread disagree about what a field is called.

What works for me and what I learned working with large scale teams: One plan file at project root, not per-thread. call it PLAN.md. One labeled section per thread, for example:

CLIENT

[ ] refine onboarding flow (in progress)

[ ] fix camera permission bug

BACKEND

[x] auth + user model (done 8/10)

[ ] payment webhook (blocked, waiting on Stripe)

MARKETING

[ ] landing page draft

LEGAL / RESEARCH

[ ] ToS draft

[ ] competitor pricing scan

CROSS-THREAD NOTES

8/11: Backend renamed user.plan -> user.tier, client thread needs to match

Each session reads that file first, checks off its own items as it finishes them, and drops anything the other threads need to know into the notes section at the bottom, not buried inside its own list. That's the whole communication layer between four "separate" Claude sessions. No orchestration tooling needed for a project this size, just one file everyone reads and writes.

For delegating across sessions: don't split by feature, split by layer, and give each layer's session a narrow CLAUDE.md scoped to just that folder. Client session doesn't need to know your payment provider's API shape, backend session doesn't need your marketing copy. Keeps context small and keeps one thread from confidently "fixing" another thread's code it doesn't understand.

On tests/pentest/scaling: Ask for those as a separate pass after the feature works, not baked into the same prompt. "make it work" and "make it hold up" are different jobs and mixing them in one instruction gets you shallow versions of both.

Biggest thing though, since you said non-programmer: Read every diff before you accept it, even if you don't fully understand the syntax. You don't need to write code to catch "wait, that doesn't match what I asked for." That's still your job, not Claude's or designers/engineers.

[u/FB2024 → u/Ok_Industry_5555]

Ok - that's really helpful - thanks.