From "lean" to "clean, not lean"

In early November I wrote down a direction for every part of YuktiBOS. One line in it changed how we build: clean, not lean.

What lean meant

Through late October we were short of budget in two senses: weekly Claude usage, and AI spend. On 1 November my planning note showed 68% of the week's usage gone and about 32% left. The note listed a "Build B lean": results pulled automatically, always-on goals, a weekly review. We built "lean" versions of many things: lean retrieval, a lean v8 judge, budget-first recipes with one brief, one research pass, one writer and one reviewer.

Lean is not wrong. A lean judge call (see the post on the scorer) cut a calibration from about Rs 21 a piece to a target under Rs 4. But lean became a habit of cutting, and cutting hides problems for later.

What I wrote on 3 November

The direction, as recorded:

• Everything doable by AI end to end, and by a human with full structure and tools. If there is no AI key, the process still works: YuktiBOS is framework, infrastructure and steps; humans are creators, reviewers and posters.
• Clean, not lean. Clean means only what is needed on the screen now, with the anticipated next thing nearby. Never cut functionality. Build enterprise-grade foundations, not minimal ones that break when the system grows.
• Edit in place wherever it saves clicks.
• Data at home: build our own unless an outside service is far cheaper at scale. Own email for IIPTA volumes, yes. Own video hosting, no.
• Modular by role: every role gets a dashboard.
• A focus dial in the planner: lean on an aspect, now lead generation until January.

The distinction I care about: lean describes what you build. Clean describes what the user sees. A screen can be clean with plenty of function behind it. A build can be lean and leave a hole.

The same week, a correction

On 3 November, with usage at 98%, I told my team that all of three weeks' work had to fit in one week. The diagnosis I accepted was blunt: most of it is debugging and finishing existing pipelines, not new systems. The cause was a lack of upfront planning and research. The key research that helped came from Gemini and ChatGPT reports, not from Claude. The rule from then on: research existing software and best practice before designing any module.

Examples since then: the SEO competitor study, the editor comparison for the human-first mode (we chose Tiptap core, MIT licensed, and built our own comment and history layer, because the paid platform holds comments and track changes), and the decision not to switch to MongoDB. On 4 November I said: keep Postgres, and add one assembled, versioned client brief document, voice notes as files with searchable transcripts, and a content inventory table.

What "AI plus human can take over" changed

The most concrete change: a person can write any piece from a blank page, assign a writer, reviewer and poster, and the AI helps only when asked. With no AI key, everything works. A piece written by hand has no flow at all: the engine never composes or auto-starts it, and a test pins that. An approval is tied to one saved version. If the words change afterwards, the approval no longer holds.

One thing I noted when I wrote the plan: no blank "write from scratch" box existed in the product yet.

What went wrong

"Lean" cost us in two places. Cost-cutting before measuring quality moved the brief to the smallest model and made the most important step the weakest. And the lean mindset let features be built to the edge of what the first test needed, so a later spec review found six build steps in one spec rebuilding things that already existed.

What's still open

I cannot show a measure of "clean". It is a rule I hold the screens to. The human-first mode is partly built: the article workbench hand-over and "Mark as posted" exist, and the full mode is next on the list.

Numbers at a glance