Flying Banana Productions
⏱ 00:00

2026 Summer Studio · Flying Banana Productions

When the Prototype
Is the Product

AI tools for prototype development — and what happens when the line between “a quick demo” and “the real thing” quietly disappears.

Stephen Palmer · Founder & Technical Director

I was asked to talk about no-code tools and landing pages.

I’ll cover that — but what I really want to share is what a year of building with agents taught me: the line between a prototype and a real product has gotten surprisingly thin.

Who’s talking

25 years
shipping
software.

  • Former Director of Development at Unity Technologies — the world’s leading real-time 3D platform.
  • 15+ years as a professional game developer: level design, programming, production.
  • Shipped titles in the Half-Life, Halo, Brothers in Arms, Borderlands, and Call of Duty series.
  • Led teams of 100+ with multi-million-dollar budgets and global publishing partners.

The pivot

From teams of 100+
to a studio of one
that ships like a team.

Flying Banana Productions — highly customized, cost-effective software for sports, entertainment & beyond, where deep domain knowledge is critical. Run solo, built with AI agents as the workforce.

This past year taught me: the cost of building real software has collapsed.

So the old question — “prototype it cheap, or build it for real?” — stopped making sense for me. Increasingly, it’s the same motion. This talk is the story of four projects, and the method that grew out of them.

Where it started · 2025

Knox
Challenger

The official companion app for the ATP Challenger Tour professional tennis event in Knoxville — live scores, draws, schedules, tickets, and an on-site practice-court reservation system for players and tournament staff.

Knox Challenger app — live scores

Shipped to the App Store & Google Play · live for the Nov 2025 tournament

Tournament week, by the numbers

564
app users
333
ticket transfers
297
court reservations
~1,100
commits, solo
  • Native mobile + a live proxy onto the official ATP API + a user/ticketing backend — shipped to both app stores.
  • Built alongside the people running it: an operations training manual for staff, a dozen dated build sessions, static-HTML venue displays.
  • 297 practice courts booked through the app — “in lieu of texting Julie.”
  • The post-tournament wish list — an SMS interface, email optional — became the seed of the next product.

The lesson

Agents amplify your velocity…
and they amplify your mistakes.

Going fast with AI is easy. Going fast without the wheels coming off is an engineering problem. Knox Challenger taught me I needed a method — not just a faster keyboard.

How I work

5x-engineer

Moving pretty fast
without breaking things.

the working method I distilled into a manifesto — and a CLI

The shift I felt

I stopped typing.
I started bringing
the taste.

  • Agents turned out to be faster — and often better — than me at writing the code, the docs, the tests.
  • What’s left is what they can’t do: taste, empathy, product judgment, architecture, quality control.
  • I became the gate at every checkpoint — instead of the bottleneck at the keyboard.

My loop

1 · Design & build from plans

PRD/TDD first, decomposed into a doc graph agents can navigate. Then a phased plan with checklists — one branch and PR per phase, each sized to a clean context window.

2 · Two models, not one

An author agent writes; a different frontier model reviews it like a Staff Engineer. No self-review bias.

3 · Model-agnostic on purpose

No LLM vendor lock-in. The workflow treats models and harnesses as interchangeable parts — a new model can slot in the week it ships.

4 · Human-gated

The reviewer loops “not ready” until issues (P0/P1/P2) are closed. I approve, archive the artifacts, merge.

Guardrails I won’t skip

Because agents amplify mistakes, I stopped treating the boring fundamentals as optional.

They’re what let me move fast on purpose.

  • Source control + one branch/PR per phase
  • Automated deploy pipeline
  • Containerized local testing
  • Fast test suites + coverage gates
  • Pre-commit / pre-push hooks
  • PR validation before merge

The number

Roughly a week’s worth of traditional output… per day.

“5x” is the midpoint of a measured, quality-adjusted range — pulled from a month of my own git history (commits, PRs, tests, migrations, reviews), not a benchmark. Deliberately not “10x.” The tool is published as a CLI — @5x-ai/5x-cli.

I fully expect the number — and the tooling — to be obsolete within the year. That’s half the fun.

Build #1 · the scale-up

Player
Desk

A multi-tenant SaaS court-booking platform for tennis venues — book by SMS, AI chat, or web, with sub-100ms bookings and real-time schedule sync. Built from scratch with everything Knox Challenger taught me.

PlayerDesk web dashboard

playerdesk-production.up.railway.app · live

The pilot partner

Knoxville Racquet Club — booking courts by paper and telephone since 1961.

1961
established
500+
active members
29
courts · 10 indoor
  • One of the oldest and largest tennis clubs in town — and PlayerDesk will be their first digital booking platform.
  • We’re modernizing desk operations together: paper time-tracking retired, a 24-hour mobile court calendar for members, back-office systems connected for accurate time billing.
  • Their operation is full of subtleties the design has to capture — the deep-domain work an off-the-shelf product would struggle to absorb.

Ambition compounds

2,294
commits
185
PRs merged
<100ms
p95 booking
142
web routes
  • Multi-tenant Postgres with exclusion constraints + serializable transactions enforcing the performance target.
  • Four front doors: an SMS rules engine, an AI natural-language assistant (Claude + MCP), a web dashboard, and a venue-local desktop shell with auto-update.
  • Real regulatory engineering — which is where the prototyping story gets interesting…

Static HTML in the wild

To send a single SMS, US carriers make you prove how users consent.

  • We built dedicated 10DLC “evidence pages” — public HTML pages with real opt-in screenshots — mapped field-by-field to Twilio’s carrier-registration form.
  • Two separate compliance programs, each with its own reviewer-facing page; SMS stayed feature-flagged off until carrier approval landed.
  • That’s “build a landing page / basic functionality” — in service of a real business gate, generated fast.
10DLC compliance evidence page

/compliance/a2p-member-auth

Build #2 · new domain, new stack

CHIEF

Constraint-based Helper for Intelligent EM Forecasting — desktop software that generates optimized shift schedules for an Emergency-Medicine residency program, replacing a chief resident’s manual Excel grind.

CHIEF — generated block schedule

Electron desktop app · local-first · constraint solver + LLM assistant

Mockups before code

Agents drove Pencil through its MCP server — the customer approved the UI before a line of it was built.

CHIEF Pencil mockups — Block List and Block Setup (chief.pen)

9 screens authored in Pencil (chief.pen), agent-driven via its built-in MCP server · reviewed screen-by-screen by the Program Director · the shipped UI traces directly back to these frames

Domain knowledge can’t be faked

The scheduling truth arrived as years of hard-won wisdom — not as a spec.

5
hospital sites
6
resident types
19
shift types
~50
plain-language rules
  • What the program handed me: a 13-block sample-schedule workbook, a master shift-requirements ruleset, a five-page explainer, and a plain-language “scheduling desires” document.
  • Rules like “protect Wednesday didactics, 9:30–3:00” · “FM PGY-2 keeps Thursday/Friday 6a–2p — it matches clinic” · “Smithfield is overflow only: EM before TY before FM.”
  • Hard constraints, conditional eligibility, soft preferences, a 13-step priority order — all of it institutional memory.

Plain language in, solver constraints out

The old cost

Codifying this much operational nuance was traditionally an enormously expensive analysis-and-engineering project — the kind that kills a tool like this before it starts.

The new pipeline

LLMs capture, translate, and refine the hard and soft constraints from plain language — then distill them into data a cheap, deterministic, offline solver can process.

The surprise, for me: it’s more efficient to let agents write and refactor the constraints as code than to build all the abstractions a “purely data-driven” solver would need. A rule change arrives in plain English and turns around in hours — and someday the built-in assistant may morph its own constraint logic.

Build #3 · the pure prototype

Deed
Lineage

A title archive for the Scarlett Oaks tract in Blount County, TN — reconstructing the chain of title across 70 years of land ownership, as a searchable, mappable static site.

Deed Lineage — parcel map

Static HTML · hosted on Cloudflare Pages

The exception that proves the rule

No customer to iterate with — so I became the domain expert.

  • Hours in the county deed registrar’s office, pulling 80+ physical deed records by hand.
  • Each scan paired with machine-readable metadata: parties, dates, book/page, acreage, metes-and-bounds, prior-deed links.
  • An agent can read a deed. It can’t drive to the courthouse and find the right one.
Scanned deed record and metadata sidecar

92 deeds · 1956 → present

Day one · the riskiest question

Can an LLM turn 1950s metes-and-bounds prose into real geometry?

  • Day 1 was a spike — a small desktop tool built to answer exactly that question. It could.
  • Only then did the site happen: a presentation-only layer over the data that evolved into the full demo — plain static HTML on Cloudflare, iterated over about a week.
  • Agents did the fuzzy work — vision and parsing, via custom skills and parallel workflows; deterministic scripts did the geometry; I approved at named gates.
deed-map prototype — parcels georeferenced onto satellite imagery

the day-1 spike, grown into a georeferencing editor · 89 deeds, 54 parcel nodes placed

This presentation is a static HTML site, built with agents, hosted on Cloudflare.

Same toolkit as Deed Lineage. No PowerPoint. You’re looking at the prototype-that’s-the-product right now.

it even re-skinned itself to match each product as we went — a few CSS variables per act

What it all adds up to · 1

Agents build fast.
The moat is still human.

Every one of these four projects lived or died on domain knowledge and real-user iteration — tournament staff, a program director, a courthouse basement. The code was never the hard part.

What it all adds up to · 2

Plain static HTML is the most underrated prototyping tool you have.

PlayerDesk

Evidence pages that cleared a carrier compliance gate.

CHIEF

Agent-driven mockups a customer could approve before code.

Deed Lineage

A whole product demo — static, hosted, polished — in a week.

This deck

The talk you’re watching.

The part you were promised

When to code
vs. use a tool

A practical framework for an early founder — most of you with a team of one to three.

Reach for a tool / no-code when…

  • You’re validating — pre-product-market-fit, testing demand.
  • It’s a landing page, form, or waitlist — the page is the deliverable.
  • The work is throwaway or a one-off.
  • An off-the-shelf tool is your product surface (Stripe, Airtable, Typeform).
  • You need it today and nobody will maintain it.

Reach for (agent) code when…

  • You have a real domain edge the tool can’t express.
  • You must own the data & logic (compliance, IP, lock-in risk).
  • Performance, scale, or regulation are real constraints.
  • The prototype is going to become the product.
  • You’ll integrate deeply with other systems over time.

A field guide · summer 2026

You need…Reach forWorth knowing
A marketing site or landing pageFramer · WebflowFramer for speed and polish; Webflow when CMS or e-commerce control matters
A working app from a promptLovable · Bolt · v0They generate real React/TypeScript you own — export to GitHub, graduate it later
A complex web app, no codeBubbleThe most capable classic builder — real learning curve, and the app isn’t portable
Internal tools on spreadsheetsGlide · SoftrGlide sits on Sheets; Softr turns Airtable into member portals
To sell thingsShopify · SquareCommerce is a solved problem — don’t rebuild it
Glue between systemsZapier · Airtable · NotionThe generic 80% of ops — automate before you build

…but the line moved

Agents made real code cheap enough to prototype in.

The old reason to pick a no-code tool was speed. When you can stand up real, owned code in an afternoon, you can often get the speed and keep the foundation. Start with static HTML to prove the idea — then graduate the same project into the real stack, with the same workflow.

Monday morning · a starter toolkit

The agents you already have

  • Claude, ChatGPT, Codex — the apps, used like a power user: attach your real documents, ask for working static HTML, iterate out loud.
  • Ready to own a repo? Any agentic coding tool — Claude Code, Codex CLI, Cursor… the method transfers.

The rest of the kit

  • Static HTML + Cloudflare Pages — the fastest real artifact you can make, hosted free.
  • Pencil — mockups a customer can approve before you build; no-code for the generic 80%.
  • A second model as reviewer — don’t ship work one agent graded itself.

…and the one that matters most: go get the domain knowledge a model can’t.

If you remember three things

  • The cost of real software collapsed — prototype and product are one motion now.
  • Speed without discipline is a trap — a method (and dual-model review) is what keeps the wheels on.
  • Agents commoditize code, so your domain knowledge and taste are the moat.

You bring the taste.

Stephen Palmer · Flying Banana Productions
flyingbananaproductions.com

QR code — this presentation online take this deck with you

Questions →

01 / 01

Deck controls

→ Space
next slide
←
previous slide
S
presenter view + notes
O
overview grid
T / R
timer start-pause / reset
F
fullscreen
Esc
close overlay
?
this help