FOUNDER MEMO · 2026-05-18 · CONFIDENTIAL
The autonomous operator
for Amazon sellers.
We built it for our own toy company first. Twelve months in production. Now we're opening it up.
What this is
Imagiland Digital is two things at once.
A toy company. Twelve ASINs, three Amazon marketplaces, ~€10k/month and growing.
And the operating system that runs it autonomously. A self-optimizing machine — AOCC — that ingests SP-API data, makes pricing, bidding, inventory, and listing decisions, and writes them back to Seller Central without human keystrokes.
The toy company is the proof. The operating system is the product.
We are raising to productize the operating system into Operator —
a service that runs Amazon businesses for other sellers, with a transparent control-lever UI that lets each business owner choose how much of their account they hand over and how much they keep in their hands.
We do not sell software. We sell outcomes.
PART 1
The thesis
Amazon is broken for the people who sell on it.
Amazon is a closed system with ~250 levers per seller, ~30 of which are operationally hot every week — bids, budgets, placements, negatives, prices, coupons, restocks, listing copy, A+ content, FBA inbound, brand store, Vine, deals, dayparting, anomaly response, account health, IPI, EPR, customs, refund disputes.
These levers compound. A small bid move affects placement, which affects CVR, which affects organic rank, which affects inventory burn, which affects IPI score, which affects ad eligibility, which affects bids. The whole thing is a coupled control system. No human can hold the model in their head.
The market response has been incomplete.
Agencies
$3k–$15k/mo per account. Humans clicking buttons. Bad incentive, bad scaling, bad consistency.
Single-purpose SaaS
Helium 10, Pacvue, Perpetua. One slice — keywords, bids, listings. Sellers still have to operate.
Amazon itself
Built to maximize Amazon revenue, not seller margin. Conflict of interest by design.
What's missing.
A single integrated operating system that sees every lever simultaneously, makes coordinated decisions, and presents the seller with outcomes, not dashboards.
PART 2
The product
Operator runs the account.
The seller signs up. OAuth into Seller Central. From that moment, Operator runs it:
Advertising
Bids, budgets, search-term harvesting, negatives, dayparting, placement modifiers, B2B, brand defense, cross-sell.
Pricing
Price optimization within margin guardrails, coupon scheduling, Prime Exclusive, deal eligibility.
Inventory
Reorder triggers, lead-time tracking, FBA inbound planning, IPI management, stranded cleanup.
Listing
Title/bullet/description optimization, A+ content, image testing, video pipeline, brand store.
Compliance & logistics
VAT, EPR, EU DoC, customs broker coordination, FBA shipment docs.
Account health
Case management, refund disputes, anomaly alerts, suspension reinstatement.
What Operator is not.
- Not a dashboard. Dashboards diagnose. Operator writes back.
- Not a SaaS subscription. We charge a % of managed revenue, not for software access.
- Not an agency. No humans in the loop on routine decisions.
- Not a black box. Every decision is logged, reversible, and explained.
- Not "AI for Amazon." Not a chatbot, not a copilot. An operator. It does the thing.
The control levers
Most automation says "trust us." Operator says "you choose."
Autonomy mode
Three tiers per domain — Ads, Pricing, Inventory, Listing, Compliance.
- Auto — Operator executes. Notified weekly.
- Propose — Operator drafts, seller one-tap approves.
- Manual — Seller drives. Operator advises only.
All five domains can run on different tiers. Change anytime.
Aggression dial
One slider, –3 to +3. Maps internally to ~30 parameters the seller never sees.
−3 = preserve cash · 0 = balanced · +3 = grow at all costs
Guardrails
- Max ACoS per ASIN
- Min margin per ASIN
- Daily ad spend cap / marketplace
- Auto-pause if spend > €X with 0 sales
- Approval required for changes > €Y
Pause
One button. Account into observe-only mode within 60 seconds. Used for vacations, supplier issues, account health flags.
The trust layer
Imagi Pulse — proof-of-life, not metrics. Four panels.
01
Pulse
Green / yellow / red per domain. One sentence each. If everything is green, nothing else needs to be said.
02
Decision queue
Every decision Operator will make in the next 24h. One-tap approve / reject / edit. Empty queue is the goal state.
03
Cause → effect
Last 7 days of actions, each linked to its measured outcome. "Bumped bid €0.42 → €0.48. Result: +18 clicks, +6 orders, ACoS 22%→19%."
04
The Number
One big number per week. Projected takeaway profit + delta vs last month + confidence band. Everything else is supporting evidence.
PART 3
What already exists
This is not a slide. It is shipped code running in production on Imagiland Digital.
Operational receipts
PART 4
Market
Who Operator is for
1. The €1M–€5M Amazon seller (year-1 target). Owner-operator. Can no longer hold the system in their head. Paying an agency or burning evenings in Seller Central. ~25k of them in Europe.
2. DTC brands expanding to Amazon. Shopify-native. They want "Amazon, handled."
3. Portfolio aggregators / holding cos (Y2-3). Where the data network effects compound hardest.
TAM
- Amazon EU 3P GMV: ~€140B
- Amazon worldwide 3P GMV: ~$550B
- Sellers doing €1M+: ~80k globally
- Sellers doing €100k+: ~600k globally
At 4% avg fee on managed GMV, capturing 5% of the €1M+ segment = €1.6B annual revenue ceiling. Realistic 5-yr: 1,500–3,000 sellers, €40–€90M revenue.
Why now
SP-API parity
Write access for ads/listings/inventory/pricing finally end-to-end usable.
LLM cost collapse
NL listing optimization, dispute drafting, anomaly explanation all sub-cent.
Agency model shaking out
Post-COVID services bubble correcting. Sellers want outcomes, not retainers.
EU compliance burden
DMA, DSA, GPSR, EPR. Sellers can't absorb it. Operator absorbs it as a feature.
Aggregator winter
Thrasio collapse. Hundreds of brands need operating partners that aren't acquirers.
No category leader yet
The shape we're building does not exist on the shelf today.
PART 5
Business model
Pricing — sold as a managed outcome
Performance fee
% of managed gross revenue, tiered:
- 4% · first €50k/mo
- 3% · €50k–€250k
- 2% · above €250k
Floor
€500/mo minimum. Covers the seat and infrastructure.
Outcome bonus
10% of margin lift vs the seller's 12-mo trailing baseline. Capped at 2x the performance fee. Earned only if YoY margin improves.
Unit economics
PART 6
Defensibility
Coordination layer
The hardest engineering problem in this space is making 30+ rules not fight each other. We have it shipped, with collision detection, rollback, and dry-run. Single-purpose tools cannot retrofit this.
Data depth
13 months of SP-API mirroring across 3 marketplaces + regulatory (Avask, Lizenzero, customs). Plumbing = 6 months. Signal extraction on top = years.
Outcome contracts
Once a seller is on % of GMV, they have zero incentive to leave for a flat-fee tool that requires their attention. We make the alternative more expensive than us.
Network learning
Every seller's negative harvest, anomaly response, and search coverage feeds the policy. Per-account isolation of decisions, shared learning on patterns. At 100 sellers the system knows things no individual seller can.
PART 7
Financials
Revenue projection — base case
Cost projection
Break-even ~M22. Contribution-positive per-account from day one; J-curve is engineering hiring and CAC payback.
PART 8
The ask
€1.2M seed · €6M pre-money · €7.2M post
24-month runway. Series-A readiness at M18 — 200+ sellers, €2M+ ARR, 90%+ gross retention.
Use of funds
Hiring priorities
- Senior engineer — distributed systems, multi-tenancy, billing
- GTM lead — Amazon-services market, agency relationships
- Customer success lead — seller psychology, account migration
- Fractional compliance / legal counsel — EU + UK
OPERATING DOCTRINE
"The seller's job is to make decisions about their business. Our job is to make every other decision so well that they never have to think about it. If a seller is logging in to Seller Central, we have failed."
APPENDIX A
The master prompt
For bootstrapping Operator on top of the existing single-tenant AOCC stack.
You are building Operator — a multi-tenant autonomous operating system for
Amazon FBA sellers, productizing the existing single-tenant AOCC stack that
runs Imagiland Digital.
Architecture must satisfy these invariants:
1. MULTI-TENANCY
- Every table that holds seller data has a tenant_id (UUID) column with a
foreign key to tenants(id). No row-level mixing is permitted.
- Postgres row-level security (RLS) policies enforce tenant isolation at
the DB layer, not just at the application layer.
- SP-API credentials are stored encrypted-at-rest per tenant, in a
dedicated secrets table, never in environment variables.
2. WRITEBACK SAFETY
- Every action that modifies Amazon state goes through a 3-stage pipeline:
(a) propose: write to actions_pending with a dry-run JSON payload
(b) coordinate: run the coordination_layer check (does this action
conflict with any pending or recently-executed action?)
(c) execute: only if coordination passes AND tenant.autonomy_mode permits
AND tenant.guardrails pass, call the SP-API.
- Every execution writes an actions_executed row with the full diff
(before/after) and a 30-day reversibility plan.
- The 5 domains (ads, pricing, inventory, listing, compliance) each have
their own autonomy_mode column on the tenant_settings row:
ENUM('auto', 'propose', 'manual'). Default 'propose' on signup.
3. CONTROL LEVERS
- tenant_settings table has:
aggression INT CHECK (BETWEEN -3 AND 3) DEFAULT 0
autonomy_ads / autonomy_pricing / autonomy_inventory /
autonomy_listing / autonomy_compliance ENUM(...)
max_acos_pct / min_margin_pct / daily_ad_cap_eur per marketplace
approval_threshold_eur DEFAULT 50
paused BOOLEAN DEFAULT FALSE
- The aggression slider maps to ~30 internal parameters via a single
pure function: aggression_to_params(int) -> struct. Implement once,
in /lib/policy.
4. TRUST LAYER (Pulse)
- Pulse is a single React page with 4 panels:
Pulse (green/yellow/red per domain)
Decision queue (actions_pending, one-tap approve/reject/edit)
Cause -> effect stream (actions_executed JOIN outcome_measurements
on 7-day post-window)
The Number (projected month profit + delta + confidence band)
- Pulse is read-only on the data side; all writes go through /api/v1
which enforces RLS + autonomy_mode + guardrails.
5. ONBOARDING
- OAuth via Amazon Login With Amazon (LWA) for SP-API.
- 7-day mandatory shadow mode: Operator runs in 'propose' for every
domain regardless of seller's chosen mode. Builds trust before any
writeback.
- Migration import: pulls last 90 days of orders, ads, inventory,
finance events on signup. ~15-min wait. Status page with progress.
6. BILLING
- Stripe Connect for outcome-aligned billing.
- Monthly invoice = floor + (managed_gmv x tier rate) + (outcome_bonus)
- outcome_bonus = 10% x max(0, current_month_margin - baseline_margin)
where baseline_margin is the trailing-12-month avg before Operator
onboarding, locked at signup.
- Display every invoice line linked to the actions that caused the
measured outcome.
7. CODE LAYOUT
/apps
/pulse - Next.js seller-facing app (the only seller UI)
/ops - Internal admin / customer success app
/services
/ingest - SP-API workers (one per domain)
/coordinator - coordination_layer + dry-run engine
/executor - writeback workers (idempotent, retryable)
/billing - Stripe Connect + outcome accounting
/pulse-api - read API for Pulse (RLS-scoped queries only)
/lib
/policy - aggression -> params, autonomy gates, guardrails
/sp-api - wrapped Amazon SP-API client (per-tenant auth)
/coordination - collision detection
/attribution - cohort + cause->effect linking
/db
/migrations - sqitch-style migrations, every change reversible
/policies - RLS policies, one file per tenant-scoped table
/infra
/cloudflare - Pages config for /apps/*, Workers for edge functions
/vps - postgres + ingest workers (existing AOCC bones)
8. NON-NEGOTIABLES
- Never trust the seller's tenant_id from the client. Always derive
from the authenticated session.
- Never log raw SP-API tokens, even at debug level.
- Every writeback must be reversible within 30 days OR explicitly
flagged 'irreversible' to the seller before execution.
- The Pulse "Pause" button must take effect within 60 seconds and
halt every in-flight worker for that tenant.
- All decisions logged in actions_executed must be human-readable in
under 200 characters. No internal IDs in the seller-facing log.
9. STARTING POINT
- The single-tenant AOCC stack lives at
/Users/giesinpa_air/.../10_Dashboard/amazon_api_dashboard/aocc/.
Treat it as the reference implementation. Multi-tenant Operator
is a rewrite, but the domain logic (rules engine, coordination
layer, attribution) is port-and-tenantize, not redesign.
10. DEFINITION OF DONE FOR M3 (seed milestone)
- 5 design-partner sellers onboarded end-to-end.
- Pulse shipped, used weekly by all 5.
- 0 cross-tenant data leaks (audited by RLS test suite that
simulates a hostile tenant trying to query other tenants' rows).
- 0 Amazon account warnings caused by Operator actions across the 5.
- First invoice cycle billed via Stripe, outcome bonuses calculated.
- Onboarding self-serve (no founder-in-the-loop activation for
sellers 6+).
Build it. Test it. Document it. Ship it.