Notebook
Note
Download Markdown

Coding Approach Basic

5 min read
  1. Always start in Plan mode.
  2. Start with the simple prompt below.
  3. Fully plan out the application in a series of markdown files before you ever start coding.
  4. Review your plan using Simple Code Plan Review SKILL before you ever start coding.
  5. After you build (code) the app, have another AI review and critique it. If you built it in Claude code, have ChatGPT review it, and vice versa.
  6. Get a free Github account and set up a separate repo or repository for each project. Ask the AI to connect to the repo.
  7. Every time you make a major update (which the AI will write to a branch of your codebase, not the main), you need to do the following steps:
    1. Commit the branch to github. You can just say commit in the AI chat.
    2. Open a PR (which is a Pull Request). It documents all your changes in a document on GitHub, and it runs a series of tests (called CIs) to make sure the code is safe and error free. Once it passes those tests, the show green.
    3. Merge the PR (You can click the green button on GitHub or tell your AI to merge. )
    4. Deploy the change. Tell your AI to deploy it. That will push all the files through a Docker container out to your server. In my case, fly.io, but it could be Railway or Vercel or any server that uses Docker.

By using this approach (updates on branches, Commit, Open PR, Merge PR, Deploy) every change is trackable and reversible in GitHub, which will make your life a lot easier if you break things and need to take a step backwards.

A good app plan

A good app plan should be made up of several markdown files in a folder covering:

  1. Numbered prompts that will explain the spec and request the build. The prompts are numbered so that you can move through the building in logical phases, and you can save certain aspects for later.
  2. Design system. A document capturing all of your design choices. If you’re starting from scratch, use a GitHub app like Impeccable to build them. If you have an existing brand, then use the Setting Your Design Preferences to extract the brand and save it to a file.
  3. Technical documentation capturing the app architecture so that if you ever decide to involve a developer, they can read the technical documentation and understand how the app was built without having to read the code from scratch.
  4. User documentation on how the app works. If you also have admin users with special privileges, then you’ll need separate admin documentation. It’s much easier to build out your user and technical documentation as you build the app. Every time you iterate, you ask the AI to update the documentation at the same time.
  5. Context Log. A log file containing a 5–8 bullet summary of what the AI did in each session and what’s still open, each entry under a dated ## YYYY-MM-DD heading. Don’t tell the AI to read this file at the start of every session. It only ever grows, and once it’s a few hundred KB a single read costs you half a context window before you’ve typed anything — I made exactly this mistake and it cost ~112,000 tokens per session. Instead, have the AI grep the dated headings for an index and read only the range it needs. Here’s what went wrong and the two hooks that fix it.

Start with this simple prompt

Plaintext
Design and architect a secure web app that solves (describe the problem) and results in (success criteria).

DO NOT start working yet. First, ask me clarifying questions so we can define the approach together. Only begin once we've aligned. 

Capture the spec for this app in a markdown file saved to this folder. If the app is sufficiently complicated that it needs to be broken into phases, then create numbered prompt markdown files aligned to each phase. 

Start by designing the user interfaces and asking me to approve them. Design them one at a time in this order:

1. Home (which manages the Workflow described below)
2. Admin Dashboard
3. Sample output report
4. Other Admin pages like User Roles, Sessions, API, etc.

Use design.md as the design system for the design.

Every time we iterate on this app, append a 5-8 bullet summary of the work we did in this session and the next steps to a file called context-log.md in this folder, under a dated "## YYYY-MM-DD — what changed" heading. Never read that file whole — to catch up on history, grep the "## " headings for an index and read only the range you need.

DEVELOPMENT RULES TO FOLLOW
- I am not a developer — never assume technical familiarity
- Always explain what a command does before running it
- Present one clear recommendation, not a menu of options
- Auto-check Socket.dev before any npm package installs
- Prefer solutions that don't require me to maintain running processes or servers
- I hate copy-pasting into Terminal. I find navigating around folders in Terminal a pain. If you can get a CLI and post to the CLI with my approval, do that.
- Client apps must be hosted on Canadian servers (fly.io YYZ). 
- All HTML files, web pages, and email templates must be fully responsive and optimized for mobile (iPhone 14 portrait / 390px as the baseline). Use CSS media queries, fluid widths, and simplified mobile layouts — never fixed-width-only designs.

Later, you can move the Development Rules into your CLAUDE.md or AGENT.md (for Codex) file, so it’s a part of the AI’s persistent memory about you.

App Deployment:

Railway and Vercel are the most widely used but they are US based. Railway has a $5/mo hobby plan that I’m on. For apps that need Canadian hosting for privacy reasons, I use Fly.io and their Toronto YYZ data center. The pricing is similar to Railway and the AI manages the whole deployment through Github.