Part 1: Determining What to Build

Introduction

This is the first post of a series that documents the whole journey of my third major production-grade project. It is going to contain the whole process from an idea in my mind to a fully deployed web application.

Determining What I'm Going to Build

I wanted to tackle a new challenge centered around real-time systems and complex state management. I also wanted to explore caching strategies and other infrastructure concerns like event-driven architecture.

The First Choice, and Why I Passed on It

My first idea was a live collaborative text editor as a real-time application. But after researching the problem space, I realized that its core engineering challenges (like document synchronization, cursor synchronization, and conflict resolution) are highly specialized problems that are not closely aligned with the areas I want to grow in: backend engineering, system design, and architectural decision-making.

More importantly, these problems are already solved by mature libraries such as Yjs, paired with editor frameworks like Lexical or Monaco. In a real-world project, integrating these libraries is the right engineering decision rather than spending significant time reimplementing this highly specialized logic, which offers limited learning beyond that narrow domain.
As a result, the project's primary distinguishing feature, that is live collaborative editing, is provided by third-party software.

The Second Choice, and Why It Was The Right Fit

After some searching, I found that a collaborative project management platform is a good choice. It naturally introduces a wide range of engineering challenges that add real value to the system. Unlike a collaborative text editor, these challenges arise from the domain itself rather than being artificially introduced to justify additional technologies. They include caching, event-driven workflows, notifications, background processing, authorization, audit logging, search, and real-time synchronization, all working together to support the final product. These are exactly the kinds of problems encountered in production backend systems, providing far more opportunities to practice system design and architectural decision-making.

In the end, my goal wasn't simply to build a real-time application. It was to build a system whose domain inherently demands diverse architectural decisions and production-grade engineering challenges, allowing me to learn far more than a project centered around a single specialized problem.

Choosing the Web Framework

Why not ASP.NET

I had already built two projects using ASP.NET Core and the .NET ecosystem, so I wanted this project to expose me to a different ecosystem.

I chose Python because it is widely used beyond web development in areas such as automation, AI, and data engineering. Rather than building another project with tools I already knew well, I wanted this project to broaden my technical perspective.

Why FastAPI

It's a modern, asynchronous web framework with first-class WebSocket support, making it a natural fit for building real-time applications. Unlike Django and Flask, which require additional libraries or extensions to build WebSocket-based applications, FastAPI provides this capability out of the box.

Furthermore, it has a significantly lighter configuration model than ASP.NET Core, allowing me to move from project setup and infrastructure configuration to implementing application logic much more quickly. This provides a streamlined development experience with minimal boilerplate, enabling me to focus more on the engineering challenges of the project rather than framework configuration. It also provides many capabilities out of the box, including dependency injection, automatic request validation, and OpenAPI documentation with very little configuration in addition to being a high-performance web framework.

What's Next

In the next post, I'll dive into the details of the project, some capabilities of the system and database design.