Third Time’s the Charm: How We Finally Got LiftTrack to Work
By this point, we were bruised, broke, and borderline burnt out.
But giving up on LiftTrack? Not an option.
After two semesters of failure, fried screens, and Apple-related breakdowns, we pivoted. This time, we went cloud-first — and it made all the difference.
Going Cloud: A New Path
Instead of trying to run everything locally, we deployed our backend to the cloud.
It worked — smoothly. The server was responsive, stable, and scalable.
We thought: finally, a clear path to the finish line.
Then came the new boss: WebSockets.
The WebSocket Roadblock
The goal: real-time communication between the mobile app and the server.
But as always, the universe had other plans.
Our ISP didn’t allow port forwarding.
Which meant: our WebSocket connections couldn’t reach the cloud server from the mobile app. No live data flow. No testing. No thesis.
The Pivot (Again)
Just when it felt like deja vu from the first two failures, our thesis adviser gave us a lifeline:
“Use localhost temporarily. Just get the survey done.”
We mocked the server locally. Ran the demo. Collected the data. And completed the survey phase of the thesis.
It wasn’t real-time yet — but it was enough.
The Final Fix
A week later, we found a workaround for the ISP. (Pro tip: don’t rely on a consumer-grade network for serious backend dev.)
WebSocket issue? ✅ Solved.
Cloud connection? ✅ Stable.
Mobile app? ✅ Talking to the server.
We walked into the thesis defense nervous, battle-scarred — but prepared.
And…
We passed.
The End of the Beginning
LiftTrack nearly killed us.
Twice.
But the third time, we stopped chasing perfection and started executing smarter:
- Use the cloud early.
- Don’t rely on flaky ISP rules.
- Always have fallback paths.
- Ask for help — your adviser might just save you with one sentence.
“Victory is sweetest when you’ve tasted defeat — twice.”
Final Notes
LiftTrack is still alive. It’s not perfect. But it exists. It works.
And we will got our degree.
Read the full trilogy: