"I run the publishing house…" — your 39 questions, answered.

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.

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.

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.

Yes — it's your checkout and your price file. Publishers use direct pricing three ways: matching retail (simplest, no channel-conflict questions), premium bundles (ebook + audiobook + bonus content at a price no retailer can assemble), and direct-first editions or early windows at full price. What we'd caution against is systematic undercutting of retail on identical products: it invites trade friction (see 7.1) and trains readers to see your channel as the discount bin. The stronger play — and the one the whole platform is designed around — is to make the direct edition worth more (exclusive content, formats bundled, early access) rather than cost less. Note that if you sell any titles under agency terms, your agreements may constrain retail price relationships (see 7.3).

Thirty days' notice, no long-term lock-in. If you leave, you keep the app (it's on your developer account), your reader data (full export), and your content; see 8.3 for exactly what offboarding involves. We think notice periods are a test of confidence: a vendor that needs to lock you in for three years is telling you something about how it expects you to feel in year two.

Partly — and that's fine, because a cannibalised sale is worth more to you. When a reader buys from you instead of a retailer, your net receipt on that unit typically rises by 30–50% (see 1.8), so even a fully cannibalised sale is margin-accretive. But three effects mean direct channels are not zero-sum in practice. First, the QR mechanism converts print buyers — people who already bought through the trade — into digital app users, which is additive, not substitutive. Second, exclusive content and bundles create purchases that don't exist at retail. Third, subscription income is a category retailers barely offer for your list at all. The honest position: some substitution happens, it's profitable substitution, and the channel's growth comes mostly from purchases the retail channel was never going to generate. Model both cases in the calculator — set the substitution assumption as high as you like and watch what it does to net margin.

Three, honestly. Marketing time: the channel succeeds on audience-building — budget a few hours a week of marketing attention for push campaigns, email, QR placement in new print runs, and promotion planning; publishers who treat the app as shelfware get shelfware results. Royalty administration: one-off work to confirm your contracts cover direct and subscription sales (see 2.1), and a small recurring addition to royalty runs. Finance setup: confirming VAT treatment in your main territories (see 3.1–3.2). What you should not budget: developers, hosting, app-store liaison, DRM licensing, or customer-care infrastructure — that's what the platform fee buys. No new headcount is the honest claim; no new hours would not be.

Most modern trade contracts do — the grant of rights typically covers sale of electronic editions "through any channel" or "by any means" — but you should verify before launch rather than after, and three clause families deserve attention. Grant of rights: confirm electronic/verbatim rights are granted to you without channel restriction; older contracts occasionally name specific retailers or "third-party retail channels" in ways a cautious reading might not stretch to direct sales. Royalty basis: direct sales pay on net receipts in most contracts — confirm the definition of net receipts doesn't produce anomalies when the receipt is 100% of cover price (see 2.4). Approval and consultation clauses: some contracts require consultation on "new forms of exploitation." The practical approach taken by publishers launching direct channels: audit a sample of contract vintages, fix forward (new contracts explicitly cover direct and subscription), and communicate openly with agents for the backlist (see 2.5). We provide a checklist of the clauses to review — but your own lawyers make the call.

Lead with the three things agents actually care about: more money per copy (higher net receipts flow through to royalties — bring the per-unit arithmetic), better data (real reading and sales figures per title, visible on demand, instead of opaque retailer aggregates), and a publisher investing in the author's long-term audience (a reader relationship that follows the author's next book, instead of being re-rented from a retailer every launch). Be ready for two questions: the royalty-rate question (see 2.4 — have a policy) and the subscription-allocation question (see 1.7 — have a basis). Publishers who bring agents a one-page direct-channel policy before being asked report the conversation becomes an asset — it signals professionalism in a market where most publishers still can't answer.

They're different legal animals. Public-library lending runs through library suppliers under licence terms you set, and (in the UK and some other territories) triggers PLR payments from the state — none of which changes with your direct channel. An in-app "library-style" subscription (e.g., any three titles at a time) is simply a commercial subscription with a borrowing mechanic: it's a sale under your subscription terms, allocated to authors like any subscription revenue (see 1.7), with no PLR involvement. The naming similarity confuses; the accounting shouldn't. If you sell to actual libraries or institutions, access codes and bulk licences are handled separately (see 5.6).

You are the controller of your reader data; we process it on your instructions under a data processing agreement. That's the legal expression of the platform's core promise — the reader relationship is yours. Reader personal data (identities, emails, purchases, reading behaviour) is collected under your privacy notice, used for your purposes, and exportable by you at any time; we don't use your readers for our own marketing, don't sell data, and don't commingle your readers with other publishers' audiences. Your DPO gets a DPA with a named sub-processor list (see 3.4). Contrast this with shared-app and marketplace models, where the vendor is often controller or joint controller of your readers — which is precisely how publishers ended up renting their own audiences back.

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.

You take it with you; it was yours throughout. On termination you receive a full export of your reader data — identities, contact details (with consent status), purchase history, and reading-engagement data — in standard machine-readable formats (CSV/JSON), after which our copies are deleted on the schedule in the DPA. Because the app lives on your developer accounts, the install base and store listing also remain yours (see 8.3). The design intent is simple: exit should be a logistics exercise, not a hostage negotiation — and we're happy for you to test the export before you rely on it.

Three structures dominate this market, and the label "white label" gets applied to all of them, unhelpfully. A shared app (the most common model) means your readers use the vendor's app — your books appear inside it, sometimes with your branding on the shelf, but the app listing, the install base and often the customer relationship belong to the vendor. An SDK means the vendor licenses you reading-engine components and your developers build and operate your own app around them — maximum control, but you become a software team. A true white-label app — Publish360's model — means a complete branded app built and operated for you, but published under your own Apple and Google developer accounts, so the asset is structurally yours without your team writing code. The question that cuts through every vendor's marketing: whose developer account is the app published under, and who keeps the readers if we separate? Ask it of everyone, including us.

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.

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.

The platform absorbs it — that's a core part of what the fee buys. Store policies shift constantly (IAP requirements, external-link rules, privacy-label demands, SDK deadlines), and the regulatory environment is currently moving in publishers' favour — courts and regulators in the US and EU have been forcing the stores open to external checkout links. When rules change, we update the platform and every publisher's app inherits the fix; when rules loosen, you inherit the opportunity (e.g., link-out checkout reducing IAP exposure — see 1.5). Because your checkout mix is diversified by design (web, in-app, offline, vouchers), no single store's policy change can hold your revenue hostage — which is precisely the resilience argument for owning a multi-channel checkout rather than living inside one store's rules.

The roadmap is ours to run and yours to influence: features ship platform-wide, so every publisher inherits every improvement without integration projects (that's the economics that keep the fee flat). Publisher requests are weighted by how many houses need them. Genuine custom development — features exclusive to one publisher — is Enterprise-tier conversation territory: possible where it doesn't fork the platform, honestly declined where it would, because a forked platform quietly becomes the bespoke build we've been warning you about (see 4.10).

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.

Not out of loyalty — out of value. Readers adopt a publisher's app when it gives them things the general retailer structurally can't: exclusive content (bonus chapters, author commentary, early access — the Innovation page's access/intimacy/curation/generosity playbook), better bundles (ebook + audiobook together at one sensible price), their existing purchases waiting in the library on day one (see 5.3), and — for the right lists — the relationship itself (children's publishers, niche non-fiction, fandoms and faith communities have audiences that actively want a home that isn't a superstore). The honest version of this answer is that your app doesn't need to beat Kindle for every reader; it needs to be clearly better for your best readers — the repeat buyers who drive a disproportionate share of revenue and who are precisely the people Amazon won't let you know.

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).

Sales and revenue in real time; reading behaviour per title (starts, progress, completion rates); funnel data (QR scans → installs → registrations → purchases); cohort and retention views; subscription metrics (conversion, churn, consumption by tier). The Data Insight page's framing is the right way to think about it: not dashboards for their own sake, but four decisions per season — what to acquire, what to reissue, what to bundle, whom to email — made with evidence instead of folklore. Completion-rate data alone changes editorial conversations: it's the difference between "it sold" and "it was read."

By launch day the app is live in both stores, your catalogue is loaded, and your historical customers' libraries are waiting for them. The launch sequence we run with you: announcement email to your customer file ("your library is ready"), an install incentive for your email list (exclusive or bundle), QR assets into the next print runs, author briefing (and dashboard access — see 2.7), and social/PR assets. First-week success metric is not revenue; it's installs and registrations from owned channels — revenue follows the population. Weeks two to twelve are a rhythm of one meaningful reader-facing reason per week to open the app: a push, a promotion, an exclusive, a serial instalment.

Launch period (first 6–8 weeks): a few hours a week from marketing (campaign assets, email copy, QR placement decisions) plus pockets of time from ops (catalogue checks) and finance (setup — see 1.14). Steady state: the honest range is 2–5 hours a week of marketing attention — the channel runs on the same campaign calendar your marketing team already keeps, with the app as an additional (and unusually measurable) channel for each campaign rather than a separate workstream. What takes zero hours: development, hosting, store compliance, DRM, reader tech support. The honest failure mode isn't overwork — it's neglect: a channel nobody feeds for a quarter stalls, which is why "no new headcount" is true and "no new hours" would be a lie. We'd rather you budget five hours a week and be pleasantly surprised.

Honest answer: adoption varies with the drivers you'd expect — the size of your email list, your print volumes, the strength of the launch offer and how visibly the QR codes are placed. The calculator on this site uses inspectable assumptions rather than guarantees, and at the demo we model the crossover point on your own numbers. What we won't do is dress projections up as track record: we show you the live evidence we have, on the record, and let the inspectable calculator speak for itself — your titles, your assumptions, your numbers.

Match the model to the reading pattern. All-access suits deep, genre-coherent backlists with voracious readers (romance, crime, category fiction). Per-author clubs suit houses with marquee names whose fans want everything, early. Books-plus-exclusive-content suits literary lists and fandoms where intimacy is the product. Focus-area subscriptions suit specialist non-fiction (a subject shelf as a service). Audio-only suits commuter-heavy audiences and keeps the tier's delivery costs legible. Library-style (any N titles at a time) suits broad general lists — it caps consumption economics while feeling generous. Two rules from the Innovation page's logic: subscription must offer readers something ownership doesn't (breadth, earliness, or intimacy — not just a different payment schedule), and check rights before enrolling titles (see 2.2). Start with one model, priced simply; a confused subscription page converts nobody.

The platform's answer is structural, not motivational: the app never starts empty because your full catalogue loads before launch (see 5.1) and your existing customers' purchases are waiting in their libraries on day one (see 5.3). The reader-side empty-app problem — installed, opened once, forgotten — is beaten by the launch rhythm (see 6.9): one real reason per week to return, of which push notifications are the enabling channel and exclusive content is the enduring one. The doom loop the Flywheel page warns about (thin app → disappointed readers → no word of mouth → thinner app) is real, and it's why we tell publishers who lack the marketing bandwidth to feed the channel that the timing isn't right yet (see 1.3) — an honest "not yet" beats a dead app in both our interests.

In practice, publisher direct channels have become normal — most major houses and a fast-growing share of independents sell direct — and retailers have not, as a category, punished it: your trade sales continue through the same accounts, on the same terms, and a retailer's buyer cares about your titles' velocity, not your website. The realistic frictions are narrower: systematic undercutting of retail prices on identical products is what actually irritates trade partners (the answer is value-differentiation, not price war — see 1.9), and exclusive editions are a long-established practice retailers themselves run constantly (see 7.2). It's also worth naming the asymmetry in the status quo: your largest retail partner already competes with you — for your readers' identities, attention and next purchase — every single day. A direct channel doesn't start that competition; it just stops it being one-sided.

Generally yes — exclusivity and windowing are standard publishing practice (retailer-exclusive editions, signed indie editions, format windowing have decades of precedent), and offering your own channel an exclusive edition or early window is the same instrument pointed at yourself. Check two things first: any agency or account terms that create price/availability obligations for specific retailers, and proportionality — an early window of days-to-weeks on select titles builds your channel without giving trade accounts a grievance narrative; withholding lead titles from retail for months would. The strongest direct exclusives don't withhold the book at all: they add what retail can't carry (bonus chapters, author commentary, bundles), which gives your channel superiority with zero trade friction.

No general legal obligation compels it — you set your direct prices. The practical considerations: where you sell ebooks under agency terms you control retail price anyway (and should check your agreements for any parity language); where retailers discount at their own expense under wholesale terms, your direct price may sometimes be undercut by Amazon, which is survivable because your channel's offer is value, not price (see 6.1). Our guidance is boring and firm: hold direct prices at or near RRP, win on bundles and exclusives, and never train readers to comparison-shop you.

Far less than it competes with the superstore, and the QR mechanism actually helps the physical trade case: every QR-carrying print copy an indie sells becomes more valuable to you than the same sale without it, because it can convert an anonymous buyer into your named reader — which quietly makes indie handselling one of your best acquisition channels, worth supporting more, not less. Your digital direct sales overlap mainly with online digital retail (dominated by one player), not with browsing a shop on a Saturday. Publishers extending goodwill further run bookshop-partner codes and event vouchers through the same code machinery (see 5.6) — turning shops into channel partners rather than bystanders.

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'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.

Eden Interactive has run consumer ecommerce since 1999 and has operated Eden.co.uk — one of the UK's largest independent online book retailers — since 2004, serving over three million customers and selling many millions of books. That matters for a specific reason: Publish360 wasn't built by a software company guessing at retail; it's the productisation of two decades of actually selling books to actual readers — merchandising, checkout, customer care, promotion cycles, Christmas peaks and all. We're also an EDRLab member (the European Digital Reading Lab, home of Readium and LCP), which anchors the platform's open-standards commitments in governance, not just marketing copy. The candid version of "why trust us": don't — verify us. The inspectable calculator, the exportable data and the 30-day notice period are all designed so that trust is continuously optional.

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.