"I run production and operations…" — your 29 questions, answered.

It covers everything between signature and a live app: catalogue ingest and conversion checks, app design in your brand, Apple and Google developer account setup (in your name — see 4.2), store submission, storefront integration, QR asset generation for your print runs, and launch-week support. Yes, it can be staged — publishers typically split it across the onboarding period rather than paying on day one.

Whatever your payment provider charges you — we add nothing. Because checkout runs on your terms (your web checkout, in-app purchase, offline, or vouchers — your choice of mix), the processing relationship is yours: typically 1.4–2.9% + a small fixed fee per transaction with mainstream providers. We are not the merchant of record on your web sales, we don't sit in your money flow, and there is no Publish360 transaction fee. The only channel that carries a platform-level fee is in-app purchase, where Apple and Google set the terms (see 1.5) — which is why we make in-app checkout an option you control, not a default you're forced into.

If you enable in-app purchase, Apple and Google charge their platform commission — 15% for most publishers under their small-business programmes (under $1M/year through the store), 30% above that threshold. That's why we treat in-app purchase as one option in your checkout mix rather than the backbone: most publishers route the bulk of sales through their own web checkout (0% platform fee) and use in-app purchase selectively, where the convenience of one-tap buying justifies the margin. Recent regulatory changes (in the US, EU and elsewhere) increasingly allow apps to link out to external checkout; we track these changes and pass the benefit through to you as store policies evolve. You choose the mix — and can change it.

On your web checkout: you are. The sale happens on your storefront, on your terms, and the customer relationship — including the money — is contractually yours. That's a deliberate structural choice: merchant-of-record platforms (where the vendor takes the payment and remits to you) are simpler to start with but put your revenue, your customer records and your refund policy inside someone else's company. On in-app purchases, Apple or Google is the merchant of record, as on every app on those stores. On offline sales and vouchers, you are. If you'd rather not carry merchant-of-record obligations for digital VAT in some territories, we'll discuss the right structure at the demo — including where a merchant-of-record checkout for specific territories can be sensible (see 3.1).

Per title, by buyer territory. Your rights metadata governs where each title can be sold: a reader whose store territory (and payment/billing country on your checkout) falls outside a title's rights territories doesn't see it offered for sale. This mirrors how retailers enforce territoriality, with one advantage: the ledger of where each sale happened is yours, so a rights query from a co-publisher or agent can be answered with data rather than assurances. Note the usual boundary: territorial enforcement governs sale; a reader who legitimately bought a title while resident in-territory doesn't lose their library when they travel.

It follows the merchant of record, channel by channel. In-app purchases: Apple and Google are merchant of record and handle VAT/sales tax globally — that's the one real advantage of their commission. Your web checkout: you are the merchant, and digital VAT obligations are yours — which sounds worse than it is, because modern checkout stacks automate nearly all of it: EU sales run through a single OSS (One Stop Shop) registration; the UK, and US states with digital-goods nexus rules, are handled by your checkout's tax engine. If your finance team would rather not carry those registrations at all, options include routing specific territories through in-app purchase or using a merchant-of-record checkout for exports. We walk through your specific territory mix at the demo — this is a solvable plumbing question, not a strategic obstacle, but it deserves a real answer rather than a hand-wave, and your accountants should sign off the structure.

The reading experience is built on EPUB 3 and Readium — the open-standards stack that the accessibility community itself develops against — with adjustable typography, reflowable text, screen-reader compatibility and text-to-speech support. The EAA, in force since June 2025, makes accessibility a market-access requirement for ebooks and reading apps sold to EU consumers — and it applies to your app, so you should ask any platform vendor for a conformance statement, not a vibe. Ask us for ours at the demo. Two of the strongest vendors in adjacent markets publish WCAG 2.2 AA conformance; that's the benchmark this platform should meet or state its path to.

On your web checkout, your refund policy applies, within consumer law: in the UK/EU, the statutory 14-day cooling-off right for digital content is waived once the customer consents to immediate access and acknowledges losing the right — which is the standard, lawful pattern for ebook delivery, and the checkout flow implements it. Faulty content must always be refundable. In-app purchases follow Apple/Google refund processes, which they adjudicate. Subscriptions must be cancellable as easily as they're started (a legal requirement in a growing list of territories, and good retention hygiene anyway — a reader who can leave easily trusts you enough to come back). Our customer-care layer handles the reader-facing mechanics; your policy sets the rules.

Four content types in one library: ebooks (EPUB 3, reflowable and fixed-layout), audiobooks (streamed and downloadable for offline listening), video, and courses (structured multi-part content). One library, one reader identity, one set of engagement data across all four — which matters because cross-format bundles (ebook + audio + bonus video at one price) are among the strongest direct-channel offers, and are precisely what single-format retail channels can't assemble.

Readium LCP — the open, passphrase-free DRM standard developed by EDRLab, of which Eden Interactive is a member. Why LCP: it protects content with real encryption (unlike watermarking, which only identifies leaks after the fact) while treating readers like customers rather than suspects — no Adobe ID, no third-party account, no device-authorisation ritual that fails at 9pm on launch night. Why not Adobe DRM: it's a closed system with per-transaction costs, a reader experience that publishers' own support inboxes testify against, and a dependency on one company's licensing decisions. Why not watermarking alone: for some lists it's a reasonable choice, but most trade publishers and agents want encryption on frontlist. LCP is also what a publisher should want strategically: because it's an open standard, your protected files aren't hostage to any single vendor — including us.

Yes — books and audiobooks download for fully offline reading and listening, and a reader's library syncs across their devices (phone, tablet, web) under one account. Reading position, bookmarks and annotations follow the reader across devices. The design brief is simple: the reading experience must never punish the reader for having bought direct — anything Kindle makes easy, your app must make at least as easy, or the channel leaks trust.

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.

Adjustable type size and fonts (including dyslexia-friendly options), spacing and theme controls, reflowable text, screen-reader support, and text-to-speech — built on the EPUB 3/Readium stack that carries accessibility metadata through from your production files. If your EPUBs are born accessible, the app preserves that work; if your backlist isn't, the reading system's own affordances cover much of the gap. See 3.6 for the compliance position.

We prepare and manage the submissions on your developer accounts, and store review is our problem to absorb, not yours to learn: we know the current review guidelines, the reader-app category's specific rules (including what a reader app may and may not link to), and the documentation each store expects. Rejections in this category are almost always resolvable formalities — a metadata clarification, a screenshot revision, a purchase-flow adjustment — handled in days as part of onboarding, and the launch timeline we give you includes review contingency. Post-launch, every update goes through review the same way, invisibly to you. What you'd feel as existential risk alone — "Apple said no" — is, for a platform that ships app updates continuously, routine weather.

We do — it's a maintained platform, not a bespoke build. OS-version updates, security patches, crash fixes, store-policy compliance and feature releases ship to your app continuously, under your developer account, with no work from your team; you never inherit a codebase, a backlog or a maintenance invoice. This is the structural difference from agency-built apps, which are famously cheap to quote and ruinous to keep alive: the $104k–$325k build-it-yourself estimate on our pricing page is the entry price of that road — the 15–20% annual maintenance is the toll.

You get named support for your publishing team during UK business hours, with reader-facing customer care handled separately so your readers are looked after without consuming your staff's time. Uptime targets, response-time commitments by severity and support channels are all stated plainly in the service agreement — ask for the current figures at the demo and we'll put them on the record.

Both. The branded apps (iOS, Android) carry the full experience — offline reading, push notifications, the home-screen presence that makes the channel durable — and a browser-based reader covers desktop reading, readers who resist installing anything, and the instant gratification moment after first purchase. The strategic weight sits with the apps: a home-screen icon is a marketing channel; a browser tab is a session.

Either, deliberately. A house with one consumer-facing brand ships one app; a group with genuinely distinct audiences (say, a literary imprint and a children's list) can run separate branded apps on the same platform, each under your developer account, each with its own store listing and design. The decision rule we'd offer: separate apps only where audiences genuinely don't overlap — every additional app divides your install-base gravity, and one well-populated app usually beats two sparse ones. Imprint-level branding inside a single app (curated shelves, imprint pages) covers most group structures without the split.

You point us at your catalogue — ONIX feed, storefront export, or spreadsheet plus files — and ingestion, format validation and library setup happen during onboarding as part of the Launch & Onboarding Package. EPUB files are validated on the way in (broken files diagnosed and flagged back to you, not silently shipped), metadata is mapped from your existing records, and the "weeks, not quarters" launch timeline on our How It Works page includes catalogue load for typical mid-size lists. Day one, your app opens with your full catalogue — the "never starts empty" principle — because an app that launches thin trains its first users to never return.

Standard ONIX is the happy path: title, contributors, descriptions, pricing, rights territories, subjects and assets map from your existing feed, and ongoing changes flow through on the same feed rather than a second data-entry burden. If you don't run ONIX, structured exports work. The design principle: your existing metadata operation should feed the direct channel automatically — a channel that demands parallel data entry gets abandoned by month three, and we'd rather engineer against that than exhort against it.

Purchases made through your connected storefront — including historical orders — sync into the reader's app library on day one: a customer who bought ebooks from your website over the past five years signs in and finds them waiting. That's the "never starts empty" mechanism at the individual reader level, and it converts your existing customer file into your app's founding population. Purchases made at other retailers (Amazon, Kobo) can't be verified or imported — no platform can honestly promise that — but the QR-in-print mechanism (see 6.3) exists precisely to give those anonymous trade buyers a reason to appear in your channel with their next action.

Your website connects during onboarding: orders flow to the reader's app library automatically, catalogue and pricing stay in sync, and your checkout remains exactly where your customers already trust it. Common platforms such as Shopify and WooCommerce use pre-built connectors; custom and legacy sites connect via API — common and custom integrations are all within reach. The point of integrating rather than replacing: you've already paid — in money and SEO and customer habit — for a working website; a platform that demands you abandon it is charging you twice.

Yes — that's the design. Checkout on your terms means the four routes (your web checkout, in-app purchase, offline/point-of-sale, and gift vouchers/access codes) are a mix you choose and can rebalance, not a decision you make once at gunpoint. Typical pattern: web checkout carries the volume (0% platform fee), in-app purchase serves impulse and convenience where its margin cost is justified, vouchers and codes serve gifting, events and B2B, and offline/POS turns festival stands and launch events into app-acquisition moments. All four routes land content in the same reader library and the same ledger — one customer, one library, however they paid.

Yes: gift vouchers for consumer gifting, access codes for review copies, influencer campaigns, prize fulfilment and corporate gifting, and bulk code batches for institutional and B2B sales. Codes are more strategically interesting than they look: every redeemed code converts an anonymous recipient into a named reader in your data, which makes vouchers simultaneously a revenue product and an acquisition channel. Review-copy distribution through codes also replaces emailing unprotected PDFs to strangers — your publicity team's most cherished piracy tradition.

Pre-orders through your storefront flow through like any order, with content unlocking on publication day — and unlike retail pre-orders, you keep the customer relationship from the moment of the order, not the moment of delivery. Serialised release — chapters or episodes unlocking over time — is native territory for a platform with courses and structured content, and it pairs naturally with subscriptions (a serial is a retention engine). If serialisation matters to your list, raise it at the demo and we'll show the current state honestly.

No per-gigabyte surprises: hosting, streaming and download delivery are included in the platform fee. This is worth asking every vendor in this market, because audio delivery costs real money and some pricing models pass it through as usage fees that only appear when your audiobook programme succeeds. Flat and predictable is the design principle of our fee generally; audio is where that principle earns its keep.

Each print title carries a QR code (cover verso, endmatter, or belly-band — placement is yours) linking to that title's landing experience: bonus content, the app install, and an offer against the reader's next action. A bookshop customer — anonymous to you at the till — scans for the bonus content and becomes a named reader in your data. On rates: treat our calculator's defaults (10% scan, 20% scan-to-action) as sliders, not promises — real-world QR engagement varies enormously with the offer's strength and the placement's prominence, and single-digit scan rates on modest offers are common. Two design truths: the QR code is only as strong as what it unlocks (a naked "download our app" earns nothing), and even low single-digit rates are meaningful because these are readers acquired at zero marginal cost from sales you'd already made.

Usually not for digital — distribution and rep agreements typically cover physical trade supply and named digital retail channels, while your own direct consumer sales sit outside them — but "usually" is doing work in that sentence: check for any exclusivity language covering "all electronic sales" or similar in older agreements. Print direct sales (if you sell physical through your storefront) more commonly touch distributor terms, since fulfilment and trade-discount structures are implicated. Practical step: a one-page briefing to your distributor and reps before launch — framed accurately as a reader-data programme that grows overall demand for your titles, including the print they carry (see 7.4) — keeps partners inside the tent and has, in our experience, never made the situation worse.

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.