Part 3 — Shipping · 14 min read
Your weekly rhythm
How to work week to week, what 'good' looks like, and when to bring in a real developer.
The founders who succeed with these tools aren't the ones who learn the most syntax. They're the ones who build a rhythm and keep it, so that progress compounds instead of oscillating between heroic weekends and stalled fortnights.
A week that works
| When | What | Why |
|---|---|---|
| Start of week (30 min) | Pick the one slice you'll finish this week. Write it down. Everything else goes in GitHub Issues. | Without this you'll drift between five half-features and finish none. |
| Each session (2 min) | Read your handover note. Fresh session. State the one thing you're doing. | Cheap, clean context beats trying to resume yesterday's mess. |
| During (constant) | Small steps. Check in the browser. Commit. Repeat. | The only way to know which change broke something. |
| End of session (5 min) | Commit, push, write a handover note, add any new gotcha to CLAUDE.md. | Turns a 20-minute restart into a 30-second one. |
| End of week (30 min) | Deploy. Use your own app as a user for ten minutes. Write down what annoyed you. | You stop seeing your own product's rough edges within about two weeks. |
What good actually looks like
You won't be able to judge code quality, and you don't need to. These are the proxies that work for a non-technical founder:
- You can find things. Given a feature, you know roughly which file it's in. If your project has become an unnavigable pile, that's a real warning sign.
- Things look consistent. Buttons look like other buttons. Two pages doing similar things work similarly. Inconsistency means the AI wasn't following existing patterns — usually because it never saw them.
- Changes stay local. A change to the booking form shouldn't break the dashboard. When it does, things are too tangled.
- You can explain it. If you can describe what happens when a user signs up — which files, what order, where the data goes — you're in control. If you can't, you're a passenger.
- Your commit history is readable. A diary of small, described changes.
Learning as you go
You have a patient expert available at all times. Use it deliberately rather than only when stuck:
- Ask "why" after every change. "Why did you do it that way rather than the obvious way?" Two minutes, and it compounds.
- Have it explain its own output. "Walk me through this file line by line as if I know HTML and CSS but not React."
- Keep a questions file. Every term you don't recognise goes in it. Once a week, ask for all of them to be explained together.
- Read one file a week properly, with the AI explaining as you go. Fifty-two files a year is a real education.
When to bring in a developer
Not a failure — a normal, sensible move. The short version is below; When to get tech advice covers the triage in full, along with how to brief someone and how to judge whether they're any good.
| Situation | What to get |
|---|---|
| You're about to take payments or store sensitive data | A few hours of security review. Cheapest insurance you'll ever buy. |
| Stuck more than a day with no progress | An hour of someone's time. Almost always solves it. |
| You have paying users and downtime now costs you | Someone on retainer who can respond when it breaks. |
| You need something genuinely specialist — real-time, video, payments at scale, anything regulated | A contractor for that piece specifically. |
| You've validated and you're building the real thing | A technical co-founder or a first engineer. |
Be straightforward about how it was built, and prepare properly before the conversation — both covered on When to get tech advice.
The failure modes to watch for in yourself
- Building instead of selling. The most common one. Building is comfortable and feels productive; talking to strangers about your product doesn't. The build is not the business.
- Polishing before validating. Nobody churns because of your border radius. They churn because your product doesn't solve their problem.
- Adding features instead of finishing them. New features are exciting; empty states and error handling aren't. Users experience the boring parts constantly.
- Never showing anyone. If nobody outside has used it, you're not validating — you're decorating.
- Believing the AI's summary. "I've implemented and tested this" needs your eyes on it. Every time.
Act as a pragmatic technical advisor doing a weekly check-in with me. Look at this project — the code, the recent commits, the state of things.
Tell me:
1. What actually changed this week, based on commit history rather than what I think I did.
2. What's half-finished and at risk of being abandoned in an unusable state.
3. Where the codebase is getting messy: duplication, inconsistency, files that are getting too big, patterns that have drifted.
4. What's accumulating that will bite me in a month if I ignore it.
5. The single most valuable hour of cleanup I could do next week.
6. One thing I'm doing well that I should keep doing.
Be honest rather than encouraging. I'd rather hear it now.I want to actually understand what I've built rather than just owning it. Design me a 4-week self-study plan based on THIS specific project.
Each week: one concept, the specific files in my project that demonstrate it, and a small exercise where I change something myself and predict what will happen before I run it.
Start from what I know — HTML, CSS, basic layout — and build up. Prioritise concepts by how often they appear in my code, not by what a computer science course would teach first.
For each concept, tell me: what it is, why it exists (what problem it solves), what the code would look like without it, and the mistake beginners make with it.I'm a non-technical founder who built this app with AI tools. I want to hire a developer for [a security review / a specific feature / ongoing help].
Write me a brief I can send to a freelancer. Include:
- What the app does and who it's for
- The stack and how it's deployed
- What state the code is honestly in, including anything I should flag as messy
- Exactly what I want them to do, and what's out of scope
- What I can and can't do myself, so they know how to communicate with me
- The questions they'll probably ask, with answers prepared
Then tell me what a fair price range is for this kind of work, what a good response from a contractor looks like, and three warning signs that I've found the wrong person.I have limited time and I keep being tempted by new features. Help me decide what to work on next, based on evidence rather than enthusiasm.
Here's what I know:
- What users have actually said or done: [paste feedback, analytics, support messages]
- What's currently half-finished: [list]
- What I'm tempted to build: [list]
- My riskiest remaining assumption: [describe]
Give me:
1. What to do next, and why that specifically
2. What to finish before starting anything new
3. What to delete or abandon outright — be willing to tell me to kill something
4. Which of my tempting ideas are procrastination dressed as progress
5. What I should do this week that isn't building at all
Push back on me if I'm avoiding talking to users.For your next five sessions, finish every one the same way: commit, push, handover note saved to docs/, one line added to the "bitten us before" section of CLAUDE.md. Five minutes, no exceptions.
You'll know it worked when starting a session takes you thirty seconds instead of twenty minutes of "where was I". The habit pays for itself by about session three.
Run the weekly review prompt. Read it properly. Then pick the single cleanup it recommends and do it — with the AI, in a fresh session, on a branch.
You'll know it worked when you've merged a change that adds no features but makes the project easier to work in. Getting comfortable with this kind of work is what stops a six-month project collapsing under its own weight.
Not friends. Five people in your actual target market. Watch them use it — screen share if you can't be in the room — and say nothing while they do. Write down every moment of hesitation.
You'll know it worked when you have a list of things to fix that you would never have guessed. This is the exercise most founders skip, and it's worth more than every other exercise in this guide combined.
Record yourself explaining, for two minutes, what happens technically when a user signs up and does the main thing your app does. Which files, what order, where the data goes, what could fail.
You'll know it worked when you can do it without notes. If you get stuck, that's exactly the part to study next — and you now have a specific, useful question to ask.