Skip to main content
← Back to product plan

AI learning notes

Runway Calculator taught me how I want to build with AI.

The product is a simple runway planner, but the real value of this build was learning how to use AI as a steady product-building partner: choosing tools, shaping judgment, shipping artifacts, and documenting what actually worked.

Product as classroom

What this build was really for

Runway Calculator helped working professionals answer a stressful household question, but for BuildingPlanB it also became a controlled learning environment.

I used one focused product to learn the practical AI workflow underneath everything else I want to build: context setup, model choice, product judgment, export design, audit loops, and honest documentation.

Learning map

Four lessons I can reuse on the next product.

  1. 01

    Pick the stack

    Find the AI setup that keeps me moving

    The first lesson was not about the calculator itself. It was learning which model, coding surface, and agent setup gave me enough context without slowing daily execution.

  2. 02

    Shape the product

    Use AI to pressure-test the problem, not replace judgment

    Runway Calculator became a practical way to test framing, copy, edge cases, and user stress. AI helped explore options, but the product needed human taste and constraint.

  3. 03

    Ship the loop

    Turn rough ideas into a working public artifact

    The build taught me how to move from sketch to domain, sharing, PDF export, and UX hardening with AI as a daily collaborator instead of a one-off code generator.

  4. 04

    Keep the receipts

    Document where AI helped and where I had to steer

    The useful learning is in the tradeoffs: model limits, context quality, skills that fit, and the moments where shipped evidence mattered more than another plan.

Working notes

The AI workflow lessons

These are the durable takeaways from the build. They matter more to BuildingPlanB than a feature checklist because they shape how I will build every product after this.

  1. Learning 1: Choosing the core AI stack

    • I tested Claude, GPT, and Qwen with Ollama before picking the default stack.
    • I landed on GPT because Codex auth works smoothly with Openclaw, usage is reasonable, and code quality was more consistent for my workflow.
    • Claude stood out for understanding with less context, but usage limits and token burn moved too quickly for my build pace.
    • I subscribed to ChatGPT Plus so I can use auth with Openclaw and Codex for deeper development work.
  2. Learning 2: Openclaw setup per product compounds context

    • Setting up Openclaw agents per product improved context quality over time.
    • This was especially useful for copywriting, idea bouncing, and tightening smaller UX areas.
    • Openclaw on Discord feels natural because messaging supports fast back and forth loops.
    • It also lets me keep enough context while commuting, so I can continue improving copy and flow.
  3. Learning 3: Codex App and CLI serve different depth levels

    • I used both Codex App and CLI for deep work and compared them directly.
    • CLI felt more natural at first because my technical workflow is terminal-heavy and some skills were easier there.
    • As Codex App improved, I started using it more for selected product features and for this blog.
  4. Learning 4: Skills are useful, but fit is subjective

    • There are many useful skills, but fit depends heavily on stage, product size, and workflow style.
    • Some options felt like too much asking and too little output for this learning phase, though they may fit larger teams.
    • The skill that stayed consistently useful across products is impeccable.style.
    • From v3.0 onward, browser-based UI iteration plus one /impeccable command flow felt more natural in daily product work.

Shipped evidence

Progress matters because it proves the learning loop is real.

Source Notes

Key build-log entries behind the narrative and learning claims on this page: