This story isn’t about building “the perfect tech stack.” It’s about how the pursuit of technical perfection cost me long period of my life as a solo founder, and how choosing simplicity over complexity finally allowed my product to move forward.
If you’re an entrepreneur working with limited resources, struggling to launch your product, or find yourself constantly rethinking your technical architecture instead of focusing on your users, this story isn’t theoretical. It’s a personal experience, and it may help you avoid the same mistakes, allowing you to redirect your energy toward what truly makes a difference.
But to understand how these mistakes impact any founder’s journey, it’s important to see the difficulties and challenges from the very beginning — when an idea is just a vision in your mind, and all you have are limited resources and abundant enthusiasm. This is where the real trap appears: falling into excessive complexity before there is any real need for it.
Between the Initial Drive and the Complexity Trap
My conviction that the industry needed a single platform designed to provide students with everything they need to manage their academic & personal life wasn’t just passing notes— they were my primary motivation to start designing this app as a rescue system from digital distraction. And, as is often the case for most entrepreneurs, the road was far from smooth .
The problem was never the complexity of the idea itself — it’s relatively simple — nor was it a lack of general technical knowledge. I was proficient in Python, familiar with AI technologies, and knowledgeable in other areas. The issue was my limited experience in building applications.
In the world of startups, there is a very fine line between “building a strong product” and falling into the abyss of over-engineering. I fell into this trap entirely of my own volition at the start of my journey, thinking that the quality of a product was measured by the complexity and grandeur of the infrastructure behind it.
Scalability Was a Future Problem I Treated as a Present One
At the start of the project, I chased technical dominance through AWS services. It made sense for a founder in the early days to think: “If Silicon Valley giants use AWS, I should start there to ensure scalability and serve millions of users.”
But the truth that many technical founders overlook is that “scalability” is an excellent problem — but a future problem, not a Day One problem. Designing a system for millions of users before reaching even hundreds often doesn’t accelerate success — it delays it.
Technically, AWS provides a comprehensive infrastructure (IaaS and PaaS) that offers near-absolute flexibility and custom scaling through services like DynamoDB, which can handle hundreds of thousands of requests per second, and Lambda, which scales to execute thousands of concurrent tasks. But this power comes at a steep cost for a solo founder; it requires deep expertise and careful infrastructure management.
I found myself drowning in these complexities, dealing with infrastructure details and trying to build a synchronization feature without ever reaching the result I wanted, due to the sheer number and intricacy of programming issues.
At that stage, I didn’t need a system capable of serving millions of users — I needed a simple interface that users could test, and a reliable sync system that could lay the foundation for future scaling. But I had started from the end instead of the beginning.
When Speed Mattered More Than Theoretical Scale
The turning point came when I decided to stop “chasing the theoretically best” and start “using what’s practically best.” I fully switched to Firebase. While some developers might argue that Firebase (especially Firestore) has hard limits — like 200,000 concurrent connections or certain document size limits (1 MB) — it provides an invaluable advantage for startups: fully serverless auto-scaling without manual intervention.
Firebase gave me tremendous support for real-time synchronization, which is critical for a productivity app that needs tasks and all data updated across devices instantly. Implementing this technology required almost no effort.
Yes, AWS might be more cost-efficient when serving millions of users thanks to options like Reserved Instances, but for a founder with limited resources, saving my time and directing it toward “user experience” was far more important than saving a few dollars on the cloud bill. Besides, most of us won’t need a system capable of handling tens of millions on Day One; starting with complexity designed for a stage you haven’t reached yet — and may never reach — is a strategic trap.
Challenges of Resources and Multiple Technologies
Beyond technical challenges, limited financial flow played a pivotal role in slowing progress. I followed a “phase-by-phase development” strategy based on the available budget. I also found myself struggling with freelance developers who split their focus across multiple projects, making even the simplest feature take several times longer than expected. This combination of scarce resources, a scattered workforce, and a lack of deep experience in application building led to long delays.
The obstacles didn’t stop there. I faced additional challenges while navigating multiple technologies. These included trying to connect Flutter (which I currently use) to DynamoDB databases on AWS, using Gatsby to build the web dashboard for users, and dealing with the resulting accumulation of errors and maintenance difficulties. I also experimented with switching to React Native, but synchronization didn’t work well, adding another layer of development complexity.
After all this drain on time, effort, and money, did I consider giving up? Absolutely not. The determination to make this vision succeed was the driving force behind reevaluating the entire path. The turning point came when I decided to return to the basics; while I had a working “offline” prototype in Flutter, I realized through developer experiences and the tech community that combining Flutter’s smoothness with Firebase’s power was the shortest and most stable path forward.
Once I adopted this approach, the leap happened; what had taken long time of stumbling in other environments was completed in a short period.
For me, this app is not just a product as people see it; it is proof that a clear engineering vision and hard work can yield solutions that change people’s lives, even with limited resources and nearly endless obstacles that could otherwise waste the effort.
Choose Your Technical Battles Carefully
The distraction between stacks — from Gatsby to React Native to AWS — made implementing the idea almost impossible due to accumulated errors and maintenance complexity. Switching to Flutter with Firebase was not just a technical change; it was a strategic decision to embrace simplicity. Firebase provided me with a ready-made backend-as-a-service, eliminating the burden of server management, while Flutter gave me a single codebase for all platforms, multiplying my productivity several times over.
The lesson I took away, which I see as essential for every entrepreneur, is this: leadership is not about using the most complex technologies — it’s about choosing the technology that serves the product vision and accelerates getting the initial version to users.
If technical complexity is preventing you from launching a single feature, it is not “strong engineering”; it is a “technical obstacle” that must be removed immediately. Users don’t care about the cloud architecture or the type of database — they care that the app solves their problem smoothly and with minimal friction.
6 Practical Lessons for Every Solo Founder
1- Scalability is a great problem — but it only becomes important when you actually have real users. Designing a system to serve millions before reaching even hundreds of users doesn’t accelerate success; it slows it down.
2- Time is more valuable than the cloud bill. Saving months of development is far more important than optimizing infrastructure costs in the early stages.
3- A good system launches the product; a perfect system stops it. If your technology delays feature launches, it isn’t serving your product.
4- Users don’t care about system architecture or internal structure. What matters to them is clarity, speed, and whether your product reduces friction and obstacles in their lives.
5- Simplicity is not a compromise — it’s a strategy. This applies especially to solo founders with limited resources.
6- Not giving up is not an emotional trait — it’s a strategic decision. Continuing doesn’t mean blindly sticking to the same tools or the same path; it means having the courage to stop, acknowledge that the current choice isn’t working, and then redirect without abandoning the vision.
Conclusion
My journey was not just an attempt to build an app — it was a true test of my belief that technology should serve humans, not impose its complexities on them. Today, as this app comes to life as a practical solution for reducing distraction and navigating between tools, I look to the future with greater confidence.