This project did not start to solve a problem
Most development articles begin with the sentence, “This started to solve a problem.” The moment a reader sees that sentence, they feel reassured. They assume there was a reason, a direction, and that technology choices were made along that direction. However, most real-world personal projects do not start that way. It is actually rare for a project to begin with a clearly defined problem followed by a structured search for a solution. In most cases, it starts from a vague discomfort or a subtle sense that something is off, something that cannot easily be articulated. This project was no different. There was definitely discomfort, but it was impossible to clearly define what the problem actually was. The decision to “build something” at that point was not the result of structured reasoning, but closer to an impulse.
To be more precise, this project did not have a clearly defined target to solve from the beginning. There was a sense that a reading record app was needed, but it was not possible to clearly explain why existing services were insufficient. There was only a lingering feeling that “something is different,” and that feeling accumulated over time until it eventually crossed a threshold. This point is critical. A project that begins without a clearly defined problem cannot have a correct design from the start. Design is built on top of a problem definition, and if the problem itself is vague, the structure built on top of it will inevitably be vague as well. Ultimately, the starting point of this project was not an attempt to solve a problem, but a state of being unable to tolerate an undefined discomfort.
A project that begins this way naturally carries a certain characteristic. Because the direction is not defined from the start, it becomes difficult for subsequent decisions to maintain consistency. Some decisions appear correct, while others later reveal themselves to be fundamentally flawed. This is not an exceptional case but rather the default state. The moment a project starts without a clearly defined problem, design stops being a plan and becomes exploration. And this exploratory process is almost never recorded. We tend to leave only the final results behind, removing all the confusion and ambiguity that preceded them. This series begins precisely from that removed space.
That is why we always start with the wrong design
When a project begins without a properly defined problem, people naturally fall back on familiar patterns. There is no solid basis to construct a new structure. As a result, choices become less about logical reasoning and more about automatic responses based on experience. Structures used in the past, patterns already understood, and technologies that feel comfortable are unconsciously pulled into the design. The same thing happened in this project. At the beginning, the structure was shaped with the thought, “This should be enough,” and that structure was not significantly different from approaches used many times before. At that moment, nothing seemed wrong. In fact, it felt stable and well-proven.
However, as time passes, it becomes clear what assumptions those decisions were built upon. And most of those assumptions turn out to be incorrect. Because the problem was never properly defined, the design gradually begins to diverge from actual needs. At first, this appears as minor discomfort, but it eventually expands into something that destabilizes the entire structure. What matters here is not the fact that the design was wrong. What matters more is that it was inevitable to be wrong from the beginning. We often interpret flawed design as a mistake in judgment, but in many cases, it is an unavoidable outcome shaped by the initial conditions.
At this point, many development articles distort reality. Most are written as if the correct decisions were made from the beginning, as if the design was completed in a single pass. But real development is the opposite. Initial decisions are often wrong, and improvement happens through repeated correction of those mistakes. This series does not hide that premise. Instead, it places it at the center. We start with the assumption that the structure we build at the beginning is not just likely to be wrong, but almost certainly wrong. And the core flow of this series is to follow how that wrongness reveals itself.
Design is not created, it is revealed through collapse
Viewing design as a finished product oversimplifies the reality of development. We often describe design as something that is “created,” but in practice, collapsed designs provide far more insight than completed ones. In this project, the initial structure appeared stable for a short period of time. Features worked, data flowed, and the system seemed usable without major issues. However, that sense of stability did not last. Under certain conditions, the structure began to behave in unexpected ways, and from that moment, the assumptions behind the original design started to break apart one by one.
What is interesting in this process is that more becomes visible not when the design is modified, but when it breaks. It is in failure that the rigidity of certain parts, the misalignment of data flows, and the incorrect assumptions become most apparent. And this failure is not merely an error. It is closer to a signal indicating how the system needs to be restructured. The problem is that in most cases, this process is never recorded. Failures are removed, and only the corrected results remain. As a result, the reasoning behind the final design becomes impossible to trace.
This series focuses on that removed process. Instead of showing how a design was created, it follows how it collapsed. It reveals how initial assumptions failed, how those failures forced new decisions, and how those decisions in turn created new problems. This approach may feel uncomfortable to read. For readers who want quick answers, it may seem inefficient. But the essence of design lies not in the result, but in the process. Results cannot be reproduced, but processes can. This series exists to preserve that process.
We Are Trying to Record Failures, Not Results
If we accept the flow discussed earlier, the form this series should take becomes almost inevitable. If design is revealed through failure, then the record must also be centered not on success, but on failure. Yet most technical writing makes the opposite choice at this exact point. Failures are removed, and only the refined results remain. Code is reconstructed into its cleanest possible form, and the decision-making process is simplified. As a result, the writing becomes easier to read, but at the same time, it becomes impossible to reproduce. The context that explains why a structure was chosen, and under what conditions that choice breaks down, disappears.
In this project, that direction is deliberately rejected. What this series deals with is not “how to build something well,” but how things failed, and how those failures forced specific decisions. Failure is not just an error or a bug. It is an event that exposes the limits of a design. And the moment such an event occurs, the existing criteria for decision-making are no longer valid. At that point, new criteria must be constructed. What matters is documenting how those criteria emerged. Only then can subsequent decisions be understood. If only the result remains, it carries no meaning outside its original context.
As you read through this series, there will be moments where conclusions feel unclear. At times, you might even find yourself asking, “So what is actually the right answer?” But that question itself is closer to the intent of this work. We are not trying to provide answers. Instead, we focus on revealing why certain choices were wrong in specific contexts. Through that process, the reader is expected to construct their own decision-making criteria. This is the fundamental difference between result-oriented documentation and failure-oriented documentation. Results can be copied, but judgment must be reconstructed. This series is built on that assumption.
The Unit of This Series Is Not Features, but “Design Collapse”
At this point, a natural question emerges. What should be the unit of this series? Most technical writing is organized around features. Login implementation, data storage structure, UI composition—each piece is separated by clearly defined functionality. This approach is intuitive and easy to follow. However, in this project, that structure is not appropriate. The moment we divide the narrative by features, the continuity of how design collapses gets lost. A single feature is built upon multiple assumptions, and when those assumptions break, the boundaries defined by features lose their meaning.
For that reason, this series is organized around points where design collapses. Each article focuses on one collapse. That collapse usually follows a recognizable pattern. There is an initial assumption, and a structure is built on top of it. At first, everything appears to function correctly. But under certain conditions, that assumption breaks. At that moment, the existing structure can no longer be sustained, and a new decision is forced. That decision, in turn, creates another assumption. This chain forms the fundamental unit of each article. In other words, each piece begins with “what assumption was made” and ends with “how that assumption broke.”
Choosing this structure changes the nature of the writing itself. Each article is no longer an independent tutorial, but a continuous record that can only be fully understood on top of previous entries. Reading a single piece in isolation may feel incomplete. But when read in sequence, a coherent flow emerges. This approach demands more attention from the reader, but in return, it conveys the transformation of design far more accurately. What matters is not the feature itself, but why that feature had to evolve into its current form. This series places that “why” at its center.
This Series Follows the Order of Thought, Not the Order of Time
At this stage, one more decision remains. Should this process be recorded in chronological order, or should another structure be used? Most development logs follow a timeline. They proceed in a sequence such as: “first this was built, then this was added, and later this issue appeared.” This approach feels natural, but it also distorts a significant amount of information. Real thinking does not unfold in a strictly linear timeline. Some decisions only reveal their meaning much later, and some choices are revised by returning to earlier stages. Time reflects the order of events, but it does not explain the structure of reasoning.
This series is organized around the flow of thought rather than the flow of time. It focuses on how one decision constrains the next, and how certain assumptions distort the structure that follows. In this approach, revisiting earlier stages is not an exception, but a necessity. Even if something has already happened, if its meaning becomes clear later, it is brought back and re-examined. What matters is not when something occurred, but in what context it should be understood. This method inevitably makes the writing more complex. But if the goal is to reveal the true structure of design, this level of complexity cannot be avoided.
When the narrative is constructed this way, the reader follows not just a sequence of events, but a chain of reasoning. You begin to see why certain decisions were made, and how those decisions imposed constraints on what came next. This is fundamentally different from simply delivering information. It may feel uncomfortable for readers who want quick answers, but it provides far more insight for those trying to understand design itself. In the end, this series is less about “what was built” and more about how the thinking evolved. And that evolution rarely follows a straight line.
So This Series Will Feel Uncomfortable to Read
If you accept the structure described so far, then the reason this series does not read like a typical development article is already determined. We deliberately avoid summarizing results, we do not remove failures, and we expose the flow of thought as it is. When these three choices overlap, the text naturally becomes less smooth. Some sentences may feel abruptly cut off, and some transitions may seem like they are going backward. The reader may begin with the expectation of reaching a clear conclusion, but that conclusion does not arrive immediately, creating a sense of friction. However, this discomfort is not a flaw in writing; it is the direct result of a structural decision. In fact, if something reads too smoothly, it is often because a significant portion of the process has already been removed.
In this series, discomfort is not something to be avoided; it is an intentionally preserved signal. Real design processes do not unfold like polished sentences. Directions shift midway, and there are repeated moments where previous decisions must be rejected. Some judgments only gain meaning much later, and some conclusions are eventually withdrawn. This process is inherently non-linear, and therefore the reading experience inevitably reflects that non-linearity. The discomfort you feel while reading is a trace of that structure. We do not remove it, because it is closer to the actual nature of design.
This discomfort ultimately forces a shift in how the reader approaches the text. A mindset focused on quickly extracting conclusions does not work well here. Instead, each sentence must be treated as a unit of judgment, and the reader must follow how those judgments connect. This process requires more attention, but it also provides far more context. The point is not that the text is unfriendly to the reader, but that it offers a different kind of consideration. Instead of delivering conclusions easily, it exposes the structure of thinking itself. This choice introduces discomfort, but that discomfort functions as information.
How This Series Should Be Read
At this point, the way this series should be read follows naturally. If approached like a tutorial, most of the content will feel misaligned with expectations. Questions such as how to implement a specific feature, which technology should be chosen, or what constitutes the optimal structure are not directly addressed here. Instead, the series shows why those questions arise and how they collapse under certain conditions. Therefore, the reading approach must also change. The key is not “what can be learned,” but “what kind of criteria are being formed” throughout the process.
When reading each section, the focus should not be on remembering results, but on observing where judgments shift. What assumptions were made, why those assumptions could not hold, and what alternatives emerged at that point—these are the elements that matter. Through this process, the reader does not acquire a single answer, but rather multiple frameworks for decision-making. These frameworks are not meant to be copied directly. They must be reconstructed according to each individual’s context. This series is built on that premise. Reading itself becomes a form of design.
This way of reading may initially feel unfamiliar. However, after going through a few sections, patterns begin to emerge. You start to see which choices repeat under certain conditions, which assumptions tend to break, and how the structure shifts in response. The moment you recognize these patterns, the series stops being a simple record and begins to function as a reference framework. What matters is not memorizing content, but understanding how judgment moves. This series does not explain that movement directly; instead, it is revealed through the flow itself.
What This Series Does Not Cover
By now, it should be relatively clear what this series attempts to cover. It is equally important to define what it intentionally leaves out. This series does not recommend specific technology stacks. It does not conclude which frameworks are better or which architectures are more efficient. It does not present a finalized structure as a reference. The typical “this is how you should do it” guidance found in most development articles is deliberately removed. This is not an omission, but a conscious exclusion, because such information, when presented without context, often reinforces incorrect assumptions.
Additionally, this series does not aim for optimization. Questions about faster methods, more efficient structures, or lower-cost implementations are not central here. Such outcomes may appear as a byproduct, but they are not the goal. What matters is not the result of a decision, but the process through which that decision is formed. From this perspective, searching for a definitive answer is fundamentally misaligned with the intent of the series. Instead, understanding why certain choices fail becomes far more important. In this sense, the series diverges significantly from conventional technical writing.
This deliberate exclusion does not narrow the scope of the series; it clarifies it. The moment you define what will not be explained, what must be explained becomes more precise. This series is not about explaining technology itself, but about recording how judgment evolves during the process of selecting that technology. If you expect deep explanations of specific tools, this series will not meet that expectation. But if your goal is to understand how design changes over time, it provides a different kind of insight. And that insight often lasts longer than any predefined answer.
Only now do we return to the starting point
Everything discussed up to this point has been closer to defining how to record rather than actually building something. We began from a state where the problem itself was not clearly defined, which meant we had no choice but to start from a flawed design. We accepted that design is not something that is created in a correct form from the beginning, but something that reveals itself through collapse. Based on that premise, we chose to record failure instead of results, to structure the series around moments of design breakdown rather than functional units, and to follow the flow of thought rather than the order of time. All of these decisions serve a single purpose. They exist to define what this series is trying to do, and equally important, what it deliberately refuses to do.
However, if we stop here, this text remains nothing more than a declaration. No matter how carefully the structure is defined, without concrete examples, it remains abstract. What is needed now is not more definition, but application. And application always begins by returning to the very beginning. In this series, the “beginning” is not the moment when a feature is implemented. It exists much earlier, at the point where nothing has yet been decided. It is the moment when a choice is first made without a clear understanding of the problem. We need to go back to that point. Because every design, in the end, is shaped by the conditions of its origin.
What follows in the next piece is the earliest state of this project. It is a state without organized requirements, without a clear goal, and without even a precise definition of the problem to be solved. Yet it is precisely this ambiguity that shapes every decision that comes afterward. To understand not just what structure was chosen, but why that structure became inevitable, we have to expose this starting point as it was. This series does not hide that state. It places it at the very front. And by doing so, it establishes the foundation that connects every piece that follows.
Only now does this series become ready to move into what can be called an actual development narrative. Up until now, we have defined how things will be recorded. From here on, we begin to explore what will actually be recorded. The separation between these two stages matters. Without first defining the method of recording, any attempt to document the process inevitably falls back into a result-driven narrative. We went through this preparation to avoid that exact outcome. And now, standing on that foundation, we begin to follow the real sequence of choices that were made, and the ways in which those choices eventually collapsed. This is where the series finally begins to move.
