
Phone Price Comparison System
A full-stack phone price comparison platform built as my first backend-heavy project, focused on real-world use cases and backend learning.
Timeline
2 months
Role
Full Stack Developer
Team
Solo
Status
CompletedTechnology Stack
Key Challenges
- Backend fundamentals
- Unstructured initial codebase
- Refactoring large codebase
- Designing MVC architecture
- Handling real-world data models
Key Learnings
- Backend development fundamentals
- MVC architecture
- Code refactoring
- Server-side rendering with EJS
- Designing for real-world use cases
Phone Price Comparison System
Overview
The Phone Price Comparison System is my first full-stack and backend-focused project, built as a college project last year. The goal was to create a platform where users could compare mobile phone prices across different sellers and make better purchasing decisions.
This project played a major role in shaping how I think about backend development, architecture, and code organization today.
What Users Can Do
- Compare Phone Prices: View and compare prices of phones across multiple sellers.
- Browse Phone Listings: Explore phones with detailed specifications.
- Search & Filter: Narrow down phones based on criteria.
- Admin Management: Manage phone listings and pricing data.
- Server-Rendered UI: Simple, fast frontend using EJS templates.
Note: The current version uses dummy data, but the system is designed around a real-world use case.
Why I Built This
This project was built as part of my college curriculum, but I intentionally chose a real and practical problem instead of a theoretical one.
At the time:
- Backend development was completely new to me.
- I wanted to understand how servers, routes, databases, and templates work together.
- React was not part of my stack yet, so I used EJS for server-side rendering.
The focus was learning — not writing perfect code.
The First Version (Reality Check)
In the initial version:
- Almost the entire backend logic lived in a single file
- The codebase grew to 2,000–3,000+ lines
- There was little separation of concerns
- Changes became harder as features increased
This version worked functionally, but it was not maintainable.
Refactoring & Architectural Growth
After gaining more backend knowledge, I revisited the project and:
- Refactored the entire codebase into a proper MVC architecture
- Separated routes, controllers, models, and views
- Improved readability and maintainability
- Made the system easier to extend and deploy
This refactoring phase taught me more than the initial build, especially about why structure matters as projects grow.
Tech Stack
- Node.js
- Express.js
- MongoDB
- EJS (Server-side rendering)
- Tailwind CSS
Key Takeaways
- Writing everything in one file works only at a very small scale.
- Code structure matters as much as functionality.
- Refactoring is a skill, not a failure.
- Backend systems should be designed for change, not just correctness.
- Real-world use cases expose design flaws early.
After Build & Impact
- This project became my entry point into backend development.
- It helped me understand MVC architecture practically.
- The learnings directly influenced how I structure later projects.
- It built confidence to work on larger backend systems.
Future Improvements
- Replace dummy data with real retailer integrations.
- Add automated data fetching and updates.
- Improve comparison logic and filtering.
- Enhance admin workflows.
