🚀 AllWDbook — From Idea to Launch
AllWDbook Build Journal
Why I Created AllWDbook: The Problem I Wanted to Solve for Publishers
The story behind AllWDbook and the practical publishing problem that led to building a focused platform for digital publishers.
AllWDbook did not begin with a plan to launch another website, and it did not begin with a search for a product idea to sell. It started with problems I was experiencing myself every time I worked on a new Amazon KDP project.
As a publisher, I repeatedly moved through a chain of connected tasks: choosing and narrowing a niche, researching keywords, exploring micro niches, following competitors, trying to understand the market, and then dealing with practical details such as getting the book cover dimensions right.
Over time, I realized that the real problem was not one difficult task. It was the fragmentation of the entire workflow. I had to move between different tools and services, while the combined cost of the paid tools I personally used exceeded $100 per year.
That led to a simple question: why not build one place for myself that brings together the tools I actually need as a publisher?
At first, the goal was personal. I wanted to solve my own problem. But while building the solution, I began to realize that other publishers were likely dealing with at least some of the same friction. That is how AllWDbook gradually changed from a set of tools I wanted for myself into a platform intended to help other publishers too.
The Real Problem Was the Workflow
It is easy to describe Amazon KDP work as a collection of separate tasks. Keyword research is one task, niche selection is another, competitor research is another, and cover preparation is something else. In real publishing work, however, these decisions are connected.
A book idea can look promising until research shows that the niche is too broad. That may lead to a more focused micro niche, which creates new keyword questions. Then comes the need to examine what already exists in the market and understand the competitive environment before investing more time in the project.
For me, this meant constantly moving between stages and tools. I was not looking for a magic button that could publish a successful book automatically. I wanted a more organized way to handle the repetitive research and preparation surrounding each project.
That changed the question behind AllWDbook. Instead of asking only how to build a keyword tool or a cover tool, I started asking how several recurring publisher needs could exist within one more coherent workflow.
Cover Dimensions: A Small Problem That Keeps Returning
One of the practical issues that repeatedly frustrated me was getting cover dimensions right. Compared with market research, this may sound like a small problem, but repetitive small problems consume real time.
A cover is not simply an image added at the end of a project. Its dimensions need to match the project requirements before the final design or export is prepared. When this becomes a recurring part of publishing, unnecessary uncertainty around dimensions creates friction.
That experience influenced how I thought about AllWDbook. I did not want to focus only on features that sound impressive. A useful tool can also remove a small step that a publisher has to repeat again and again.
This eventually became one of my basic product questions: does this feature solve something that actually happens during the publishing workflow? If the answer is no, adding another feature simply to make the platform look larger does not create much value.
Keywords, Niches, and Micro Niches
Research created another major source of friction. Having a book idea is only the beginning. As a publisher, I still need to understand where that idea fits and whether it should be narrowed into a more specific direction.
This is where keywords, niches, and micro niches connect. I was not simply trying to generate lists of words. I was trying to answer connected questions: Is this topic too broad? Can I narrow it? Which search terms relate to the direction I am considering? What does the market look like when I investigate it further?
For that reason, I do not see keyword research and micro-niche exploration as completely isolated activities. In a real workflow, one can lead back to the other. A keyword can reveal a direction worth investigating, while a niche decision can create a new set of keyword questions.
The purpose of a tool should not be to make the publishing decision for the user. Publishing still requires human judgment, market understanding, and a good product. The useful role of software is to reduce research friction and help organize the information behind those decisions.
Competitor Research Is Part of Understanding the Market
Once I had a direction in mind, I also needed to look at competitors. Competition is not simply something to avoid. Existing books and products provide information about the market.
What appears in the results? How are competing books positioned? Which topics keep appearing? Where does the market look crowded, and where might there be a more specific angle worth investigating? None of these questions guarantees that a book will succeed, but they can make a decision less dependent on guesswork.
Again, fragmentation was the problem. When niche exploration happens in one place, keywords in another, and competitor research somewhere else, the information becomes separated from the context in which I need to use it.
This is why the idea behind AllWDbook became increasingly focused on workflow rather than simply the number of tools available. Ten unrelated tools do not automatically create a useful platform. Each tool needs to correspond to a real part of the publisher's work.
When My Tool Costs Exceeded $100 per Year
Fragmentation was not the only issue. Cost also mattered. The combination of paid tools and services I personally used for different parts of my KDP work cost me more than $100 per year.
That figure describes my own experience. It is not a claim that every publisher spends the same amount or that every KDP tool costs that much. For me, however, it was enough to raise an important question: did I want to keep paying for multiple services to perform a collection of tasks I needed repeatedly?
Paying for specialized software can make complete sense when it delivers clear value. Software has real development and operating costs. The problem for me appeared when several subscriptions and services started accumulating around one publishing workflow.
For a publisher who is still testing ideas or publishing a limited number of books, recurring software expenses can become a meaningful part of the project budget. I wanted to explore whether the specific functionality I needed could be brought together in a more focused and accessible way.
Why I Built the Solution for Myself First
At this point, I did not have a grand story about starting a company. The idea was much simpler: if these problems keep appearing in my own work, why not build the tools I need myself?
That changed the starting point. Instead of asking what product I could sell, I started with a different question: what genuinely frustrates me during my publishing workflow, and which parts can I simplify?
This distinction matters to the AllWDbook story. Cover sizing was not included because it sounded good on a sales page. It came from a problem I had experienced. Keywords, niches, and micro niches were not added simply because they are popular KDP terms. They were already part of the work I was doing.
Being the first user of your own product can make certain problems easier to identify because you experience the friction directly. It also creates a risk: your personal workflow is not automatically everyone's workflow. As AllWDbook developed, that distinction became increasingly important.
From a Personal Tool to AllWDbook
While building, the idea began to change. If I was struggling with cover dimensions, keyword and niche research, micro niches, competitor tracking, and the accumulated cost of different tools, other publishers were likely experiencing at least some of the same problems.
That was the point where the project moved from "tools I use" toward "a platform another publisher can use." This transition is bigger than it sounds. A personal tool can make sense to its creator even when the interface is rough. A product for other people needs clearer organization, design, and usability.
AllWDbook gradually came to represent that broader idea: a place where tools related to books and digital publishing can live together instead of requiring the publisher to assemble an entire workflow from disconnected services.
The goal is not to claim that the platform can guarantee a successful book or discover a profitable niche with one click. KDP is more complicated than that. The goal is to support research, organization, and preparation while leaving the final evaluation and publishing decision with the publisher.
The Original Cost Problem Also Influenced Access
Because software cost was part of the original problem, I could not ignore pricing and access when AllWDbook began turning into a product. I wanted the platform to remain approachable for publishers who do not want to add another collection of expensive subscriptions to their workflow.
Low price alone, however, does not make a useful product. A cheap tool that saves no time and solves no real problem is still a poor tool. The priority therefore remained the usefulness of the functions and their connection to actual publishing tasks.
The same preference for simplicity influenced the access model. I did not want a traditional email-and-password account to be mandatory for normal access. AllWDbook therefore developed around an AWD-KEY access key that can also be used to restore access on another device, with an optional recovery or security email.
This may appear separate from the original publishing problems, but the principle is connected. If the platform exists to reduce friction and fragmentation, adding unnecessary friction to the way users access it would work against that goal.
What I Do Not Want AllWDbook to Become
Publishing tools can easily fall into the trap of making oversized promises: find the perfect niche, guarantee sales, or discover keywords that will make any book successful. That is not how I want to present AllWDbook.
Software can help with research, calculations, organization, comparisons, and preparation. It cannot remove the natural risk involved in publishing, and it cannot replace book quality, understanding the reader, or making sound market decisions.
I believe a more useful product clearly communicates what it can help with instead of promising outcomes it cannot guarantee. AllWDbook should remain a practical toolkit for publishers rather than a machine that sells shortcuts to success.
The same principle applies to the content around the platform. When I document a workflow or experiment, the goal is to explain the process, what happened, and what can be learned from it—not to present one example as a universal rule for every book and every market.
The Biggest Lesson: Start with a Repeating Problem
If there is one lesson I take from the beginning of AllWDbook, it is that a product idea does not always have to begin with something nobody has ever seen before. Sometimes it starts with a small problem that happens repeatedly.
Cover dimensions alone did not create AllWDbook. Keywords alone did not create it. Micro niches alone did not create it. Even software cost alone was not the reason. The real need appeared when these problems accumulated inside a workflow I experienced again and again.
Once I put those points together, the direction became clearer. I wanted fewer places to jump between, a more organized research process, simpler handling of repetitive tasks, and a more focused alternative to paying for multiple disconnected needs.
That is how AllWDbook began: not as a finished product searching for a user, but as a solution that started with one user who had a clear problem—me as a publisher. Once that solution began taking shape, the next challenge was making it useful to other publishers too.
This Is Only the Beginning of the AllWDbook Story
Finding the idea was not the hardest part. Turning it into a real platform created an entirely new set of questions. What should it look like? How should it work on a phone? How do we keep loading fast? How should paid access work? How do we build for Arabic and English without creating a confusing experience?
Some decisions worked well, while others required diagnosis and changes. At one stage, for example, the site developed a visible loading flash. The real solution came from identifying the underlying styling problem rather than continuing to add patches around the symptom.
Those experiences are now part of the product story. This article is therefore the beginning of the AllWDbook Build Journal, where I will document decisions, problems, fixes, and lessons from turning a personal idea into a working web platform, supported by real examples and project screenshots whenever useful.
If AllWDbook started with one question—why not build the tools I need myself?—the next stage raised a harder question: how do I turn those tools into a real product that somebody else can open and use? That is where the next part of the story begins.