All packsOffline Sync EngineSolve
dexie indexeddb not defined next.js server side rendering
next build prerenders client components once, on the server
A top-level Dexie/IndexedDB import throws indexedDB is not defined during Next.js's build-time prerender, even inside a component marked as client-only.
This is one of the things Offline Sync Engine already handles. Let your app keep working with no internet, then merge the changes correctly when it reconnects.
Is this you?
Marking a component "use client" tells React it can run in the browser, but Next.js's next build step still prerenders every page once on the server to generate its initial HTML -- including client components. A module that imports Dexie (or anything else that touches IndexedDB) at the top level throws indexedDB is not defined the instant that prerender runs, because there is no browser IndexedDB API available during a server-side build step, client-component marking notwithstanding.
Why this one is easy to get wrong
"use client" reads as a complete answer to "this needs the browser" -- it's the documented mechanism for exactly that -- so it's a reasonable but incorrect inference that everything inside a client component is safe to run only in the browser. The build-time prerender step that also executes client components is a Next.js implementation detail that isn't obvious from the client/server component mental model alone.
What you get instead
The demo page creates the sync engine inside a useEffect via a dynamic import ("../src/sync/browser") -- browser.ts is the only module in the pack that imports dexie-storage, and dynamic import() defers loading it until the effect actually runs in the browser, after mount, never during the server-side prerender. The two sync API routes additionally declare export const dynamic = "force-dynamic" so Next.js never tries to evaluate them (and the database pool they'd open) at build time either.
Source: ARCHITECTURE.md 'Next.js traps (pre-decided so the build passes first try)', item 1 — checkable in the pack you receive
How you actually use this
You don’t install a library or wire up an SDK. Your own coding agent builds the code in your project, and you keep it — no runtime dependency on us.
Step 1
Download and unzip
You get a folder: the docs that tell an agent what to build, a starting skeleton, and the test suite that decides when it's done.
Step 2
Open it in Claude Code or Cursor
Point your coding agent at the folder. Nothing to install, no account with us, no API key.
Step 3
Paste one prompt
The pack contains the exact prompt. Paste it as your first message and leave it alone — it works through the build itself, choosing a cheaper or stronger model per task.
Step 4
Run ./verify.sh
One command. It prints a pass or fail for every check. Green means the build is done — the same script we ran to produce the receipt on this page.
Typical build: about 12 minutes of your agent working, mostly unattended. Then you integrate the working module into your app the way you would any code you’d written yourself.
Why you can believe this
2 of 3 runs passedWe ran this pack from an empty folder 3 times and published exactly what happened — every check, the model, the token cost, the wall time. Not a testimonial, and not our opinion: the same verify.sh you run yourself. Read the full receipt →