CineJourney is a private movie club app built for friends and family. The idea came from my love of movies and the movies I share with my partner. Most existing movie platforms focus on individual ratings, reviews, or recommendations. We wanted a place where we could log the movies we watched together and have meaningful discussions about them.
That idea inspired me to build CineJourney.
CineJourney is also a sandbox for me to keep learning and building. I started this project while I was unemployed, and I wanted to continue developing my skills by treating a greenfield project like a real product that could eventually be launched.
Since I am building the application from the ground up, it has given me the opportunity to explore areas beyond simply building features, including software architecture, testing, deployment, CI/CD, realtime systems, and AI-assisted development workflows.
Tech Stack
Language: TypeScript Frontend: Next.js, Tailwind CSS, shadcn/ui Backend & Infrastructure:
- PostgreSQL — Supabase
- Redis — Upstash
- Node.js — Render
- AWS SES
Why I choose Nextjs?
I had already been working with React using React Router and TanStack Query, so I wanted to learn more about Next.js and its full-stack approach.
One of the things that interested me about Next.js was the ability to build the frontend and backend within the same application without needing to maintain a separate backend server from the beginning. For a small application like CineJourney, this keeps the architecture relatively simple while still giving me room to grow.
If the application eventually needs to scale beyond what this architecture is suited for, I can decouple the frontend and backend and introduce a dedicated backend service. That would also give me more flexibility around concerns such as load balancing, rate limiting, and independently scaling different parts of the system.
The main feature
CineJourney is currently under development. The planned features for the first launch include:
- Group creation
- Member invitations
- Movie screening creation
- Discussions for each screening
- Threaded replies
- Reactions
- Group watchlists
Challenges Along the Way
1. Code Architecture
One of my biggest challenges has been figuring out the architecture as the codebase grows.
I was able to establish the basic infrastructure and technologies I wanted to use, but designing the boundaries between different parts of the application has been much harder. As the codebase became larger, I found myself constantly thinking about questions such as:
- Where should this logic live?
- What should this function or module be responsible for?
- How should data flow between layers?
- What should I name this?
- Am I creating unnecessary abstractions?
- Is this architecture going to make the next feature easier or harder to build?
At first, I underestimated how much cognitive overhead this could create. I would sometimes spend more time thinking about where code should go than actually building the feature itself.
This became an important learning experience for me. I realized that good architecture is not just about knowing common patterns or creating more layers. It is about creating boundaries that make the system easier to understand and change as it grows.
I am still actively refactoring CineJourney as I learn more. This has also made me more conscious of the trade-offs of AI-assisted and agentic coding. AI can help me move quickly, but without a clear understanding of the architecture, it can also make a growing codebase harder to reason about. One of my goals with this project is therefore not just to use AI to write code faster, but to develop better judgment about how the code should be structured in the first place.
2. Realtime Support
Another challenge was adding realtime discussion updates.
Rather than relying entirely on Supabase Realtime, I decided to build a custom realtime system using Server-Sent Events (SSE) and Redis Pub/Sub. This introduced concepts that I had not worked with before, including persistent connections, event-driven architecture, message publishing, connection management, and separating the realtime server from the main Next.js application.
This was intentionally a learning decision. I wanted to understand what was happening underneath a realtime feature instead of treating it as a black box.
3. User Invitations
The invitation system also introduced more complexity than I initially expected.
An invitation is not simply an email containing a link. I needed to think about invitation tokens, expiration, who is allowed to invite someone, what happens when an invitation is accepted, and how membership should be represented in the database.
Building this feature pushed me to think more carefully about authentication, authorization, database constraints, and application-level security.
4. Deployment and Infrastructure
As CineJourney became more than a local project, deployment became a problem I had to think about rather than something I could leave until the end.
I had to decide where each part of the application should run and which tools made sense for the project. Instead of deploying everything to a single platform, I separated the application into several services based on their responsibilities.
This includes deploying the Next.js application, PostgreSQL database, Redis infrastructure, realtime Node.js server, and email service independently. I also needed to think about how these services communicate with each other, how secrets and environment variables are managed, and how different environments should be configured.
I also set up separate development, testing, and production environments so that I could make changes without treating production as my testing ground.
This process taught me that deployment is not simply the final step after development. Where an application runs, how its services communicate, and how those services are deployed are architectural decisions that affect the application itself.
5. CI/CD
Once I had multiple environments and services, I also needed a reliable way to move changes between them.
I worked on branch-based deployments and automated build and deployment processes so that development, testing, and production could be treated as separate environments.
This gave me hands-on experience with environment variables, build processes, deployment pipelines, and managing an application that is made up of multiple independently deployed services.
What I Am Learning
CineJourney started as a simple idea: a place for two people to keep track of the movies they watch together.
It has gradually become much more than a CRUD application. Building it has forced me to think about architecture, security, infrastructure, realtime communication, deployment, testing, and the trade-offs involved in building a real application from the ground up.
More importantly, it has taught me that building software is not just about making individual features work. As a codebase grows, the decisions made around those features start to matter just as much as the features themselves. The code is not perfect for now, but I had learned a lot from it and grow with the project.
A little sneak peak of the application!