Over the past year, I've been building a project called WORK Network, a community-focused rewards platform designed around participation, progress tracking, and weekly rewards.
Like many side projects, it started as a simple idea and gradually evolved into something much larger.
One of the biggest lessons I learned is that building the app is often easier than building the systems around it.
The Technology Stack
The current platform is built using:
- Flutter
- Firebase Authentication
- Cloud Firestore
- Firebase Cloud Functions
- Firebase Hosting
Flutter allowed a single codebase for Android and iOS, while Firebase significantly reduced backend complexity.
The Real Challenge: Fair Rewards
Creating screens and buttons was relatively straightforward.
The difficult part was designing a reward system that could remain fair as the platform grew.
Some of the questions I had to solve included:
- How do weekly rewards work?
- How can duplicate rewards be prevented?
- How can progress be tracked accurately?
- How can reward calculations remain consistent across devices?
As the project evolved, reward logic moved away from the client and into backend-controlled systems wherever possible.
Weekly Rewards System
One of the most interesting features is a weekly rewards model.
Instead of focusing only on daily activity, the platform tracks participation over time and allows users to qualify for weekly community rewards.
From a technical perspective this required:
- Weekly snapshots
- Reward qualification logic
- Historical record keeping
- Winner selection processes
- Administrative controls
Building these systems taught me the importance of separating configuration, historical records, and live user data.
Firebase Lessons
Firebase has been incredibly productive, but there are some lessons I wish I knew earlier.
1. Design Data Structures Carefully
Changing Firestore structures later becomes expensive.
Spending more time on schema design early would have saved many migrations.
2. Keep the Backend as the Source of Truth
Any reward system should assume the client can be manipulated.
Critical reward validation should happen on the backend.
3. Plan for Growth
Queries that work for 100 users may not work for 10,000 users.
Indexes, aggregation strategies, and collection structures become increasingly important.
Building in Public
One unexpected benefit has been feedback from early users.
Several features that exist today came directly from community suggestions rather than my original roadmap.
The process reinforced an important lesson:
Users often identify the most valuable improvements long before developers do.
Final Thoughts
WORK Network is still evolving, and there are many features planned for the future.
The journey has been a reminder that successful applications are rarely built in a straight line. They evolve through experimentation, mistakes, user feedback, and continuous improvement.
For developers building their own projects, my advice is simple:
Start small.
Ship early.
Listen to users.
Keep improving.
Those four principles have helped shape every stage of this project so far.
Top comments (0)