The monitor has been sitting on the same publishing spreadsheet long enough for the screen to start feeling like another piece of furniture. One column says control. Another says cost. A third says time. None of them is really the problem.
The problem is that we keep treating traditional publishing and self-publishing like two competing answers to the same question.
They aren’t.
They are two different production architectures.
And once we look at publishing that way, the comparison gets considerably more useful.
Stop Asking Which One Is Better
The usual traditional-versus-self-publishing discussion is built like a shopping list.
Traditional publishing offers professional editing, design, production, distribution, and potentially an advance. It also comes with a competitive submission process, less control over certain decisions, lower royalty rates, and a longer timeline.
Self-publishing offers greater control, potentially higher royalties, faster publication, and the ability to change pricing or presentation later. In exchange, the author takes on editing, design, formatting, distribution, marketing, and the associated costs and time.
None of that is wrong.
It’s just not the most useful model for thinking about the decision.
A list of advantages and disadvantages makes the two systems look like competing products. Pick the one with the better features.
Publishing isn’t a product comparison.
It’s a workflow.
A book still has to move through roughly the same broad production chain:
Manuscript → Editing → Design → Production → Distribution → Marketing → Sales
The important question is not whether those jobs exist.
The important question is:
Who carries each piece of the load?
That’s where the architectures diverge.
The Publishing Pipeline
Imagine the publishing process as a workshop with six stations.
The manuscript enters at one end.
Someone has to edit it.
Someone has to create the cover and interior design.
Someone has to turn the files into a product that can actually be sold.
Someone has to distribute that product.
Someone has to make potential readers aware that it exists.
Someone has to manage the commercial side.
Traditional and self-publishing don’t remove these stations.
They redistribute them.
That’s the mechanical distinction worth paying attention to.
Traditional publishing places much of the production infrastructure on the publisher’s side of the table. The publisher may provide editing, cover design, production, distribution, and marketing support, while the author moves through a gatekeeping and contractual process to access that infrastructure.
Self-publishing moves much more of the pipeline back to the author.
The author can hire an editor. They can hire a cover designer. They can use a distributor. They can pay for formatting.
But the author remains the system’s central operator.
That difference has consequences.
Not moral consequences.
Mechanical ones.
Architecture One: External Infrastructure
Traditional publishing is essentially an infrastructure-sharing model.
The author creates the manuscript and enters an existing production system.
That system has its own people, processes, contracts, schedules, distribution relationships, and commercial decisions.
The benefit is obvious: the author doesn’t have to construct every piece of the machine independently.
But infrastructure comes with constraints.
Once another organization is carrying part of the production load, that organization also has a stake in how the machine operates.
The publisher may have input into the cover.
The publisher may have input into the title.
The publisher controls much of the production schedule.
The publisher’s marketing resources are finite.
The publisher’s distribution network is an asset, but access to that asset comes with an agreement about rights, royalties, and responsibilities. The original post identifies this trade-off directly: traditional publishing can provide professional production and wider distribution while giving the author less control over some creative and marketing decisions.
That’s not a flaw in the system.
It’s the cost of using someone else’s infrastructure.
We already understand this principle in other creative industries.
A production studio has equipment, staff, facilities, distribution relationships, and capital that an individual creator may not possess.
In exchange, the creator doesn’t get unilateral control over every production decision.
The system works because both sides are carrying different parts of the load.
Architecture Two: Distributed Responsibility
Self-publishing flips the structure.
Instead of entering an existing production system, the author becomes the central point connecting multiple independent services.
Editor.
Designer.
Formatter.
Distributor.
Marketing platform.
Retailer.
Possibly advertising.
Possibly newsletter infrastructure.
Possibly additional freelancers.
The author can assemble the system however they want.
That’s the great mechanical advantage.
The architecture is configurable.
If the cover isn’t working, it can be changed.
If the price needs adjusting, it can be changed.
If the description needs rewriting, it can be changed.
If the book needs a new edition, the author controls that decision.
Thhis flexibility is one of self-publishing’s advantages, alongside creative control, faster publication, and the ability to adjust pricing and presentation.
But configuration creates another problem.
Someone has to configure it.
Someone has to evaluate the editor.
Someone has to determine whether the cover is actually doing its job.
Someone has to handle the files.
Someone has to understand the distribution options.
Someone has to make the marketing decisions.
Someone has to pay for the pieces.
The machine is yours.
So is the maintenance.
Jaxon Would Call This a Logistics Problem
Jaxon has a particular expression he gets whenever someone describes a complicated operation as “just a few moving parts.”
It usually means he’s already counting them.
Put a publishing contract in front of him and he wouldn’t begin by asking which option feels more prestigious.
He’d draw a line down the page.
Who owns this?
Editing?
Who owns it?
Cover?
Who owns it?
Distribution?
Who owns it?
Marketing?
Who owns it?
Rights?
Who owns them?
Cost?
Who absorbs it?
Time?
Who controls the schedule?
That’s the useful exercise.
Not because Jaxon has suddenly become interested in publishing.
He hasn’t.
He just understands systems where responsibility disappears into the gaps.
Publishing decisions get expensive when we mistake ownership for control.
Self-publishing gives you ownership of the entire machine, but that doesn’t mean every component is something you personally have to perform.
Traditional publishing gives the publisher responsibility for many components, but that doesn’t mean the author has no responsibilities of their own.
The architecture determines where the work goes.
It doesn’t determine whether the work exists.
The Hidden Trade: Control for Infrastructure
This is where the traditional-versus-self-publishing argument usually gets flattened.
Traditional publishing is often described as having “less control.”
Self-publishing is described as having “more control.”
True, but incomplete.
A better description is:
Traditional publishing exchanges some decision-making control for access to established infrastructure.
Self-publishing exchanges that infrastructure for direct control over the production system.
Those are different trades.
Neither is automatically superior.
Suppose the thing you value most is control over the cover, pricing, release timing, and presentation of the book.
A system that puts those decisions outside your direct control creates friction.
Self-publishing reduces that friction.
But suppose the thing creating the most friction for you is the prospect of coordinating editing, design, production, distribution, and marketing.
A system that moves those responsibilities onto your desk creates friction.
Traditional publishing may reduce it.
This is why the same publishing model can feel liberating to one writer and exhausting to another.
The architecture is interacting with the writer’s actual constraints.
Time Is Part of the Architecture
Publishing timelines are another place where the systems look deceptively similar.
Traditional publishing can take considerably longer. The original comparison notes that publication can take a year or two or more after signing, on top of the time required to secure representation or a publishing deal.
Self-publishing can move much faster once the manuscript and production materials are ready; the source notes that a book can potentially reach the market within weeks or even days.
But “faster” doesn’t mean “less work.”
It means the bottlenecks have changed.
In a traditional system, the author’s manuscript may be waiting on acquisition, editorial schedules, production schedules, and release planning.
In a self-publishing system, the author can remove some of those external bottlenecks—but may replace them with their own production queue.
The book isn’t necessarily moving faster because the process became simpler.
It may be moving faster because fewer organizational layers are between the decision and the result.
That’s an architectural difference.
Money Follows Responsibility
The same principle applies to money.
Traditional publishing may involve an advance against future royalties, while the publisher absorbs substantial upfront production investment.
Self-publishing reverses much of that exposure.
The author may need to budget for professional editing, cover design, formatting, advertising, and other production services before the book earns anything back.
Again, the system hasn’t eliminated the cost.
It has moved the cost.
That’s the recurring pattern.
Responsibility moves. Risk moves with it.
If a publisher invests in production, the publisher has capital at risk.
If an independent author commissions the production themselves, the author carries that initial expense.
If a publisher handles distribution, the author doesn’t have to construct that network from scratch.
If the author chooses their own distributors, the author also takes on the work of deciding how that network functions.
Every architectural choice creates a corresponding load.
Rights Are Load-Bearing Components
Rights deserve particular attention because they’re easy to bury inside the excitement of getting a book published.
The original post identifies rights management as one of the considerations in traditional publishing, alongside contracts and negotiations.
Mechanically, rights determine who gets to make which decisions about the work and under what conditions.
That makes the publishing agreement less like a receipt and more like a blueprint.
The blueprint tells us which pieces of the book’s future have been assigned to which party.
Who controls a particular edition?
Who controls distribution?
What happens if the book is adapted?
What happens if it goes out of print?
What happens if one party wants to change the arrangement?
Those questions belong to the architecture.
They aren’t fine print surrounding the architecture.
They are the architecture.
The specific answers depend on the contract, so there isn’t a universal “traditional publishing gives you X rights” rule we can responsibly apply to every deal. The useful principle is simpler: before choosing a system, identify which decisions and rights that system places inside or outside your control.
Success Isn't a Single Output
This is the part I think gets lost most often.
We talk about publishing as though both systems are trying to produce the same end state.
A book gets published.
Therefore, whichever system gets the book published “better” wins.
But a production system isn’t successful simply because it produces an output.
It is successful when it produces the intended output under acceptable constraints.
A bridge isn’t a bad bridge because it was built with steel instead of concrete.
A game build isn’t a failure because it sacrifices defense for damage.
A plot isn’t badly designed because it chooses a slower pacing model than another story.
The question is whether the architecture supports the thing it was built to accomplish.
Publishing works the same way.
If an author wants established production infrastructure and is comfortable surrendering some control over the process, traditional publishing may fit that architecture.
If an author values direct control and is prepared to carry the operational workload, self-publishing may fit better.
The important variable isn’t which system wins in the abstract.
It’s whether the system’s trade-offs match the project.
Where the Architecture Breaks
Every system has failure points.
Traditional publishing can become frustrating when the author expects complete creative control from a system designed around shared decision-making.
Self-publishing can become overwhelming when the author mistakes having control for having unlimited capacity.
That’s an important distinction.
You can control every component of a system and still be crushed by its workload.
The source material points directly toward this problem: self-publishing gives the author control, but also makes the process time-intensive because the author is responsible for so many aspects of production.
The inverse is also true.
You can delegate responsibility and still become frustrated when decisions move more slowly than you’d like.
Neither problem is evidence that the system is inherently broken.
They’re signs that the architecture is mismatched with the operator.
The Better Question
So I wouldn’t ask:
“Should I traditionally publish or self-publish?”
I’d put the publishing pipeline on the desk instead.
Write down:
Editing
Design
Production
Distribution
Marketing
Sales
Rights
Timeline
Upfront Cost
Then ask two questions for every component:
Do I want control over this?
And:
Do I want responsibility for this?
Those answers don’t necessarily have to match.
You can want control over your cover without wanting to design the cover yourself.
You can want professional editing without wanting to find every editor in the industry.
You can want broad distribution without wanting to negotiate every distribution channel.
That’s why “traditional versus self-publishing” isn’t actually a binary about independence.
It’s a question of where you want the boundary of your responsibility to sit.
Different Machines, Same Destination
The useful conclusion isn’t that traditional publishing is better.
It isn’t that self-publishing is better either.
The useful conclusion is that publishing models are different production architectures, not opposing definitions of success.
One architecture places more infrastructure outside the author’s immediate control.
The other places more of the infrastructure directly under the author’s control.
Both still require a finished manuscript.
Both still require a book that functions as a book.
Both still require readers to discover it.
The difference is how much of the machinery sits on your side of the table.
That’s a much more useful way to make the decision.
Not Which path makes me a real author?
Not Which path is more legitimate?
Not even Which path is better?
Instead:
Which production architecture can carry this particular book without putting more load on the project than I can reasonably support?
That’s a systems-design question.
And systems questions are usually easier to answer once we’ve stopped arguing about which machine is morally superior and started looking at what each machine actually does.
Sanctuary Project
Take your current publishing plan and draw the pipeline on one sheet of paper:
Manuscript → Editing → Design → Production → Distribution → Marketing → Sales → Rights
Under each stage, write “Me,” “Publisher,” or “Shared.”
Don’t decide whether the arrangement is good yet.
Just map where the load would sit.
Once the architecture is visible, the trade-offs become considerably harder to ignore.