For months, I’ve been the bottleneck on Fantasy Futbol. Not because I’m lazy, but because I’m not a developer. Deepali, our engineer in India, built the MVP while I handled product, design, and everything else. Sam, my cofounder, reviews structural changes before they ship. The problem was time zones and cost. Deepali’s in India. I’m in New York. By the time she’s wrapping up her day, I’m just waking up. By the time I’ve identified bugs and written them down, she’s offline. Moreover, she is a good developer and has an hourly rate. 

Our arrangement worked fine for an MVP, and for small scale updates. But as the app sits on the App Store with real users (my family, friends, people who actually care), the time and cost friction became unbearable.

Then something shifted. In the span of one day, I shipped 21 fixes. Not by becoming a developer. By building a system that let me act like one.

The Inflection Point

Two days ago, I got three things aligned at once:

1. Repository ownership. Sam transferred the GitHub repo to my ownership so I could deploy without friction.
2. Server access. I figured out SSH into our AWS EC2 instance and stopped treating the backend like a black box.
3. Live feedback. I got a developer environment running in Expo on my iPhone so I could see changes in real time, in the actual app, without deploying to production.

All three of these were a massive unlock. I couldn’t have done this with just one or two. Repository ownership without server access meant I could push code but not actually see what was running. Server access without live feedback meant I’d be guessing whether my changes worked. Live feedback without ownership meant I’d be waiting for Sam to merge every commit. Together, they removed every friction point between thinking of a fix and validating it on my phone in the league with my family.

That’s when the floodgates opened.

The Scaffolding

I’m not a developer. I don’t know what a hook is. File structure confuses me. I can barely explain what’s happening with the dev server I spun up. What I do understand is product. Things like: what the user experience should feel like, what my Figma designs say, what good taste looks and feels like on a mobile app, and what’s actually broken versus what’s just a nice-to-have.

That said, I couldn’t just open Claude Code and start yelling at it. I needed scaffolding. Structure. A way to translate “this doesn’t look right” into actual code changes.

So I built a claude.md file.

If you’re not familiar: claude.md is just a simple text doc that lives in your project’s folder of files. It tells Claude how your code is organized, what conventions you follow, and what you care about. I spent way too long researching what makes a good one (YouTube videos, tweets with traction, GitHub examples) and then used Claude itself to synthesize everything into something that actually made sense for my stack.

But a claude.md alone isn’t enough. You need to teach Claude what problems you’re solving.

To this end, I ended up building four custom skills before ever touching Claude Code:

1. Backend Patterns — How does the plumbing of the app actually work?
2. Feature Checklist — The non-negotiable things every screen has to do.
3. Scoring System — How points are calculated in the game (this is surprisingly complex).
4. Screen Conventions — What a properly built screen looks like in this codebase.

The magic happens because my claude.md has a “resolver” field. It listens for keywords. When I ask Claude to center a button or some text, it automatically reads the Screen Conventions skill. When I ask to change scoring, it reads the Scoring System skill. I don’t have to remember which skill to invoke, and I don’t have to bloat my claude.md with every possible piece of context upfront. I learned that the shorter your claude.md is, the better. You don’t want to flood Claude Code with too much information every time you use it. The resolver lets me keep it lean while still having all the context I need exactly when I need it.

The Setup

Ok without further adieu, here’s the actual setup I use:

• Software Tools
  • Ghostty as my terminal client. (The built-in terminal is fine too.)
  • Superwhisper for voice-to-text because I talk faster than I type. A keyboard shortcut starts and stops recording. You’d be surprised how much faster this makes things.
  • Notion. Project management and status tracking. (See below for details.)
  • Claude. Duh…
• My monitor
  • Claude Code CLI in one Ghostty pane (left half). This is where I actually prompt Claude to write and modify code. 
  • Expo dev server in another pane (top right quarter). This spawns a QR code I scan on my iPhone, which shows me a live version of the app with all my changes. Fantasy Futbol is a React Native app, so Expo is 1000% necessary for a non-technical human like me. 
  • SSH connection in a third pane (bottom right quarter). This is where I can jump into the AWS server and check logs, run database commands, or restart services.
• My laptop screen
  • Claude Chat in the desktop app inside a dedicated Fantasy Futbol project (full screen). This is my sensei and my quarterback, with full elaboration below.
• Background
  • Notion database where every bug, feature, and improvement lives. Fields for type, priority, status, who reported it. Screenshots where needed.
  • Notion status page that shows real-time development state: what’s done, what’s next, what’s deferred, what needs Sam’s review.
  • Stickies (see below)

That Claude Chat in the desktop app is the secret weapon.

Before each sprint, I invoke Claude to read my Notion status page and my bug database directly through the Notion connector. Claude has access to all the context it needs without me having to paste anything or manually explain what’s broken. It then builds me a concrete sprint and explains exactly what I need to prompt the three terminal instances to do. When something confusing comes back, I paste the output into Claude Chat and ask for the next step. It’s like having someone sitting next to you who knows the entire codebase and can explain what just happened. (B/c it is.)

Then Claude updates my Notion pages in real time. This sounds like a hack, and it is, but it’s a good hack. Without automatic updates, I would never keep records this detailed. The Notion connector in the Claude desktop app just... does it. No asking, no manual logging. I’m not going to lie, I didn’t even plan this. Claude desktop just did it once, and now I’ve routinized it.

I also have Stickies open to jot down random bugs or ideas that pop up mid-sprint. I don’t want to break momentum, so unless something is a blocker, I just record it (one per sticky) and paste them all into Claude Chat at the end to log for future sessions.

The Rhythm

I commit in bite-sized pieces with clear messages, then push straight to main.

I get that this is risky. But I’m trying to move as fast as possible and get changes into production ASAP. This is a game, not a medical device. I’ll learn more from breaking the app and fixing it than I ever will from being cautious. Sam can review the commits and merge them. I’m keeping them small and clear so it doesn’t require a ton of effort on his end.

In 30 hours, I shipped:

Monday, April 27 (11 fixes): League name header, match times with UTC fix, Matchweek label, keyboard Done button, rank wrapping, time two-line split, draft button color states, flag emojis in Draft and Rosters screens, round text centered.

Tuesday, April 28 (10 more): Keyboard push-up on all auth screens, logout in pre-draft state, back button on Name Your League, draft time in local timezone, Choose Draft Time button centered, minimum league size change (backend), persistent header styling, uniform spacing across tabs.

I caught them. I fixed them. I logged them. I validated them on my phone. I committed them. I pushed them. All in 30 hours. Bear in mind that included over six hours of sleep, and it’s only 2pm on the 28th.

The Philosophy

The reason this works is simple: I’m not trying to be a developer. I’m being a product person with tools that amplify what I actually understand. I know what looks wrong. I know what users need. I like to think I have taste. Claude handles the “how”(syntax, file structure, conventions). I validate the “what” (does it look right? Does it feel right? Does it solve the actual problem?).

I’m also okay with failing fast. Every bug fix teaches me something about the codebase. Every failed deploy teaches me how the infrastructure works. Every time I jump into the server and poke around, I understand the product a little better.

This is exactly the kind of work that shouldn’t be farmed out right now. I need to understand the app deeply so I can make good product decisions and talk intelligently with Sam about structural changes.

What’s Next

We’re shipping a new build that should address every single bug my family and friends have reported in the past few months. Once I validate that those fixes actually work in production, I’m sending a note to the entire waitlist: Download now.

That’s when things get interesting.

VAMOS