New: Fixed Bid Applications. See the packages

EffortlessAPI
Methodology

The Effortless Loop
& Shadle Steps.

A workflow for building software systems that don't drift. Rules live once. Everything else derives from them, deterministically, every time.

The Problem

Every change makes the next one harder.

When business rules live in code, prompts, tests, and documentation, every change forces someone (human or AI) to re-process meaning symbol by symbol. Drift compounds. Every sprint costs more tokens than the last.

Without the methodology

  • ×Rules scattered across backend code, prompts, tests, and docs
  • ×Every change requires re-deriving the same meaning in multiple places
  • ×AI agents spend tokens re-interpreting what hasn't changed
  • ×Drift between systems compounds with every sprint
  • ×No single source you can point to and say: this is what the business means

With the Effortless Loop

  • ✓One rulebook holds all business rules, the definitive source of truth
  • ✓Change the rule once; rebuild; everything follows deterministically
  • ✓AI agents operate on the rulebook, not on scattered code
  • ✓Derivative artifacts (schema, APIs, docs) regenerate from scratch on every build
  • ✓0 tokens spent re-deriving what hasn't changed

The Shadle Steps

Bootstrap.
Happens once, before the loop.

Named for the process of translating raw business understanding into a structured rulebook. You go through these steps once at the start of every project. After that, the loop takes over.

1

Stakeholder

The raw input

Start with conversations, tasks, and context. What does this business actually do? What are the nouns? This is where the work begins. Not with a schema, but with understanding.

2

Glossary

Creates the vocabulary

Build every domain term from scratch. A Customer, an Order, a Schedule, a Permission. Each defined precisely. This creates the vocabulary. Claude can help generate the initial glossary from stakeholder notes.

3

Narrative

General rules, not instances

Write rules in the general form: "Widgets have a color", not "Widget 1123 is red." Narratives describe what is always true about the domain, not specific instances of it.

4

Mock Data

Edge cases surface early

Define edge cases for every rule. One who is, one who isn't. Mock data forces you to confront the boundary conditions of the narrative before a single line of code is written.

5

Blueprint Sketch

One artifact in natural language

Glossary + Narrative + Mock Data combine into one artifact, in natural language. The project feels ready to build. The question is: what now?

After the Bootstrap: the Blueprint Sketch transitions into a structured Rulebook, the SSoT that governs everything from here forward. The sketch becomes ephemeral. The rulebook is now the source of truth.

The Effortless Loop

The repeating cycle.
Change rule. Build. Consume. Repeat.

The core insight: rule changes are entirely derivative. Change the rulebook, rerun tools, approve a PR. The build process eliminates the token exercise.

→

Change Rule

at the source

Every change begins in the Rulebook, the SSoT. New words become new tables. New columns become new attributes. No change touches code directly.

→

Build

effortless build

Run `effortless build`. The toolchain is deterministic: rulebook-to-airtable → airtable-to-rulebook → rulebook-to-postgres. Zero tokens. The output is always the same given the same input.

→

Consume

vw_* views

Application code reads from generated `vw_*` views and calls generated functions. Derivative code regenerates on every build. Delete it and it comes back, like obj/bin.

↺

Repeat

until done

The next change request starts the loop again. Stakeholder → new words in the Rulebook → build → consume → ship. The cycle is the methodology.

Deterministic

The same rulebook always produces the same output. No ambiguity. No interpretation. The build is a pure function.

0 tokens on rebuild

Derivative code is generated, not written. AI agents operate on the rulebook itself, not on the generated output.

UI/UX works on stable ground

The build process replaces the token exercise. Frontend work continues on a stable, predictable foundation that tracks schema changes automatically.

What a Rulebook Looks Like

Rules expressed once.
Derived everywhere.

Think of the rulebook as a spreadsheet expressed in three dimensions. A single source that says, definitively, what your business means: what a customer is, what makes an order valid, how a schedule gets built, how permissions work.

Once that rule lives in the rulebook, it doesn't live anywhere else. The database schema, the API behavior, the documentation, the instructions you give any AI agent. All derive from it.

Rulebook / Customer table

A customer is VIP if

  • -lifetime spend > $10,000
  • -OR referred 3+ paying customers
  • -AND account is in good standing

That rule doesn't live in five services. It lives once. Everything else follows from it.

Derived automatically on `effortless build`

vw_customer viewis_vip() functionRLS policySeed dataAPI documentationAgent instructions

Get Started

Learn the methodology hands-on.

Training sessions walk your team through both the Shadle Steps and the Effortless Loop against real work, not generic demos. The session fee converts to store credit.