The real bottleneck in cross-border ops isn’t traffic — it’s the data plumbing nobody wants to own
Every operator I talk to is sitting on the same quiet problem. You’ve got a Shopify storefront, an Amazon Seller Central account, a TikTok Shop feed, maybe a Temu or SHEIN listing, plus Klaviyo for lifecycle, a 3PL or two, and a payment stack that spans currencies and chargeback rules. Each of those systems emits data on its own schedule, in its own shape, and none of them talk to each other without someone building a pipe. That someone is usually a freelancer, an agency, or the one ops person who knows SQL. When that person leaves, the pipe rots. This is why I pay attention when a tool tries to collapse the whole load-transform-schedule-serve stack into something a single technical operator can run locally. croft, launched by Zabaca, is a small but pointed attempt at exactly that — and even if you never install it, the design choices are worth stealing.
What croft actually is, and the problem it’s really solving
The maker’s own framing is refreshingly blunt: a “typical data stack is several tools glued together” — dlt or Airbyte to load, dbt to transform, Airflow or Dagster to schedule, and a warehouse to host it all, mostly in Python and YAML. croft’s bet is that a TypeScript developer who just wants a few tables updated hourly shouldn’t have to stand up four systems to get there.
The pitch, as posted: ingest from any API or CSV with an ingest() call in a .ts file that runs incrementally and is safe to rerun; transform per table via a .sql file or a TypeScript function, with checks that run before anything is saved; schedule with a single schedule: "every hour" string, with downstream tables updating in order; and serve by querying from any Bun or Node app, typed by table. Everything lives in one DuckDB file on your machine — no server, no account, no warehouse bill.
For a cross-border seller, the translation is direct. The “APIs” in that sentence are your marketplace report endpoints, your ad platforms, your 3PL webhooks, your payment processor’s settlement feed. The “CSV” is the weekly export your Amazon account manager emails you because the API doesn’t expose that field. The “checks before anything is saved” are the margin and inventory sanity checks that today live in a spreadsheet with conditional formatting and a prayer.
Two claims the maker is proudest of are the ones I’d flag for operators specifically. First, types across SQL and TypeScript: every table gets a type generated from its real columns, so renaming a column in SQL flags the TypeScript that reads it before anything runs. Second, it’s “built for agents” — you tell Claude Code what you want, it writes the pipeline, and croft checks every step, previews changes without touching your tables, and stops for your OK before anything could lose data. The maker is also honest about scope: one machine, one DuckDB file. If your team already runs a warehouse with dbt, keep it.
That last sentence is the most important one on the page, and I’ll come back to it.
Why Amazon sellers should care more than Shopify ones
Shopify operators have it comparatively easy. The Admin API is well documented, the data model is sane, and if you’re on Shopify Plus you can pipe orders and customers into a warehouse with a dozen off-the-shelf connectors. Amazon is the opposite. Amazon Seller Central report endpoints are notorious for rate limits, asynchronous report generation, and fields that appear in the UI but not in the API. TikTok Shop’s Partner Center is younger and less predictable. Temu and SHEIN give sellers far less programmatic surface area than either.
That’s precisely where a tool that treats “pull from any API, incrementally, safe to rerun” as a first-class primitive earns its keep. The value isn’t the transform layer — it’s the idempotent ingest. If your Amazon settlement report job fails halfway through at 2 a.m. and you rerun it, you need to know you didn’t double-count fees. Incremental-and-safe-to-rerun is the whole ballgame for marketplace data, because marketplace APIs fail constantly and nobody wants to babysit a cron job.
How it stacks up against the incumbents
Let me be concrete about the comparison set, because “we replace your data stack” is a claim that deserves scrutiny.
Against dbt: dbt is a transformation framework, and a very good one. It assumes you already have a warehouse and a loader. croft bundles transform with ingest and schedule, which is less powerful but dramatically less setup. If your team already runs dbt on Snowflake or BigQuery, croft is not for you — the maker says so himself.
Against Airbyte and dlt: these are loaders. Airbyte’s connector catalog is enormous and its cloud offering handles the operational burden; dlt is a Python library that’s elegant if your team writes Python. croft’s differentiator is the TypeScript-native, single-file, no-account posture. For a small DTC brand whose technical hire writes TypeScript for the storefront, that’s a much shorter on-ramp than teaching them Python and Airflow.
Against Airflow and Dagster: these are orchestration platforms. They’re the right answer when you have dozens of interdependent jobs, SLAs, and a platform team. They’re absurd overkill when you have four tables that need refreshing hourly. croft’s schedule: "every hour" string is a deliberate refusal to build a DAG editor, and for the target user that’s a feature.
Against the warehouse itself — Snowflake, BigQuery, Redshift: these bill by compute and storage and require someone to manage cost. DuckDB running locally on one file is the anti-warehouse. For datasets in the low millions of rows — which describes most single-brand order and ad data — DuckDB is genuinely fast and costs nothing.
The honest positioning is: croft is what you reach for before you have a data team, and what you migrate off of once you do. That’s not a knock. Most cross-border sellers are years away from a data team and are currently doing this work in Google Sheets with IMPORTRANGE and vibes.
Where the math breaks
Here’s my skepticism. “One machine, one DuckDB file” is a wonderful developer experience and a questionable operational posture. That file lives on somebody’s laptop. If that laptop is lost, or the person running it goes on vacation, or you need two people to query the same tables simultaneously from different machines, you’ve got a problem. DuckDB supports concurrent reads but a single writer, and a local file is not a backup strategy.
The maker is upfront about this — “it’s honest about scope” — but operators should hear it as a hard constraint, not a footnote. If your fulfillment reconciliation, your ad-spend attribution, and your inventory reorder logic all depend on a pipeline running on one person’s machine, you’ve concentrated operational risk in a way that will eventually bite you. The right pattern is probably: use croft for prototyping and for the pipelines that are genuinely personal-scale, and move anything that other people depend on to a hosted setup.
What cross-border operators should borrow from this, regardless of whether they adopt it
This is the part I actually want you to take away, because the tool is free and MIT-licensed but the ideas are what compound.
Borrow the idempotent-ingest discipline. Every marketplace data pull you run should be safe to rerun without duplicating rows. If your current process is “download the settlement CSV, paste into the tab, delete the duplicates by hand,” you have a correctness bug waiting to happen. The croft framing — incremental, safe to rerun — is the standard you should hold your existing scripts to.
Borrow the pre-save checks. The idea that validation runs before anything is written to the table is quietly excellent. In cross-border terms: before you trust an order row, check that the currency conversion rate is within a sane band, that the SKU exists in your catalog, that the destination country is one you actually ship to. Catching bad rows at ingest is far cheaper than discovering them in a margin report three weeks later.
Borrow the type-safety-across-layers instinct. The maker’s example — rename a column in SQL, get flagged in the TypeScript that reads it — is a proxy for a bigger principle: your downstream reports should break loudly when upstream schemas change, not silently produce wrong numbers. Marketplace APIs change fields without warning. Anything that forces those changes to surface is worth having.
Borrow the agent-with-a-guardrail pattern. The “built for agents” framing — Claude Code writes the pipeline, croft previews changes and stops for your OK before anything could lose data — is the correct shape for AI in ops tooling. Not autonomous, not fire-and-forget: propose, preview, confirm. If you’re evaluating any AI tooling for your stack right now, that’s the bar. Claude Code is the example here, but the pattern generalizes to every AI ops tool you’ll be pitched this year.
Borrow the honesty about scope. The maker telling you “if your team already runs a warehouse with dbt, keep it” is rare and worth rewarding. Most launch copy overclaims. When you’re evaluating tools for your own stack, weight the vendor that tells you who shouldn’t buy.
A note on the free-and-MIT detail
croft is free and MIT-licensed, installable with bun add -g @zabaca/croft, with a quickstart the maker claims takes five minutes. That pricing posture matters for cross-border operators specifically, because it means the cost of trying it is your time and nothing else. There’s no seat count, no warehouse bill, no procurement conversation. For a seller in Shenzhen or a DTC brand in Austin running lean, “free and runs on my laptop” is a genuinely different risk profile than “sign a contract and migrate your data.”
It also means there’s no support contract. If it breaks, you’re reading the source. That’s fine for a technical operator and a non-starter for a team without one.
Where my judgment says it falls short
I’ll be direct about the gaps, because the maker asked for them and because you deserve a real assessment.
Collaboration is unaddressed. A single local DuckDB file is a single-player tool. Cross-border ops is inherently multiplayer — the Amazon account manager, the 3PL liaison, the ads buyer, and the founder all want to look at the same numbers. There’s no story here for shared access, permissions, or a hosted read replica. That’s a real limitation for any team above one technical person.
The marketplace connector story is unproven. The pitch is “pull from any API,” which is true in the sense that you can write the API call yourself. But writing a robust Amazon SP-API client with pagination, rate-limit backoff, and report polling is real work, and “any API” means “you build the connector.” Compare that to Airbyte’s catalog of pre-built connectors and the tradeoff is stark. For a Shopify store the connector is trivial; for Amazon it’s a project.
DuckDB’s concurrency ceiling will arrive faster than you think. Single-writer is fine for one pipeline. The moment you want an hourly ingest and an on-demand ad-hoc query hitting the same file, you’re scheduling around a lock. This is a known DuckDB characteristic, not a croft flaw, but it caps how far the local-file model scales.
The agent story is a bet on a moving target. “Tell Claude Code what you want and it writes the pipeline” is compelling today and could be table stakes in six months. Building your operational dependency on a specific agent workflow is a bet on that workflow’s stability. The guardrails croft adds — preview, confirm — are the durable part; the agent integration is the part that will churn.
No hosted option means no SLA. For anything revenue-critical, you want a vendor who owns uptime. croft explicitly doesn’t. That’s a philosophical choice, and it’s the right one for the target user, but it means croft will never be the system of record for a serious brand’s financial reconciliation.
What I’d watch / test next
If you want to pressure-test this thesis this week, here’s what I’d do.
First, install it and run the five-minute quickstart against a genuinely annoying data source — not a toy CSV. Pick the marketplace report that currently costs you the most manual time. My bet is Amazon settlement or TikTok Shop order data. See how long it takes to get an idempotent, rerunnable ingest working. That single test tells you more than any review.
Second, time-box a prototype of the pre-save checks. Write down the three validation rules you’d want before trusting an order row — currency sanity, SKU existence, ship-to country — and see how naturally they fit the transform layer. If it’s awkward, that’s a signal about fit for your workflow.
Third, watch whether the maker ships any collaboration or hosted story in the next quarter. That’s the tell for whether croft stays a solo-operator tool or grows into something a two-person ops team can share. If a hosted read replica or a shared-file story appears, the calculus changes materially.
Fourth, and most importantly: whatever tool you end up using, steal the posture. Idempotent ingest, checks before save, loud failures on schema change, agent-proposes-human-confirms. Those four principles will improve your data plumbing whether you’re running croft, dbt, or a pile of scripts. The tool is free; the discipline is the actual upgrade.
