#45 The Raw Truth About Self-Publishing My First Technical Book: 800+ Copies, $11K, and 850 Hours

Want to write a technical book? Think twice. Here is my story of self-publishing a software architecture book—from the initial decision through writing, pricing, and real sales numbers.

A week ago, my “Master Software Architecture” book reached a milestone: 800 copies sold (combining ebooks and physical copies). While I am incredibly happy about this achievement, you might wonder: is this a lot compared to what I planned? That is one of the many topics I will explore in today's post.

I want to share the complete journey with you, answering questions like: How much has the book earned? Why did I choose the self-publishing route over a traditional publisher? How did I plan and execute the writing process? What were my initial expectations? How did I figure out the right pricing? And what are the pros and cons I have discovered along the way?

My hope is that by sharing this story—from its very beginning until now—I can help you make a good decision if you are considering writing your own technical book.

They say if you don't know where to start, start at the beginning. So that is exactly what I will do.

When Did I First Think About Writing a Book?

The story begins in 2012, at the start of my professional programming journey. Like any junior developer, my main concern was simply surviving another month without making a fool of myself. My knowledge was limited, but it was just beginning.

As the years passed, I found myself exploring various areas of software development. From infrastructure to backend, frontend to third-party integrations, I eventually became a part-time consultant (next to my full-time job) specializing in payment providers and authentication systems.

Each new project offered a different perspective on software development. I worked with legacy systems and greenfield projects, in both hierarchical and flat organizations, from small startups to large enterprises. Looking back, it is amazing how quickly time flew by and how much I learned from both my mentors and the challenges I faced.

Around 2020, my perspective on software systems fundamentally shifted. After witnessing numerous systems built with unnecessary complexity, I began focusing on two key principles: simplicity and evolution.

But let me be clear: simplicity does not mean stupidity. A well-designed system can adapt and grow, regardless of future changes. You can follow and adapt patterns to meet your business needs—whether that means starting with a simple App Service and later migrating to Kubernetes, or evolving today's modular monolith into tomorrow's distributed system.

I frequently received feedback like “I didn't think about it this way” or “It opened my eyes.” This was the trigger that inspired me to write a book, sharing my thought process that had proven successful in 80% of the situations I encountered. Of course, it will never be a silver bullet covering 100% of cases. When you hear about a “magical” method that is “the” way, remember it is just “a” way—one of many possibilities.

In 2022, I began collecting materials and created what I thought was a rough plan (though looking back, I would hardly even call it that). While I initially planned to write the book in 2023, a full-time opportunity in artificial intelligence—a field I had been interested in since my studies—took priority.

When 2024 arrived, I made a decisive choice: this would be the year I finally wrote my book. I left my full-time job to focus on this goal. Interestingly, I had two potential books in mind, so I created a LinkedIn poll to let my audience help decide which one I should write.

As you can see, the margin wasn't overwhelming—55% versus 45%. Still, the decision was made: “Ode To Software Architecture” would be my focus. That LinkedIn post on March 21, 2024, marked the beginning of what would become five months of intense work and dedication.

Self-Publishing Versus Traditional Publishing

One of the first crucial decisions you will face is choosing between self-publishing and working with a traditional publisher. Both paths have their advantages and drawbacks—what matters is understanding what is important to you and whether you can manage the self-publishing journey independently.

Here are the key factors I considered:

• Reach. If you don't have a significant following (like Gergely Orosz, for example), reaching a broad audience with your first self-published book can be challenging—I learned this the hard way. After publishing, I dove into research about typical sales figures. The pattern became clear: first-time authors typically sell 200-300 books in their first year. For a self-published book, reaching 1,000 sales in the first year is considered a success.

• Royalties. Based on publicly available information and discussions in the author community, traditional publishers typically offer an upfront payment of $3,000-5,000, with royalties of 5-8% on physical book sales and 10-20% on ebooks (sometimes after meeting certain sales thresholds). In contrast, self-publishing platforms (Leanpub, Gumroad, and others) offer 80-90% royalties on ebook sales. Physical book economics through print-on-demand services are less favorable (I earn something between $1-5 on each sale via Amazon KDP).

• Creative Freedom. Working with a traditional publisher involves extensive back-and-forth about content, writing style, and book structure. This makes sense—they have a reputation to maintain. For me, the ability to express myself naturally was paramount. I wanted to use simple language, share practical examples, and follow my specific structure. This was the deciding factor in choosing my path.

• Copy Editing. Traditional publishers include professional copy editing services. They will assign someone to review your manuscript for grammar, sentence structure, and phrasing. With self-publishing, you need to hire them independently.

• Beta Readers and Reviewers. Self-publishing means finding your own beta readers and reviewers. Surprisingly, this wasn't as difficult as I expected—I put out calls on social media, and several colleagues volunteered (some even approached me directly). Traditional publishers typically have established networks of reviewers.

• Marketing. While I can't speak comprehensively about traditional publishers' marketing support, they do offer built-in reach and reputation—almost everyone in tech knows names like O'Reilly or Manning. With self-publishing, you are responsible for all marketing efforts.

Having weighed all these factors, I decided to self-publish my book. The main challenge was finding the right platform that could help with reach, especially since I didn't have a large community behind me. After exploring my options, I settled on Leanpub. Their royalty structure was refreshingly straightforward: they take 20% of each sale (while taking care of things like collecting VAT), while 80% goes directly to the author. The platform's credibility was reinforced by the fact that many respected authors in the software architecture space—like Gregor Hohpe, Alberto Brandolini, and Simon Brown—had published their books there.

My Expectations

Before diving into writing, I did my homework. I studied other authors' sales figures, read countless posts about maintaining writing consistency, and consulted colleagues who had published their own books. Based on this research, I set clear goals:

• Sell 5,000 copies in the first year

• Start with an ebook, refine it based on early reader feedback, then release the physical version

• Write at least 20 pages daily, aiming for around 400 pages total

Was I being naive with these expectations? Let's explore what actually happened.

Writing

I started writing on March 22, 2024, just one day after the poll results came in. The first step was creating a comprehensive plan using a Miro board, mapping out topics and structure. While the overall plan proved accurate over time, some parts evolved (sadly, I no longer have that original Miro board). I spent about a week developing this initial outline, sharing it with my mastermind group (Radek Maziarka, Kamil Bączek, and Krzysztof Owsiany) and the “Order of Devs” Discord for feedback. Their input was invaluable and helped shape the final structure before I wrote my first word.

Initially, I tried maintaining a rigid schedule of writing eight hours daily. While I managed to keep this pace for 2-3 weeks, eventually I hit a wall. Creative work for such extended periods proved unsustainable, so I adapted my approach.

My new routine was simple: wake up, have coffee, and start writing. Some days were incredibly productive—I could write for 13-14 hours (my record was 16 hours), producing up to 20 pages. Other days, I might only manage 3-5 hours and 5 pages. I set just one rule: write at least 5 pages daily. In the entire writing period, I only fell short of this goal 3-4 times.

This approach worked wonderfully. The key lesson? Listen to yourself. When you can't write, don't force it. Find your own rhythm. Also, don't measure yourself against other authors.

If you don’t know it yet, my book is divided into 8 key steps and 2 extras:

• Step 1: Understand Software Architecture

• Step 2: Discover Your Business Domain

• Step 3: Recognize the Environment Around You

• Step 4: Choose Deployment Strategy

• Step 5: Define Release Strategy

• Step 6: Focus On Testing

• Step 7: Evolve Your Architecture

• Step 8: Don't Forget About Security

• Extra 1: Other Engineering Practices

• Extra 2: Architecture Exercises

My initial writing strategy was strictly sequential—starting with Step 1 and methodically moving forward. However, like my daily writing schedule, this linear approach ultimately proved too rigid. I discovered a more effective method: focusing first on topics I was most passionate about, such as discovering business domains, release strategies, architectural evolution, and security. I left the topics that interested me less, like deployment strategies and testing, for later. This approach clicked, and it served me well through the 5 months of writing.

Once I completed a substantial portion of each section, I sent it to my beta readers: Kamil Kiełbasa and José Roberto Araújo. I am incredibly grateful for their exceptional feedback. Their input helped me refine my ideas, fill in gaps, and most importantly, validate that my content was valuable and well-presented. I would then incorporate their suggestions and send the revised sections back for another review.

On March 28, I ordered my book cover through Fiverr. I received it two days later:

Throughout the process, I also actively engaged with both my LinkedIn community and colleagues, seeking input on technical aspects of the book. Here are some examples:

In April, Gergely Orosz gave me invaluable advice: regularly share draft excerpts from my book. This suggestion proved brilliant—it allowed me to publicly validate my content as I wrote. I continued this practice throughout the writing process, gaining feedback and building interest along the way.

In May, I hit my first major roadblock. I noticed my creativity had dried up—I was going through the motions of writing, but the quality was suffering. Rather than push through, I made a crucial decision: take a complete week off from writing. This proved to be exactly what I needed. When I returned to the keyboard, my mind was brimming with fresh ideas, and I easily found my rhythm again.

By the end of May, I began searching for a copy editor to elevate my book to professional standards. I had one key requirement: they needed to be from the United States, since I was primarily targeting US readers (below are my all-time stats from my Substack) and wanted American English.

I found my editor through Fiverr, and on June 10, 2024, I sent them the first 200 pages of my manuscript.

While waiting for the edited pages, I continued writing the next 200 pages. When the second crisis hit in June, I knew exactly what to do. I applied the same strategy—a week-long break—and once again, it worked perfectly.

I received the edited first half back on July 9, and spent several days reviewing the changes. On July 14, I sent the second batch of approximately 200 pages to my editor. While waiting for the second half, I made another significant decision: changing the book's title. I was receiving consistent feedback that “Ode To Software Architecture” didn't clearly convey the book's content. I created another poll to gather input, and that is how “Ode To Software Architecture” transformed into “Master Software Architecture.”

The last step before publication was securing reviewers who could provide rigorous, constructive feedback. Two experienced reviewers stepped forward: Jose Luis Latorre and Martin Dilger (author of the Leanpub bestseller “Understanding Eventsourcing”). I also specifically sought out Urs Enzler, knowing his reputation for thorough, unvarnished feedback would be invaluable.

Thanks to detailed critiques, I was able to make significant improvements to the book.

Throughout the writing process, I also gathered pricing feedback from multiple sources: social media interactions, direct inquiries, and Leanpub's data collection.

Based on this research, I initially structured the pricing with two tiers:

• Minimum price: $20

• Recommended price: $26

This flexible pricing model, unique to Leanpub, allows readers to pay the minimum price or choose to pay more if they find additional value in the book—there is no upper limit. After observing the market response, I later simplified the pricing to a flat $19, occasionally offering promotional discounts.

Finally, on August 26, the book was published.

Guest Authors

Rather than following the traditional approach of having one or two forewords, I invited five experts to share their perspectives on the key drivers of successful software architecture:

• Vladik Khononov. Author of “Learning Domain-Driven Design” and “Balancing Coupling in Software Design.” While we had known each other online, we finally met in person at Infoshare 2024 where we were both speakers.

• Oskar Dudycz. The “Leonardo da Vinci of Event Sourcing,” whom I have had the pleasure of knowing personally for several years.

• Milan Jovanović. A distinguished software architect and one of the two most prominent content creators in the C# and .NET ecosystem.

• Milan Milanović. Chief Technology Officer and well-known content creator.

• Denis Čahuk. Known for his pragmatic and smart approach to software development, Denis was previously a guest on my YouTube channel.

I am really happy and grateful to have them contribute to my book. Their insights add great value for readers, and honestly, seeing their names in my book still makes me smile.

The Numbers Behind the Book

After all the planning, writing, and editing, let's look at the results:

Readership

• Total readers: 810

  • Ebook copies: 728 (+11 refunds = 1.5%)

  • Physical copies: 82

Financial Results

• Leanpub royalties to date: $11,138.88

• Amazon KDP royalties: pending

Pricing Insights

During the period of the two-tier pricing model, the purchasing patterns were revealing:

• 65% of readers chose the minimum price

• 35% opted to pay above minimum

  • Most paid between $21-26

  • About 10 readers chose to pay even more

Time Investment

• Total hours: approximately 850

  • Pre-launch work: 753 hours

  • Post-launch activities: ~97 hours

Costs

• Copy editor: ~$1,000 (usually it costs between $1,000 and $2,000)

• Leanpub Pro Plan: $12.99/month

• Grammarly: $90/4 months (1x quarterly + 1x monthly plan)

• Deepl Pro: ~$10/month

• Facebook & Google Ads: $100

Reader Response

• Goodreads Rating: 4.83

Unexpected Surprise

Just days after publication, I received an incredible opportunity—an invitation from GOTO Book Club, probably the biggest tech book club in the world, to discuss my book in an interview. With their YouTube channel reaching 1 million subscribers, this was exactly the kind of exposure I was hoping for. The interview took place on September 6, just a week and a half after the book's release.

What made this even more special was that I could choose my interviewer. I invited Artur Skowroński, and we had a fantastic conversation. You can watch the recording here:

Final Reflections

Looking back, do I feel happy about publishing my first book? It is complicated. My initial goal was ambitious—5,000 sales in the first year. That turned out to be naive, but I am still on track to reach 1,000 sales, which I later learned is actually quite an achievement for a first-time self-published technical book.

The journey taught me invaluable lessons: how to write clear, accessible content, how to structure complex knowledge, and it significantly improved my written English. My beta readers and reviewers opened my eyes to new concepts I hadn't considered. And there is no better feeling than hearing someone say it is the best software architecture book they have read.

But I have to be honest—the writing process was exhausting. The creative aspect is a double-edged sword. It is incredibly engaging and interesting, but it drains your energy over the long run. At this point, I can't even think about writing another book.

Still, there is something incredibly rewarding about seeing a years-old dream become reality.

So, is writing a book worth it? Absolutely. Would I write another big book right now? No way—I am completely drained.

Good luck, and fingers crossed for your own writing journey!