TL;DR — Four pieces this week land on the same nerve: most teams measure the wrong thing, and the spreadsheet they build for the review committee actively hides the number that decides whether the project survives.
The theme
Every item in this roundup is an argument about measurement. The replatform piece says TCO is a comfort metric and time-to-value is the decision metric. The unified commerce piece says feature checklists score everyone at 94% and hide the operational questions that separate a working platform from a rewrite in year three. The subagents piece says parallelism is the metric people cite and blast radius is the metric that actually matters. The ERP piece says real-time sync is what brands ask for and one-way sync plus reconciliation is what ships and stays shipped.
The common failure mode is picking a number that sounds rigorous, feels fair, and quietly measures the wrong thing. The common fix is cheaper than it sounds: write down the question you actually care about, then find the smallest honest way to answer it. The rest of the post is four examples of that, in domains that do not usually share a paragraph.
1. Time-to-Value Is the Only Replatform Metric That Matters (original)
Overview
Every replatform RFP leads with TCO. License, hosting, integration, support, professional services, laid out over three or five years in a table the CFO and procurement both love. The problem is that TCO is a vanity metric. It makes the decision feel rigorous without predicting whether the project will be worth it. The number that actually predicts success is time-to-value, measured honestly: days from project approval to the first feature a customer can feel — not the first feature deployed, the first feature felt.
Shopify has been hammering this drum as positioning against composable vendors, and the TTV gap between a Shopify Plus implementation and a full composable stack is usually months to quarters. For a brand whose roadmap depends on a new merchandising capability before the holiday window, that gap is the entire ROI.
Technical
Most teams measure TTV as contract signature to cutover. That is the middle of the story. The honest measurement starts at project approval and ends at the first customer-felt improvement. Usually it looks like two to four months from approval to RFP, two to four months from RFP to contract, six to fourteen months from contract to cutover, and one to three months from cutover to the first improvement customers notice. Teams report only the middle two segments. Real TTV on an enterprise replatform is twelve to twenty-four months, and the brands that beat their peers compress the bookends, not the middle. Consulting attention concentrates on the middle because that is where the margin is. The bookends are where the operator wins are hiding.
TCO answers a hypothetical: if everything goes according to plan, what will this cost? TTV answers a real one: when does this start paying back? A 15% TCO saving paired with a six-month TTV penalty usually loses more in delayed revenue and competitive ground than it gains in licenses. Vendors who win on TTV have an opinionated platform with a clear default path. Vendors who win on TCO have configuration flexibility that shows up as calendar time in the field. You are choosing whether to pay the bill in licenses or in calendar, and calendar is almost always more expensive than the spreadsheet implies.
Takeaway
On your next RFP, add a TTV column next to the TCO column and require every vendor to commit to a specific date for the first customer-felt improvement. Make the date contractual. Watch who prices differently and who retreats into hedging. Picking the lowest TCO with the worst TTV is how brands lose a year of competitive momentum to save a quarter of license fees.
2. Why Unified Commerce RFPs Keep Failing (original)
Overview
The failure mode of unified commerce RFPs is structural. The RFP is written by the team that will not have to live with the outcome. The team that will live with it is too busy running the current stack to participate. By the time they inherit the platform, the contract is signed, the SOW is locked, and the architecture decisions that will hurt them daily are baked in. The document itself is 200 pages of yes/no feature coverage across POS, commerce, OMS, CDP, loyalty, returns, reporting, and integration. Every vendor answers yes to almost everything. Four finalists all score 92 to 96%, and the decision falls to brand recognition and TCO.
Technical
The fix is a different RFP — operational questions that cannot be answered with "yes." A short version: Walk us through what happens when a customer who bought online returns an item in-store and the original tender method is not on file. Show us the exact API call to update a price across all channels in real time and the worst-case latency to the POS. What is the maximum decimal precision for inventory quantity, and how does the platform handle bundles, kits, and assemblies? How many person-weeks to enable a new marketplace channel, and what additional license fees apply? What does the migration path for loyalty look like, specifically tier history and accrual rules, not just balances? Show us the customer profile schema — which fields are first-class, which are custom attributes, which are JSON blobs. Walk us through the tax engine on a cross-jurisdiction in-store return of an online order. Finally, put us on a reference call with an operations lead at our scale, not a digital lead.
The second habit worth fixing is the sandbox bake-off. Bake-offs reward vendors who demo well in a controlled environment; they do not reward vendors whose platforms survive year three of a real deployment. A paid pilot with two finalists over six months, in a live store, graded by the operations team, costs more upfront and avoids the replatform-in-three-years tax. The retailers who consistently pick the right platform are the ones who pay for the pilot.
Takeaway
If you are running an RFP this quarter, throw out the feature checklist and send those eight questions to your shortlist. Score on specificity, not coverage. Demand reference calls with ops, not digital. If you are already on a platform that is underperforming, run the same questions against what you own — the answers will tell you whether you picked wrong, implemented wrong, or hit a real platform ceiling. Each of those has a different remediation and the feature audit will not distinguish between them.
3. Subagents as a blast-radius pattern, not a parallelism trick (original)
Overview
Most writing on subagents frames them as a parallelism trick — fan out, get more done in less wall-clock. That is a fine reason to use them and it is the reason Anthropic leans on in How we built our multi-agent research system. After a year of running autonomous agents on real codebases, I think parallelism is the third-best argument. The first is blast radius. Subagents are the only practical way I have found to keep one wrong-headed run from corrupting the workspace, the prompt history, the token budget, and the afternoon.
Technical
An agent with broad permissions, a long context, and a multi-turn loop can cause a lot of damage quickly. It can write to the wrong file, run the wrong command, poison its own context with an error trace it should not have read, or burn a budget reading a file it did not need. None of those are model failures. They are architectural failures — the question is what the agent was allowed to do, and the answer should be "as little as possible, in a place that can be discarded."
Claude Code: Best practices for agentic coding is the most operationally honest post on this. Use git worktrees so the agent has a clean directory of its own. Limit allowed tools to what the task needs. Keep sessions short. Be explicit about scope. My PR worker runs on exactly this pattern: every task gets a worktree under .claude/worktrees/agent-<id>/, launched with Read, Edit, Grep, and prefix-gated Bash:test/Bash:build — no generic Bash. When the subagent finishes, the worktree is pushed to a branch and removed, or removed without a push. There is no path by which a confused run writes to my main checkout, no path by which two subagents stomp on each other, and no path by which a stray rm -rf escapes the directory.
Pair that with filesystem and network sandboxing — the argument in Beyond permission prompts — and you have two layers of containment. The third layer is context. A subagent in a fresh context window cannot poison the orchestrator with a tangent it went on. Subagents return summaries; the orchestrator never sees the four debug turns before the answer. That alone keeps orchestrators from mimicking their subagents' failure modes over long runs.
Takeaway
Pick one agent loop you currently run and move it into a worktree this week. Do not optimize anything else. Create a fresh directory, run the agent there, delete it on exit. Then read the best-practices and sandboxing posts back to back and ask: what is the smallest set of tools this subagent actually needs, and how do I gate Bash so it cannot do anything I have not pre-approved? When you have answered both, you have a containment story. Parallelism is the bonus.
4. ERP Integration Patterns for B2B Commerce That Do Not Rot (original)
Overview
Every B2B brand past roughly $20M in annual revenue ends up with the same diagram: commerce on one side, an ERP on the other — NetSuite, Sage Intacct, Dynamics 365, S/4HANA, Acumatica, sometimes still QuickBooks — and a line between them labeled "integration" with no further detail. Under that line live the most expensive bugs and the slowest data decay in the business. The integration is fine for six months. By month eighteen, inventory levels are off, customer records are duplicated, order numbers do not line up, and nobody can find the source of truth for anything.
Technical
The integrations that age well share four properties. First, clear ownership — every data domain (products, customers, orders, inventory, prices) has exactly one authoritative writer. Every other system is a reader, and the reader's view is allowed to be slightly stale. "Both systems can write customers" is how you get a duplicate-customer problem in ninety days that takes a year to clean. Second, idempotent messages — every outbound event carries a stable source-system ID, and the receiving handler upserts against that ID. This is undergraduate-level distributed systems and half the integrations I have audited skip it, which is why they have a weekly "duplicate orders in NetSuite" Slack thread. Third, reconciliation as a separate layer — sync is the live wire, reconciliation is the safety net. Different code, different schedule, different alerting. Sync handles the last five minutes; reconciliation scans the last seven days end to end and surfaces deltas to ops. The integrations that rot have only sync, and the rot starts the first time a webhook fails silently. Fourth, explicit failure modes — malformed messages, unknown SKUs, duplicate emails go to a dead-letter queue with ops alerting, not a log line and a shrug.
Two warnings. Real-time bidirectional sync is what brands ask for and consultants sell, but it is the hardest pattern to keep working over years. The honest default is one-way sync per data domain plus nightly reconciliation, with inventory as a near-real-time exception handled by ERP-pushes-deltas-to-commerce plus a buffer stock setting. And point-to-point custom code — the NetSuite-to-Shopify integration a contractor wrote in 2022 — will be replaced, not because the code is bad but because the contractor is gone and the SKU-mapping logic left with them. Use an iPaaS even when it is more expensive, because it forces the integration to be expressed in a way another human can read.
Takeaway
This week, draw your integration diagram with five labels: products, customers, orders, inventory, prices. For each, write down the authoritative writer. Find any place where both systems are writing the same domain — those are your duplicate-record incubators. Pick the worst one, pick a winner, make the loser read-only, add a reconciliation report. Then check your dead-letter handling. If it does not exist, a single Slack channel alert is enough to catch the silent drops before they turn into a quarter-end cleanup.
Original sources
- Time-to-Value Is the Only Replatform Metric That Matters — originally published 2026-02-18
- Why Unified Commerce RFPs Keep Failing — originally published 2026-02-19
- Subagents as a blast-radius pattern, not a parallelism trick — originally published 2026-02-20
- ERP Integration Patterns for B2B Commerce That Do Not Rot — originally published 2026-02-21
