The desk was ordinary. A laptop, a notebook, a half-empty mug. What wasn't ordinary was what the author had built around it over eighteen months: a complete publishing operation that ran on tools she had assembled herself, none of which required her to write a single line of code.
She wasn't a developer. She wasn't a tech blogger. She was, by her own description, someone who had once been intimidated by the phrase "DNS settings." But she had read enough about platform dependency about authors waking up to find their audiences locked behind new algorithm rules or their distribution accounts suspended without clear appeal to decide she wanted something different.
What she built is sometimes called a modular stack: a collection of interchangeable tools, each doing one thing well, that can be swapped out or upgraded without dismantling the whole operation. The term comes from software development, where it describes a way of building applications from discrete, composable components. But the principle, it turns out, translates cleanly to publishing.
What Owning Your Infrastructure Actually Means
The case for owned publishing infrastructure has been made directly by the team at Publishing House, who note that "every few years, a platform that indie publishers relied on changes the rules." Algorithm changes cut organic reach. Monetization programs introduce new requirements or reduce payouts. Accounts get suspended without clear appeal paths. The terms shift in ways that favor the platform over the publisher.
This dynamic predates the internet. But the specific form it takes now where a significant portion of an independent publisher's audience, revenue, and distribution lives on infrastructure controlled by companies whose interests regularly diverge from the publishers they host is worth examining directly.
The alternative is not to abandon platforms. It is to use them differently, from a foundation of owned infrastructure.
"Owning your publishing infrastructure means the core of your operation your content, your archive, your subscriber list, your publication's identity lives on systems you control, not on systems you access by permission," according to Publishing House's analysis of indie publisher infrastructure.
In practical terms, this means: your primary publication lives on a domain you own, hosted on a server where you have full data access and portability; your subscriber and reader data lives in systems you control or can export cleanly; your content archive is yours in files you can move, republish, and build from independently; and platforms like social media or newsletter services are distribution channels you use, not the foundation you build on.
The distinction matters when platforms change. If your primary audience lives on someone else's platform, a policy change or account action can cut you off from readers you spent years building relationships with. If your primary publication is yours, platforms become amplification tools rather than existential dependencies.
The Modular Stack, Translated for Authors
The concept of a modular stack has been explored in technical contexts by Andrew Hong, who describes it as "a collection of technologies designed to change all that, so application developers can tailor their development environment to the desired user experience, while remaining permissionless, composable, and minimizing trust assumptions."
For authors, the translation is straightforward: instead of relying on a single platform to handle writing, distribution, audience building, and monetization, you assemble discrete tools that each handle one of those functions. Each piece can be evaluated, replaced, or upgraded independently. None is irreplaceable. None controls your relationship with your readers.
This approach requires more upfront thinking than simply signing up for an all-in-one platform. But it offers something those platforms cannot: portability. When the platform changes its terms, you don't have to start over. You simply route your audience through a different channel, because the foundation your domain, your files, your subscriber list remains yours.
The Static Site Foundation
One of the most radical versions of owned publishing infrastructure involves static site generators tools like Hugo, Eleventy, Jekyll, and Astro. Publishing House describes these as representing "the most radical version of owned publishing infrastructure."
The appeal is simplicity at the foundation level. Your content is files. Your site is files. Hosting is cheap or free and trivially portable. A publication built on Hugo lives in a Git repository. The full content archive is Markdown files. The site can be rebuilt from those files on any hosting provider in minutes.
"There is no database to migrate, no proprietary format to escape, no hosting lock-in," according to Publishing House's infrastructure guide. "The tradeoffs are real no browser-based editing, no dynamic features without third-party services, a technical barrier to entry but for publishers willing to work within those constraints, the operational independence is genuine."
For non-technical authors, this might sound intimidating. But the technical barrier is lower than it sounds. Markdown is a plain-text formatting language that takes an afternoon to learn. Static site generators have extensive documentation and communities. And once the site is running, it requires almost no maintenance.
Self-Hosted WordPress as the Middle Ground
Not every author wants to work in Markdown files. For those who prefer a more traditional content management interface, self-hosted WordPress offers a practical middle ground.
"WordPress is not a platform in the sense that social media companies are," according to Publishing House's infrastructure analysis. "WordPress.org is open-source software you run on your own hosting. Your data is in a database you control and can export. Your content is yours."
The distinction between WordPress.com and a self-hosted WordPress.org installation is important and often elided. WordPress.com's higher tiers function more like a hosted platform with their own terms and restrictions. A self-hosted WordPress.org site, properly backed up and on hosting you control, is owned infrastructure in the meaningful sense.
"The calculus changes if your publication lives on WordPress.com's higher tiers, Ghost Pro, or other managed platforms," Publishing House notes. "These are quality services, but they are platforms the distinction is portability."
Distribution: The Boring Part That Pays Off
Infrastructure ownership isn't just about your website. It's about where your books actually sell. The team at Fusion Stack Lab, who have "ghost-built, shepherded, and launched dozens of indie books," emphasize that distribution setup is "the boring part that pays off."
"Set up Amazon KDP, IngramSpark, Apple Books, Kobo, Google Play, and audiobook distribution (ACX or Findaway) properly the first time," they advise in their guide to publishing without a publisher. "The cost of redoing metadata, categories, and price tiers across five storefronts later is enormous. Get it right at launch."
One channel that indie authors sometimes overlook: libraries. "IngramSpark distribution makes your book available to physical retailers and libraries, which is both a real channel and a real source of credibility," according to Fusion Stack Lab. "Libraries showed up in 18% of our authors' first-year sales last year."
This is the kind of specific, actionable detail that gets lost when authors rely on a single distribution platform. The modular approach means thinking about where readers actually discover and acquire books not just where it's convenient to list them.
Editorial First, Always
Infrastructure is the foundation, but the content itself still needs to work. Fusion Stack Lab is direct about this: "The biggest mistake we see indie authors make: skipping developmental editing because they think their manuscript is already 'good enough.'"
A developmental editor is the person who tells you the chapter ordering is wrong, the middle sags, and the protagonist's motivation isn't earned. "That's not a $500 line-editing pass it's a $3-8k engagement with someone who's done it for a major house, and it's the single highest-leverage spend in the whole project," according to Fusion Stack Lab's publishing guide. "We won't take on a publishing engagement without dev editing in scope. The downstream cost of a beautifully designed book that doesn't work structurally is too high."
This is where the modular stack extends beyond technology. The team you assemble editor, cover designer, formatter, publicist is also modular. Each role can be evaluated independently. Each can be replaced if the fit isn't right. The goal is to build an operation where no single component is irreplaceable, including the people.
Cover Design as a Sales Tool
The cover is where many indie authors make their most expensive mistake: prioritizing aesthetic taste over category convention. "Your cover has one job: make a stranger scrolling Amazon stop and click," according to Fusion Stack Lab. "Aesthetic taste is irrelevant category convention is the law."
Romance covers look the way they do because that's what romance readers click. Business book covers look the way they do for the same reason. "Fight your covers designer on this and you'll lose money in week one," Fusion Stack Lab advises. "We A/B test every cover against three to five concepts before launch, using paid traffic to category-relevant audiences. The data settles arguments. Designers' egos shouldn't."
This is another form of modular thinking: the cover is a conversion tool, not an art project. It can be tested, measured, and revised without touching the content of the book itself.
Marketing as a System, Not a Launch
The temptation for first-time indie authors is to treat the book launch as the event that determines success or failure. The modular approach reframes this.
"The launch week matters less than people think," according to Fusion Stack Lab. "Sustained marketing over months matters far more. The authors who do this right treat their book as a flywheel: a newsletter that keeps growing, paid ads that run at a profitable ROAS, a podcast tour spread across a year."
The launch is "the first marketing event, not the only one." Indie authors who succeed in this model "don't beat trad publishing by being clever. They win by being more patient, more systematic, and more willing to keep showing up six months after the launch party ended."
This patience is easier to maintain when your infrastructure is yours. When you're not dependent on a platform's algorithm to reach your audience, you can build sustainable, compounding channels: an email list you own, a website with evergreen content, a backlist that generates steady sales independent of new releases.
Why This Matters for BookWriter Readers
For readers researching author tools and publishing platforms, the modular stack approach offers a specific alternative to the all-in-one platform model. Rather than trusting a single service to handle your writing, distribution, audience building, and monetization, you assemble discrete tools that each do one thing well.
The practical benefit is control. When your foundation is owned your domain, your subscriber list, your content files platform changes become inconveniences rather than catastrophes. You can adapt. You can migrate. You can choose new tools without losing your audience.
The practical cost is upfront complexity. You'll need to make more decisions about tools and setup. You'll need to understand enough about each component to evaluate whether it's working. But this complexity is front-loaded, not ongoing. Once your stack is assembled, it tends to run itself.
For authors who have been burned by platform changes or who simply want to build something durable the modular approach is worth understanding. It won't solve every problem. But it addresses the core risk of platform dependency: the risk of building your audience on land you don't own.
Building Your Stack: A Practical Map
For authors ready to explore the modular approach, here's how the components fit together:
| Layer | What It Does | Example Tools | Owned vs. Platform |
|---|---|---|---|
| Foundation | Where your primary content lives | Self-hosted WordPress, Hugo, Eleventy | Owned (your domain, your hosting) |
| Distribution | Where readers buy your books | Amazon KDP, IngramSpark, Apple Books, Kobo | Platform (but portable set up once correctly) |
| Audience | Your direct reader relationships | Email list (self-hosted or exportable), newsletter service | Mixed own the list, rent the delivery tool |
| Marketing | How readers discover you over time | Podcast appearances, paid ads, evergreen content | System compounds over months and years |
| Team | Who helps produce and promote your work | Developmental editor, cover designer, formatter | Modular each role independently replaceable |
The key principle is that each layer can be evaluated and replaced independently. If your email service raises prices, you export your list and move to a different service. If your cover designer isn't generating clicks, you test new concepts. If your distribution setup is wrong, you fix it once and then let it run.
The Dependency Question
One honest question about the modular approach: doesn't it just create different dependencies? You're still relying on hosting providers, domain registrars, distribution platforms, and tool vendors.
Yes. But the nature of the dependency matters. As the xkcd dependency explainer notes, technology architecture often involves dependencies on components maintained by individuals or small teams. The question isn't whether you depend on others it's whether those dependencies are portable and replaceable.
"The concept of balance is not intended to be communicated by a stack diagram, making this a humorously absurd extension of a well-known diagram style," according to the xkcd dependency explainer. The comic illustrates how dependencies near the bottom of a stack components maintained by a single person, without fame or acknowledgement can become critical risks when they fail.
The modular stack approach mitigates this risk by design. When each component is replaceable, the failure of any single tool doesn't collapse the whole operation. You maintain multiple distribution channels, not just one. You back up your content files regularly. You own your email list and can export it at any time.
The goal isn't to eliminate dependencies. It's to make them transparent, portable, and replaceable.
What Non-Technical Authors Actually Need to Learn
The modular approach does require some technical literacy. But it's less than most authors assume. The core skills are:
- Domain management: Understanding how domains work, how to point them at your hosting, and how to transfer them if needed. This is a one-time learning investment.
- Content portability: Knowing how to export your subscriber list, back up your content files, and move them between services. This is a regular practice, not a one-time setup.
- Tool evaluation: Being able to assess whether a tool is working for you based on data, not just preference and being willing to replace it if it's not.
- Basic markdown or CMS operation: Learning enough about your content management system to publish, edit, and maintain your work without constant technical support.
None of these skills requires a computer science degree. They require curiosity, patience, and a willingness to learn by doing. Most authors who adopt the modular approach describe the learning curve as steeper at the beginning and much smoother after.
The Flywheel That Compounds Over Time
The deepest appeal of the modular approach is what it enables over time. When your infrastructure is owned and your distribution is set up correctly, each book you publish adds to a compounding system.
Your email list grows with each release. Your backlist generates steady sales. Your website accumulates evergreen content that brings in organic discovery. Your distribution setup done correctly the first time handles each new title without additional setup cost.
This is the flywheel that Fusion Stack Lab describes: not a launch event, but a sustained system that builds over months and years. The modular approach makes this flywheel more durable, because it's not dependent on any single platform's goodwill or algorithm.
For authors who want to build something lasting, the modular stack offers a path. It's not the only path. But for those willing to invest in understanding their infrastructure rather than simply renting it it offers something valuable: ownership.
Where to Read Further
For authors ready to explore owned infrastructure in more depth, the following resources offer practical frameworks:
- Publishing House's analysis of indie publisher infrastructure covers the case for ownership, static site approaches, and the WordPress distinction in detail.
- Fusion Stack Lab's guide to publishing without a publisher offers specific workflow advice for editorial-first production, cover testing, and distribution setup.
- The xkcd dependency explainer provides useful context for thinking about technology dependencies and why portability matters.
The modular stack isn't a magic solution. It won't guarantee sales, solve creative blocks, or replace the hard work of writing a good book. But for authors who want control over their publishing operation and who are willing to invest in understanding the tools they use it offers a practical framework for building something durable.