About Dividend.watch
Dividend.watch is an investment platform for tracking users' stock portfolios. For their users, reliability is everything, and downtime means missed alerts and frustrated customers.
So when their platform started crashing every few days, it quickly became a business-critical problem. At that point, the team didn’t yet know what was causing the instability; only that internal firefighting wasn’t leading to a solution. The team was also in the middle of preparation for acquisition, actively talking with several prospects interesting on purchasing the app. These issues were blocking the deal.
Aleš Chromec, Dividend.watch co-founder, made a crucial decision: to bring in external help rather than continue firefighting internally. That decision would prove pivotal.
TL;DR
Dividend.watch reached out when their product began experiencing recurring crashes that were difficult to diagnose. The team knew the application was unstable, but the root cause wasn’t clear. Together, we investigated the issue and traced the crashes to a memory leak caused by architectural patterns that weren’t releasing memory as expected. I helped stabilize the platform and worked with the team to define a clear plan for refactoring the backend.
With stability restored, the team took ownership of the improvements, successfully refactored the backend, and moved toward a serverless approach. This shift reduced operational burden. The decision to bring in support at the right moment, combined with the team’s execution, strengthened the platform’s technical foundation and helped position the company confidently for an acquisition that successfully happened a few months later.
How We Found the Root Cause
The engagement began in a collaborative, hands-on way. Aleš created a dedicated Slack channel and invited me to join, allowing us to share insights. I adapted to their workflow, keeping all discussions and data within their environment.
We started testing hypotheses in their staging environment. However, because the issue only appeared under heavier load, some controlled experiments in production were necessary. I deployed enhanced logging and memory metrics to gain visibility into the system’s behavior under real-world conditions.
It soon became clear that this was not a simple bug. The app’s instability stemmed from architectural patterns that retained memory longer than necessary. A quick patch wouldn’t be enough.
To buy time for a proper fix, I proposed a temporary workaround:
- Introduced a load balancer and ran the app across multiple instances
- Monitored memory usage per instance
If an instance exceeded thresholds for too long, traffic automatically shifted to healthy nodes, and the “unhealthy” instance was restarted to mitigate the memory leak before it could impact users
This gave us stability and breathing room to focus on the real solution: refactoring the backend to eliminate the architectural issues.
Fixing the Root Cause
The root cause wasn’t a single function. It was a systemic architectural problem. To be more specific, long-running WebSockets were used for real-time communication with the frontend, but they weren’t properly freeing memory, which led to slowly consuming resources until the app crashed.
After pinpointing and fixing the problem, the team took ownership of the backend rewrite. Together, we designed a clear, actionable plan for refactoring. With firefighting reduced, the team could execute the improvements themselves.
The Results
- Near-zero downtime: The app went from crashing every few days to running reliably
- Higher developer confidence: Refactoring made the backend predictable and maintainable
- Simpler, more modern stack: Serverless adoption reduced load on main servers
- Business impact: A stable, reliable product positioned the company strongly during the acquisition
The memory leak had put the entire product at risk, but Aleš’s decision to get help at the right time, combined with the team’s execution, saved the platform and strengthened the company’s technical foundation.
Final Thoughts
In this case, what began as an unstable application became a catalyst for meaningful architectural improvements, renewed team confidence, and long-term business success.
And personally, I believe Aleš made the right call to bring in support at the right moment. Together, we stabilized the platform, refactored the backend, and prepared the product for acquisition.
Sometimes the problems that threaten a product the most are the ones that push teams toward their best decisions, both technically and strategically.
Top comments (0)