Deming Live-Build Full Stack Iteration Method

Last updated: 17 August 2026

Apply Michael Deming's incremental, AI-assisted, write-it-yourself full stack development methodology to ship real features on a Python/FastAPI + React project without tutorial hell or framework abstraction paralysis.

// TL;DR

The Deming Live-Build Full Stack Iteration Method is an incremental, AI-assisted development workflow for shipping real features on a Python/FastAPI + React project without falling into tutorial hell or abstraction paralysis. You use AI as a Jarvis-style advisor while hand-writing every line yourself, write pure SQL instead of ORMs, precompute expensive aggregates during batch jobs, wrap mutations in transactions with rollback, and ship one small feature at a time. Use it when adding database columns, wiring them through the API, and surfacing them on the frontend while keeping your data pipeline clean and debuggable.

Method

// When should you use the Deming Live-Build Full Stack Iteration Method?

Use this skill when you are building a Python backend + React frontend project from scratch or iterating on an existing one, and need a structured way to add database columns, wire them through the API, surface them on the frontend, and keep your data pipeline clean — all while using AI as a Jarvis assistant rather than a code-paste machine.

// What do you need before starting a Deming Live-Build session?

Project descriptionrequired
What the app does — its core data pipeline, user-facing features, and target audience
Current blocker or feature to addrequired
The specific thing you are trying to build or fix this session (e.g. 'add an appearances column to the leaderboard')
Database schemarequired
Current table definitions — column names, types, relationships
Tech stack details
Python version, FastAPI, PostgreSQL or SQLite, React component structure, Docker usage
Known constraints
API rate limits, pagination limits, performance concerns, domain/cost limits

// What are the core principles of the Deming Live-Build Method?

Write It Yourself With Jarvis

Use AI the way Tony Stark uses Jarvis — to gather thoughts, outline plans, and guide you through learning — but always hand-write the code yourself. Copying and pasting from AI means you cannot go back in and fine-tune specific processes later without being completely lost.

Pure SQL Over ORM

Avoid ORMs that abstract away what is actually happening. Write raw SQL so you always know exactly what query is executing. This prevents the 'trust that it works but have no idea what is going on' problem that compounds at every layer of abstraction.

Precompute Aggregates in Batch, Serve Fast in the API

Never compute expensive aggregates on every API call. Run heavy calculations (like appearance counts or position statistics) during the nightly batch job and store the result as a column. The API just reads the cached value. This is a legit pattern: precompute during the pipeline, serve instantly at request time.

Incremental Update Over Full Recompute

When a nightly sync runs, increment the counter only for rows active in that run rather than recomputing the entire history. Full-table recomputes are O(N × history); incremental updates are O(N new rows). This scales cleanly forever.

Wrap Mutations in a Single Transaction with Rollback

Every database write sequence — insert then update, or save then increment — must be wrapped in one transaction. On any exception, roll back immediately so the connection is not left in a broken state. A failed query that is never rolled back will cause every subsequent request to fail with 'current transaction aborted, commands ignored until end of transaction block'.

No Feature Bloat — Little By Little

Resist adding every idea at once. Identify the smallest shippable unit of a feature (one column, one sort option, one filter button), ship it, confirm it works end-to-end, then move to the next. Fun ideas are noted but not built until the current feature is confirmed working.

SQL Injection Protection via Allowed-Sort Allowlist

Never interpolate user-supplied sort fields directly into SQL strings. Maintain an explicit allowlist of valid sort column names and map user input through that allowlist before constructing the ORDER BY clause. If the input is not in the allowlist, reject it.

Aftershock Debugging Discipline

When you see 'command ignored until transaction block' errors, recognize these are aftershocks — the root failure happened earlier and was never rolled back. Fix the root cause (the failed query) and add rollback-on-exception before hunting any other error.

// How do you apply the Deming Live-Build Method step by step?

1
Define the feature in one sentence and identify every layer it touches
State what you are adding (e.g. 'track how many times a leaderboard trader has appeared in our daily sweeps'). List all layers: database schema, batch pipeline, API query, frontend table, frontend sort/filter controls. Do not start coding until this map exists.
2
Update the database schema first
Add the new column with a sensible default (e.g. appearances INTEGER DEFAULT 0 NOT NULL). Drop and recreate affected tables during development to avoid migration headaches. In production, use ALTER TABLE.
3
Add the batch pipeline logic using incremental update, not full recompute
Write the SQL as: UPDATE leaders SET appearances = appearances + 1 WHERE address IN (SELECT DISTINCT address FROM leader_snaps WHERE run_id = [most_recent_run_id]). First fetch the most recent run_id via SELECT MAX(run_id) FROM leader_snaps. Only touch rows active in the current run. Do not recount all historical data every night.
4
Wrap the save + increment in a single transaction with rollback
Pattern: try → for each user: save user → if count_appearances flag is True: call update_leader_appearances(run_id) → commit → log success. Except Exception: rollback → raise. Finally: close cursor. The count_appearances flag lets you reuse the build pipeline for non-leaderboard paths without triggering the increment.
5
Expose the new field in the API query
Add the new column (e.g. leaders.appearances) to the SELECT clause of your get_leaderboard query. Add it to the allowed_sort_fields allowlist. Build a sort_field_map dictionary that maps the string 'appearances' to the safe SQL fragment 'leaders.appearances' and inject that — never the raw user string — into the ORDER BY clause.
6
Add the frontend sort option and table column
Add 'appearances' to your sort_options array so the button renders automatically via your existing sort-button mapping. Add a <th>Appearances</th> header and the corresponding <td>{row.appearances}</td> cell in the table body. No color formatting needed for a raw integer count.
7
Test end-to-end by dropping tables, rerunning the pipeline, then querying the result
Drop affected tables, restart the backend, run the full pipeline script. After completion, SELECT appearances FROM leaders WHERE address = '[known_address]' to confirm the column populated. Reload the frontend and confirm the appearances column appears and the sort button works.
8
Commit with a descriptive message that names the feature and the mechanism
Example: 'add appearances to leaders table; auto-increment appearances on sync'. Push to GitHub. Check the contribution heatmap to maintain momentum visibility.
9
Note follow-on features without building them yet
Log ideas (appearances-based secondary leaderboard page, toggle between views, mobile layout adjustments) as future session starters. Do not build them now. Avoid feature bloat.

// What do real examples of the Deming Live-Build Method look like?

A developer is building a data aggregation app that pulls from a third-party public API, stores processed statistics in PostgreSQL, and displays them in a React dashboard. They want to track how many times each entity has appeared in their daily data sweeps.

Add an INTEGER DEFAULT 0 appearances column to the entities table. In the nightly batch job, after committing the new snapshot, fetch MAX(run_id) from the snapshots table and run UPDATE entities SET appearances = appearances + 1 WHERE id IN (SELECT DISTINCT entity_id FROM snapshots WHERE run_id = [max_run_id]). Add appearances to the API SELECT and to the sort allowlist with a safe field map. Add the sort button and table column on the React side. Wrap save + increment in one transaction with rollback on exception.

A developer's API is returning 'current transaction aborted, commands ignored until end of transaction block' on every request after adding a new sort option.

Recognize this as an aftershock. The root cause is that an earlier query (likely the first request after the new sort field was added) failed — probably because the column did not yet exist in the database or the sort field was hitting the wrong table — and was never rolled back, leaving the connection in a broken state. Add try/except/rollback to the execute and query functions. Fix the root query error (check the column exists, check the table prefix in ORDER BY). Restart the server to clear the broken connection state.

// What mistakes should you avoid with the Deming Live-Build Method?

Copying and pasting AI-generated code without writing it yourself — you will not be able to fine-tune or debug it later because you have no mental model of what it is doing.
Running a full-table recompute of aggregate statistics on every nightly sync instead of incrementally updating only the rows active in the current run — this becomes O(N × history) and degrades over time.
Not wrapping save + update operations in a single transaction — a partial failure leaves the connection in a broken state and causes every subsequent request to fail with transaction-aborted errors.
Interpolating user-supplied sort field strings directly into SQL ORDER BY clauses — this opens SQL injection vulnerabilities. Always use an explicit allowlist and a field map.
Letting a failed query go without a rollback — the aftershock errors it produces look like new bugs but are just the original failure echoing.
Blindly following a third-party leaderboard at face value — one-trade 100% win rates and large unrealized losses hidden in open positions can make poor traders look like top performers. Compute your own metrics.
Feature bloat — adding multiple new features in one session before confirming the current one works end-to-end.
Naming database helper functions after the wrong abstraction (e.g. 'save_user' when it actually inserts into the leaders table) — mismatched naming creates confusion when refactoring.

// What key terms should you know for the Deming Live-Build Method?

Jarvis pattern: Using AI as an intelligent assistant to outline plans, explain concepts, and suggest approaches — while the developer still hand-writes every line of code. Named after Tony Stark's AI assistant. The developer remains the engineer; AI is the advisor.
Nightly sweep: The scheduled batch job that calls the third-party API, aggregates the full dataset of entities, computes statistics, and saves a snapshot to the database. Runs on a cron schedule (e.g. daily or every 12 hours).
Leaderboard snap / leader snaps: The snapshot table that records which entities appeared in each nightly sweep run, keyed by run_id. Used as the source of truth for computing appearances.
Run ID: A unique identifier for each nightly sweep execution. Used to scope incremental updates — only entities present in the latest run_id get their appearances incremented.
Appearances: An integer column on the leaders table tracking how many of the app's own nightly sweeps that entity has appeared in. A proprietary internal metric that cannot be obtained from the third-party API.
Precompute, serve fast: The pattern of running expensive aggregations during the batch job and storing results as columns, so the API only needs a simple SELECT at request time with no heavy computation.
Incremental update: Updating aggregate columns by incrementing (appearances + 1) only for rows active in the current run, rather than recomputing the aggregate from all historical data on every run.
Allowed sort fields / sort field map: An explicit allowlist of column names the API will accept as sort parameters, mapped to safe SQL fragments. Prevents SQL injection through user-supplied ORDER BY values.
Aftershock error: The cascade of 'current transaction aborted' errors caused by a single original failed query that was never rolled back, leaving the database connection in a broken state for all subsequent requests.
Count appearances flag: A boolean parameter on the build pipeline function that controls whether the incremental appearances update runs after saving the snapshot. Allows the same pipeline function to be reused for non-leaderboard data paths without triggering the increment.
Feature bloat: The mistake of building too many features in one session before confirming the current feature works end-to-end. Avoided by shipping the smallest testable unit and stopping.
Pure SQL: Writing raw SQL strings instead of using an ORM, so the developer always knows exactly what query is executing against the database.

// FREQUENTLY ASKED QUESTIONS

What is the Deming Live-Build Full Stack Iteration Method?

The Deming Live-Build Method is a structured workflow for shipping features on a Python/FastAPI + React stack by adding one small piece at a time across every layer — database, batch pipeline, API, and frontend. It emphasizes using AI as an advisor while hand-writing all code, writing raw SQL over ORMs, and precomputing aggregates during batch jobs so the API stays fast.

What is the Jarvis pattern in full stack development?

The Jarvis pattern means using AI the way Tony Stark uses Jarvis — to gather thoughts, outline plans, and explain concepts — while you still hand-write every line of code yourself. It keeps you as the engineer and AI as the advisor. Copy-pasting AI code leaves you unable to debug or fine-tune later because you have no mental model of what the code does.

How do I add a new column and wire it through my full stack app?

Define the feature in one sentence and list every layer it touches, then update the database schema first, add incremental batch pipeline logic, expose the field in the API SELECT with a sort allowlist, and add the frontend column and sort button. Test end-to-end by dropping tables, rerunning the pipeline, and querying the result before committing.

How do I fix 'current transaction aborted, commands ignored until end of transaction block'?

Recognize this as an aftershock error — the root failure happened in an earlier query that was never rolled back, leaving the connection broken for all subsequent requests. Fix the root query (often a missing column or wrong table prefix), add try/except/rollback to your execute functions, and restart the server to clear the broken connection state.

How does the Deming Method compare to using an ORM like SQLAlchemy?

The Deming Method deliberately avoids ORMs in favor of pure SQL so you always know exactly which query is executing. ORMs abstract away the actual queries, creating a 'trust it works but no idea what's happening' problem that compounds at every layer. Writing raw SQL keeps you in full control and makes debugging and performance tuning far more transparent.

When should I use the Deming Live-Build Method?

Use it when building a Python backend + React frontend from scratch or iterating on an existing one, and you need a structured way to add database columns, wire them through the API, and surface them on the frontend while keeping your data pipeline clean. It's ideal when you want AI as a Jarvis-style assistant rather than a code-paste machine.

What results can I expect from the Deming Live-Build Method?

You get features that ship reliably end-to-end, a codebase you fully understand and can debug, fast API responses because expensive aggregates are precomputed, and a data pipeline that scales cleanly because updates are incremental rather than full recomputes. You also avoid the transaction-aborted cascades and SQL injection risks that plague ad hoc approaches.

Why should I precompute aggregates in the batch job instead of the API?

Precomputing during the nightly batch job and storing the result as a column means the API only runs a simple SELECT at request time with no heavy computation. Computing expensive aggregates like appearance counts on every API call scales poorly and slows every request. Precompute during the pipeline, serve instantly at request time.

What is incremental update versus full recompute?

Incremental update increments a counter only for rows active in the current run (appearances + 1 for the latest run_id), which is O(N new rows). Full recompute recalculates the entire aggregate from all historical data every night, which is O(N × history) and degrades over time. Incremental updates scale cleanly forever.

How do I prevent SQL injection when users can sort by column?

Never interpolate user-supplied sort field strings directly into your ORDER BY clause. Maintain an explicit allowlist of valid sort column names, map user input through a sort_field_map that returns safe SQL fragments, and reject anything not in the allowlist. This is the only safe way to accept dynamic sort parameters.

Why should I write my own metrics instead of trusting a third-party leaderboard?

Third-party leaderboards can be misleading — a one-trade 100% win rate or large unrealized losses hidden in open positions can make poor performers look elite. Computing your own metrics, like tracking how many times an entity appears in your own nightly sweeps, gives you a proprietary, trustworthy signal you can't get from the external API.

// GET THIS SKILL — FREE