The questions publishers actually ask us — answered straight.

No — there are two components, and we'd rather you budget both from day one. The recurring cost is the platform fee: Launch at $650 per month ($6,500 if paid annually), Growth from roughly $1,300–$1,950 per month depending on catalogue and features, and Enterprise agreed per deal. The second component is a one-time Launch & Onboarding Package covering catalogue ingest, app design, store submission and launch support, which is agreed per publisher based on catalogue size and scope, and can be staged across the launch period. Beyond what you pay us: payment processing on your own checkout (typically 1.5–3% to your payment provider), and your own team's time to market the channel. We model all of this with you, on your numbers, at the demo — and hand over the spreadsheet.

Arithmetically: whenever 20% of your annual direct digital revenue exceeds our annual fee. At the Launch fee of $7,800/year ($650 × 12), the crossover sits at $39,000 of direct digital revenue; on annual billing ($6,500) it's $32,500. Below the crossover, a commission model is genuinely cheaper — and we'll tell you so, and suggest the cheapest sensible way to build toward it. Above it, every additional dollar of direct revenue widens the gap in your favour, because our fee doesn't grow with your success. A commission provider takes more from you in absolute terms every year your channel grows; that is precisely the wrong incentive structure for a channel whose whole purpose is growth. For comparison, typical commission models in this market charge 20% of gross or net revenue plus setup fees of £250–£750, forever.

Because it converts the app from a service you rent into an asset you own. The Apple and Google developer accounts determine, contractually and technically, who owns the store listing, the app's ratings and reviews, its install base, and its push-notification relationship with every reader who installed it. If the app lives on a vendor's account, then no matter what your contract says, leaving the vendor means leaving the asset: your readers' installed app belongs to someone else's account, and you start again. On your own account, a change of platform provider is an update your readers receive, not an app they lose. It costs you $99/year (Apple) and a one-off $25 (Google) — we set both up in your name during onboarding — and it is, in our view, the single most important structural question to ask any app vendor in this market. Most don't volunteer the answer.

Honestly: not on Kindle e-readers — Amazon's devices are a closed system that only Amazon's store can sell into, which is, of course, the business model this platform exists to counterweight. Your app runs on iOS and Android phones and tablets, and in the browser (see 4.13), which between them cover the overwhelming majority of digital reading. Some open e-ink devices (PocketBook, Boox and others) support Readium LCP, and LCP-protected files can be readable there. For readers who are devoted Kindle-hardware users, the practical pattern is: serve them audiobook, web and phone reading through your channel while continuing to sell them Kindle editions through Amazon — a direct channel doesn't require abandoning any reader where they are; it stops every reader being somewhere you can't see.

From assets you already own, in roughly this order. Your customer file: everyone who ever bought from your website gets an email that their library is waiting in the app (see 5.3) — for most publishers this alone seeds the first cohort. Your email list: subscribers get a reason to install (an exclusive, a bundle, early access — not just an announcement). Your print run: QR codes in every new printing turn bookshop buyers into app users at zero acquisition cost (see 6.3). Your authors: authors with live dashboards (see 2.7) promote the channel that shows them their own numbers. Your events and socials: vouchers and codes convert audiences you meet into named readers. What's deliberately absent from this list: paid acquisition. The flywheel is designed to run on owned assets first; ads are an accelerant for later, not the ignition.

You do — entirely, exportably, and under your own consent records. Readers who opt in to marketing did so under your privacy notice, to hear from you; we never email your readers for our purposes, never share them with other publishers, and never charge you to access your own list. This deserves a blunt answer because the market's default is the opposite: retailer channels give you no reader identities at all, and some platforms in this space treat your reader list as their asset with usage-based pricing for reaching it. The email list your channel builds may end up the single most valuable marketing asset your house owns; check any vendor's answer to this question against their data-export terms before believing it — including ours, which is why export is contractual (see 3.9).

You'd be inconvenienced, not destroyed — by design. The assets that matter survive independently of us: the app listing and install base live on your developer accounts; your reader data is yours and exportable at any time (test the export whenever you like — see 3.9); your content files are yours; and the DRM is Readium LCP, an open standard operated by an independent non-profit ecosystem (EDRLab), not our proprietary lock — LCP-protected libraries don't die with any single vendor. The platform's service — the running backend — would need replacing, and that's real disruption we don't minimise: readers' apps would need a successor platform behind them. But compare the failure modes across the market: a shared-app vendor's failure deletes your channel and your readers' libraries outright; ours leaves you holding the app, the audience, the data and openly-licensed content, shopping for a new engine rather than a new life. See 8.2 for continuity specifics.

You keep: the app (it's on your developer accounts — listing, ratings, install base), your readers (full data export: identities, consents, purchase history, engagement data — see 3.9), your content (your files, plus LCP-protected copies readable in any LCP-compliant system), and your storefront (it was always yours). Offboarding on 30 days' notice involves: final data export and verification, transfer of any operational credentials, and an agreed reader-communication plan for the service transition. What leaving costs you: the platform's running services (delivery, sync, analytics, care) until a successor is in place. What it doesn't cost you: your audience, your asset, or your history. We'd rather be kept by merit than by moat — and an exit this clean is only a risk to vendors who expect customers to want one.

We're early, and we won't pretend otherwise. We share adoption data from our founding publisher cohort at the demo, plus direct reference calls where publishers have agreed to take them. What we won't do is decorate this page with logos of houses that ran a pilot once. The platform's economics don't require you to take adoption on faith — bring your own catalogue to the demo and the evidence is your own titles, your own readers, your own numbers.

Seven questions, and we'll answer all of them on this page or at the demo: (1) Whose developer account is the app published under — and what happens to the install base if we separate? (See 4.2.) (2) Who is merchant of record, and does our revenue flow through your accounts? (See 1.10.) (3) What DRM do you use, and is it an open standard or your proprietary lock? (See 4.4.) (4) Who controls our reader data, under what DPA, and in what format do we get it back? (See 3.3, 3.9.) (5) What does exit actually involve — walk us through offboarding. (See 8.3.) (6) What are the total costs — setup, commission, transaction fees, delivery/bandwidth, and fee-growth as we grow? (See 1.1, 5.8.) (7) Show us adoption evidence from live publishers — or tell us honestly that you're early. (See 8.4.) We've published this list because the comparison genuinely favours structures like ours — and because a publisher who asks all seven of every vendor will make a good decision even if it isn't us. That's the confident version of candour, and it's the house style.