I almost didn't build this project.
I thought, "Who am I to build something for real users? I'm still in college. I barely know what I'm doing."
But I did it anyway. And now that app is actively used by more than 500 people.
This is the honest story of how I built it, what broke, what I learned, and what I wish someone had told me before I started.
If you are a beginner in web development, bookmark this. It will save you months.
Why I Built This in the First Place
Many community organizations — especially churches — manage their entire operations through WhatsApp groups, paper notices, and scattered spreadsheets. Events get missed. Announcements get lost. Media files live on someone's personal phone.
I saw this happening firsthand and thought — this is a real problem. And I know enough React and Node.js to attempt a solution.
So I started building.
Not because I was ready. Because the problem was real.
What I Built
A full-stack Church Management Web Application that handles:
- Event scheduling and announcements
- Dynamic media galleries (images, videos)
- A secure admin dashboard for content management
- Real-time updates for community members
The app is live. It has real users. And it has broken in real-world ways I never anticipated when I was writing code locally.
The Tech Stack (And Why I Chose It)
- Frontend React.js + Tailwind CSS
- Backend: Node.js + Express.js
- Database: MongoDB
- Media Storage: Cloudinary
- Deployment: Netlify (frontend) + Railway (backend)
I chose this stack because I was already learning React, and MongoDB made sense for flexible content structures. Cloudinary solved the media storage problem in one afternoon, which would have taken me weeks if I tried to build it myself.
How It Works — The Real Data Flow
Here is the actual flow from admin action to user screen:
- Admin logs into the dashboard and adds an event or uploads media
- Frontend sends an API request to the Express backend
- Backend validates the request and processes it
- Data is saved to MongoDB; images/videos are pushed to Cloudinary
- When a user opens the app, the frontend fetches the latest data via REST APIs
- The UI renders dynamically — no page refresh needed
Simple on paper. Surprisingly complex to get right in practice.
The 3 Moments Where Everything Broke
1. The API data mismatch that took me 2 days to find
My React frontend was sending data in one format. My Express backend expected a slightly different structure. The result? Silent failures — data that appeared to save but never actually did.
I spent two days debugging this before I realized I hadn't standardized my API payload format.
What I do now: Before writing a single line of frontend code, I define the exact request and response structure. I write it down. I test it in Postman. Then I build the UI around it.
2. State that refused to update when it should
Components were not refreshing after data changes. A user would submit a form and the UI would show the old data for another 10 seconds.
The root cause was poor state management — I was mutating state directly instead of triggering proper re-renders.
What I do now: I treat state as immutable. Every update creates a new object. I also use useEffect dependencies carefully instead of leaving them empty and wondering why nothing updates.
3. It worked locally. It broke for real users.
When I deployed, things that worked perfectly on my laptop started failing for users with slower connections or different browsers. Images would not load. API calls would time out.
This taught me the most important lesson of the entire project:
Local development is a lie. Always think about real network conditions.
What I do now: I test on throttled connections. I add loading states and error boundaries everywhere. I assume things will fail and handle it gracefully.
The Moment It Became Real
Three weeks after launch, a volunteer coordinator messaged me:
"The app saved us two hours of work this Sunday. Everyone knew exactly where to be."
That message hit differently than any grade I have ever received.
Your project is not real until a real person tells you it changed something for them. That is the bar. Not a deployment. Not a GitHub repo. A real person, real impact.
Numbers That Kept Me Going
- 500+ active users on the platform
- Handles live event data every week
- Reduced manual coordination effort significantly for the admin team
- Taught me more in 3 months than a semester of coursework
What I Would Do Differently Today
If I rebuilt this from scratch, here is what I would change:
- Add JWT-based authentication from day one (we had to retrofit this later — painful)
- Set up proper error logging with a tool like Sentry before going live
- Build a proper API contract document before writing any code
- Add automated tests for critical API routes before deployment
- Use environment variables correctly from the start (I hardcoded some things locally that caused embarrassing bugs)
The Real Lessons — The Ones No Tutorial Teaches You
1. Debugging is the actual job.
Writing code is maybe 30% of development. The rest is figuring out why it does not work.
2. Real users find bugs your tests never will.
Your localhost environment is not reality. Deploy early, even if it is ugly.
3. Data flow is everything.
If you understand how data moves from database to screen, you can debug anything. If you do not, you will always be guessing.
4. Shipping beats perfecting.
I was going to add authentication before launching. I was going to redesign the UI. I was going to add real-time notifications. Instead, I launched with what I had — and real feedback made it 10x better than my solo perfectionism would have.
5. Backend developers, understand your frontend. Frontend developers, understand your backend.
I started as a frontend developer. This project forced me to understand backend, APIs, databases, and deployment. That cross-knowledge is what makes you valuable.
Who This Is For
If you are a college student sitting on a half-finished project — finish it. Deploy it. Share it with five real people. Watch what breaks.
You will learn more in one week of real-world usage than in three months of tutorials.
The gap between "I can code" and "I can build things people use" is not talent. It is just willingness to ship, break things, and fix them.
What I Am Building Next
- Authentication system with role-based access
- Real-time notifications using WebSockets
- Mobile-first redesign
- Performance improvements for slower connections
Final Thought
Before this project, I used to say: "I am still learning."
Now I say: "I build things people use."
That shift in identity — from student to builder — is worth more than any certificate.
Go build something real.
I am Aswini SM, a 3rd-year ECE student at Panimalar Engineering College, Chennai. I build full-stack web applications and am currently exploring enterprise technologies. You can find my work at https://aswini-sm-portfolio.netlify.app and https://github.com/Aswini1008