Series Roadmap
- Product Overview (1/6)
- Architecture: N-Tier Design, Decoupling, and Microservices (2/6)
- Frontend: Angular, NgRx, and OpenAPI Integration (3/6)
- Machine Learning in Practice (4/6)
- Database Design and Data Modeling (5/6)
- Engineering Tradeoffs: Limited Time vs. Ideal Architecture (6/6)
Closing the Chapter: When "Good Enough" is the Engineering Solution
After a year and a half of active development, countless commits, and a steep learning curve, Claprec is finally shipped. This series has documented the journey, but this final post isn't just a victory lap. It is a retrospective on the gritty reality of engineering tradeoffs.
We often read about architecture in a vacuum - perfectly scalable, perfectly optimized. But in the real world, constraints exist. This post covers the tension between limited time and perfection, the architectural debt accumulated, and why I chose to ship a functional app rather than pursue an unattainable ideal.
The Timeline and The "Last 99%"
The first commit for Claprec dates back to October 19, 2022. It wasn't a continuous sprint; life happened. I graduated, worked for a year as a Frontend Engineer, and juggled other projects. However, the final push took everyone's favorite timeline: the "last 1% of work", which inevitably consumes 99% of the effort.
For the last two and a half months, I dedicated intense focus to finishing the app. There were no strict deadlines (post-graduation), only a self-imposed drive to close this chapter.
The result? A functional application. It follows the programmer's iteration mantra:
- Make it functional. (Status: Done)
- Make it performant. (Status: Acknowledged, deferred)
- Make it beautiful. (Status: Secondary priority)
For a demonstration of skills and a valid product delivery, functional is sufficient.
Architectural Decisions: The N-Tier Constraint
One of the defining constraints of this project was the architectural requirement: N-Tier Architecture.
If I were starting from scratch today with total freedom, I would likely lean towards Clean Architecture for better dependency inversion and maintainability. However, N-Tier was a requirement for my university curriculum, and it taught me a critical lesson: strict boundary enforcement.
The Trap: The Distributed Monolith
My biggest mistake in the early stages was being loose with tier boundaries. I paid the price later. Refactoring a specific part of the primary microservice to restore proper separation of concerns took me two intensive weeks of full-day work.
In N-Tier, if you aren't strict, you are heading for a disaster.
The Silver Lining: Velocity
Despite the complexity of N-Tier, there is a distinct advantage: speed of entity creation. Once the layers are in place, adding a new entity with full CRUD functionality is incredibly fast. This allowed me to build out the backend logic rapidly when I needed to.
Performance and Scalability: The Reality Check
Let's be honest about the state of the shipped product. The application is visibly slow.
The Immediate Missing Piece: There is no caching layer.
- Immediate priority: Implementing Redis to offload read pressure and reduce latency would be the first commercial step. Without it, the database takes the full hit of almost every request.
- Media delivery: For media files (pictures and documents), I would use a CDN. A key advantage is that the database and the backend already support this setup, so the infrastructure is ready for integration whenever a CDN is provisioned.
The Deployment Reality
- Current setup: Deployed to a VPS using Docker and Nginx.
- Why: It works. It was fast to set up.
- The tradeoff: This is not a scalable architecture for a million-user startup. It is a monolithic deployment on a single node.
The Cloud-Native "What If"
If I were architecting this for high-scale production, the roadmap would look vastly different:
- CI/CD: GitHub Actions for automated testing and deployment pipelines.
- Orchestration: Kubernetes (K8s) for auto-scaling and self-healing.
- Infrastructure as Code: Terraform for reproducible cloud provisioning.
- Observability: Prometheus + Grafana for real-time metrics and alerting.
While the current VPS setup lacks the bells and whistles of a cloud-native stack, it fulfills the project's primary goal: it works.
Technical Debt & Hard Lessons
Engineering maturity isn't about writing perfect code; it's about knowing which corners to cut and understanding the cost of doing so. Here is my itemized bill of technical debt:
The Debugging Gap
A key mistake was not measuring execution times during development. I treated performance as an afterthought rather than a feature. This led to "visibly slow" endpoints that require painful retrospective optimization.
Thread Safety Nightmares
I initially neglected thread-safe operations. This was a significant mistake. It produced elusive bugs that I had to solve later - often under pressure. Lesson: concurrency issues do not fix themselves; they compound interest.
Polyglot Persistence
Retrospectively, forcing a relational database for everything was a mistake.
- Better Approach: Use specialized storage. For example, a write-optimized time-series database for activity logs, and NoSQL database for archives and logs. This separation would significantly improve performance by aligning each data type with a storage system optimized for its access and write patterns.
The Frontend Grind: 101 Pages
On the frontend, the tradeoffs are visible. I built 101 pages under tight deadlines.
- UX Polish: Sacrificed.
- User Flows: Inconsistent in places.
This is the reality of feature completion. In a startup environment, often "it works" beats "it looks perfect".
Evolution of Tooling: LLMs
This project was started before ChatGPT existed. Throughout the lifecycle of Claprec, I witnessed the explosion of LLMs.
I integrated them into my workflow, watching the tooling evolve. They are fantastic helpers for some parts of software engineering - generating boilerplate, clarifying language details, writing tests, and drafting standard functions.
However, this journey reinforced a crucial distinction: actual engineering and debugging cannot be fully solved by LLMs. LLMs, built on gradient descent and backpropagation, are powerful tools, but they cannot solve novel problems that haven't been documented on the internet yet. You still need to know what to ask and why the answer works.
Bonus: Book Recommendations
Throughout the development of Claprec, I read a few books to help guide my decisions. These are of quality and I highly recommend them:
RESTful Web Services Cookbook by Subbu Allamaraju was extremely useful for the backend. It helped me design my API, ensuring that the result is a standardized REST API that strictly follows REST practices.
On the frontend side, Universal Principles of UX by Irene Pereyra and Refactoring UI by Adam Wathan & Steve Schoger were very helpful resources. They provided the theoretical and practical advice I needed to navigate the design process.
Closing the Chapter
Claprec is not perfect. It is slow in places, the UX needs polish, and the architecture carries the scars of university constraints. But it is a bridge between academic theory and real-world product delivery.
This project tested my endurance and discipline. It is a testament to the fact that finishing is a skill in itself.
If you prefer video format, I also published a video containing all six videos from the LinkedIn series in their original, unmodified form and sequential order, providing high-level overviews of the engineering decisions behind Claprec: Watch it on YouTube.
What's Next?
I am closing the book on Claprec to focus on new challenges.
- Side projects: I'm considering new challenges: engineering a system capable of handling 3 million HTTP requests per second, learning TLA+ or Verilog, or working on an interesting embedded systems project.
- Professional opportunities: I am open to new roles. If my experience with Claprec (.NET, Angular, MSSQL) - along with my experience in Next.js (React), Vue.js, Laravel (PHP), Node.js, and Python - matches what you or your company needs, let's talk (Linkedin).
I want to acknowledge Haris Kordić for contributing during the initial stages of the project, including the product vision, design prototypes, and backend implementation.
I also want to acknowledge Benjamin Markanović for his feedback on design decisions throughout the project, and Haris Sejmenović for helping with testing and validating the application before release.
Thank you for following this series.
If you enjoyed this deep dive, please feel free to connect with me on LinkedIn. I will be posting a special closing update there shortly where I share a personal milestone: receiving the Rector's Award for academic achievements.
It is good to close this chapter. Now, onto the next build.
With the series now complete, I'd love to hear your thoughts on these tradeoffs or the entire project in the comments below.