The spec is the new SKU: why cross-border operators should care about spec-driven development
Cross-border e-commerce has quietly become a software industry. The Shopify theme you customized last Black Friday, the Amazon SP-API middleware that syncs inventory across three marketplaces, the TikTok Shop webhook handler that fires order events into your 3PL — none of that was written by a “tech company.” It was written by an ops lead, a freelancer, or an agency, and it now sits between you and revenue. So when I see a tool like EasySpecs launch with the thesis that “code review is dead, spec review is where quality lives now,” I don’t read it as a developer-tooling story. I read it as a warning about the operational debt accumulating inside every seller’s stack, and a preview of how the next wave of AI tooling will be governed. That governance question is the one cross-border operators are least prepared for.
What EasySpecs actually solves — and why it’s not a developer-only problem
The pitch, in the maker’s own framing, is that teams adopt AI coding agents, PRs pile up faster than anyone can review them, specs get written against a mental model of the codebase rather than the actual codebase, and things break silently because nobody documented what was actually there to begin with. That’s a direct quote from the launch post, and it describes something cross-border sellers experience constantly without naming it. Your agency ships a “small fix” to your Shopify checkout extension. Your FBA replenishment script stops writing to the right SKU field. Your Temu feed parser silently drops a variant. Nobody reviews the diff because nobody on your side can read the diff. Six weeks later you’re reconciling inventory discrepancies in a spreadsheet and blaming the 3PL.
EasySpecs attacks this with two workflows. First, it documents the codebase automatically — including the undocumented, nobody-wants-to-touch-it kind. The maker’s proof point is a pharmaceutical company’s legacy Delphi system, which is a genuinely useful signal because Delphi is the kind of language that makes modern tooling vendors run the other way. Second, it turns that understanding into specs with paired validators, so a spec can be checked against the app before anyone codes against it. The interesting design choice is the “oracles and rubrics” layer: as you write a spec, the tool suggests machine-checkable pass/fail oracles and human-or-AI-scored rubrics, so you’re not staring at a blank page trying to invent your own verification criteria.
Pricing is disclosed on the launch page: free to start with your own AI key, a Workbench tier at €5 per repo per month during launch pricing (normally €10), and a Factory tier at €150 per month where EasySpecs runs the AI side and gives you credits usable on any repo. The MCP server — confirmed by the team in the comments — lets coding agents download generated specs and mark them as implemented, which is the integration point that matters most for anyone running an agentic workflow.
The uncomfortable translation for e-commerce operators
Here’s the reframe I’d push on any seller running more than two custom integrations: you already have a “codebase,” even if you’ve never called it that. It’s the sum of Shopify Liquid overrides, Amazon SP-API scripts, Klaviyo flows with custom webhook logic, Zapier and Make scenarios, and whatever your agency built and never documented. When you hire a new agency or bring dev in-house, the onboarding cost is exactly the “specs written against a mental model of the codebase” problem the maker describes. You are paying for that gap in retainer hours and outage windows. A tool that generates ground-truth documentation from the code itself is, functionally, a due-diligence instrument. That’s a more compelling use case for a seller than for a SaaS engineering team, and I don’t think the launch page leans into it hard enough.
How it differs from the incumbent review and documentation stack
The obvious comparison class is code review and static analysis: GitHub Copilot for generation, CodeRabbit and Greptile for AI-assisted PR review, SonarQube for static quality gates, and Swimm or Mintlify for documentation. EasySpecs is not trying to win the PR-review race. Its bet is upstream: if the spec is grounded in the actual codebase and ships with validators, you don’t need to read every diff, because the diff was constrained before it existed.
That’s a meaningfully different posture from CodeRabbit, which reviews the PR after the fact, and from SonarQube, which enforces rules but doesn’t know your intent. It’s also different from Swimm, which keeps docs tied to code changes but is still fundamentally a documentation product — EasySpecs wants the spec to be the artifact that agents consume, not the doc humans read. The MCP server is the tell: this is built for a world where the reader of the spec is often a model, not a person.
Why Amazon sellers should care more than Shopify ones
If you’re a pure Shopify DTC brand with a clean theme and a handful of apps, your custom-code surface is small and your blast radius is contained. If you’re an Amazon FBA brand, the opposite is true. You’re likely running Amazon Seller Central alongside Helium 10 or Jungle Scout for research, a repricer like Aura or Sellerboard for margin tracking, an ERP or middleware layer for inventory sync, and a returns workflow that touches Amazon FBA policies. Every one of those is an integration with its own failure mode, and most of them were wired together by someone who has since moved on. When an SP-API change breaks your listing sync mid-Q4, “we don’t have documentation” is not an acceptable answer to your CFO. Spec-driven documentation is cheap insurance against exactly that scenario — and the €5/repo entry price is less than a single hour of agency time.
Where the math breaks
Two things give me pause. First, the pricing model is per-repo, which assumes your code lives in repos. Many cross-border sellers’ most fragile logic lives in no-code tools — Zapier, Make, Airtable automations, Shopify Flow — and none of that is a repo EasySpecs can connect to. The maker is explicit that the “context” is generated from code, which means the no-code layer of your stack is invisible to it. Second, the model convergence problem the maker admits to in the comments — needing six different models because validators kept failing in ways the agent couldn’t resolve — is a signal that the validation layer is genuinely hard, not a marketing line. That’s honest, but it also means your mileage on a messy legacy integration will vary. Ask for a pilot on your worst repo before you commit.
What cross-border sellers can borrow from the EasySpecs playbook
Even if you never touch the product, the operating principles transfer directly to how you run your stack.
Write the spec before you brief the agency. The single highest-leverage change a seller can make is refusing to approve a change request that isn’t written down. Whether it’s a new checkout upsell, a returns automation, or a marketplace feed tweak, the brief should state what “done” looks like in checkable terms. That’s the oracle/rubric idea applied to agency management, and it’s free.
Demand ground-truth documentation, not onboarding decks. When you inherit a codebase from a departing agency, the deliverable should include auto-generated documentation of what actually exists, not a slide deck describing what someone remembers building. Tools like Mintlify and Swimm can help, but the principle matters more than the vendor.
Treat your MCP-connected agents as junior contractors. If you’re already using Claude or Cursor to modify storefront code, you’ve effectively hired an agent that ships faster than you can review. The EasySpecs MCP server exists precisely because that’s the new normal. The seller-side equivalent is: never let an agent touch production without a written spec and a rollback plan.
Budget for the no-code layer separately. EasySpecs won’t document your Zapier zaps. Neither will most code-first tools. That gap is real, and it’s where a lot of cross-border operational risk actually lives. Maintain a manual inventory of your automations with owner, trigger, and failure mode — a spreadsheet is fine, and it’s better than nothing.
A note on the “spec review is where quality lives” claim
I think the maker is directionally right but overstates it. Code review isn’t dead; it’s been demoted from primary quality gate to secondary sanity check. For cross-border sellers, the practical implication is that your QA budget should shift upstream — into how you define requirements — rather than downstream into post-launch firefighting. That’s a real reallocation of time and money, and most operators haven’t made it yet.
Where my judgment says it falls short
The launch page is honest about scope in a way that most Product Hunt posts aren’t, but three gaps matter for this audience. First, there’s no evidence of e-commerce-specific validation — no Shopify, Amazon, or marketplace integration mentioned, which means you’d be using a general-purpose tool on domain-specific code. Second, the “Drift Specs vs Code” feature that would detect when specs and reality diverge is explicitly not yet in production, per the maker’s comment. That’s the feature that would matter most for a seller whose agency quietly changes things. Third, the accuracy question — “how accurate is the documentation when the codebase is really large and messy?” — got a soft answer: clients say it’s “better than most open source solutions out there,” which is not a benchmark. If you’re evaluating it, insist on a measured pilot against a repo you already understand.
The pricing nuance nobody mentions
€150/month for the Factory tier sounds trivial until you realize it only covers one repo’s worth of “we run the AI side” — and a typical cross-border seller’s stack spans multiple repos, plus the no-code layer that’s out of scope entirely. The true cost is the Factory tier multiplied by your repo count, plus the human time to review generated specs. That’s still likely cheaper than an agency retainer, but it’s not the €5 headline.
What I’d watch / test next
This week, do three things. First, inventory your custom-code surface: list every repo, script, and no-code automation that touches orders, inventory, pricing, or customer data, and mark which ones have no documentation. That list is your risk register. Second, pick your single worst-documented integration and run it through a free-tier trial of EasySpecs — connect the repo, bring your own AI key, and see whether the generated documentation matches what you believe the system does. If it doesn’t match, you’ve just found a bug you didn’t know you had. Third, write one spec for your next agency request using the oracle/rubric pattern: state the change, then state how you’ll verify it passed. Watch whether the MCP server and the promised Drift Specs vs Code feature ship in the next quarter — if they do, this becomes a genuine operational tool for sellers, not just a developer curiosity. If they slip, treat it as a documentation generator and nothing more.
