The Problem
The photography industry has always had a discovery problem. A talented freelance photographer or a well-equipped studio would spend more time chasing clients than doing actual work. The platforms that existed were either directories that charged for visibility (ranking profiles higher for more money) or tools that handled event management but offered no way to market yourself. Nobody had combined both into one place. And almost none of them worked well on mobile, despite the fact that most photographers live on their phones.
Picxilens was built to fix that. The idea was simple: one platform where studios and freelance photographers could showcase their work, manage their business, and get discovered by customers, all without paying for visibility or switching between five different tools.
What Was Built
The platform was designed around three distinct user types, each with a completely different experience.
Studios got a full suite of business tools (a profile page visible to the public, a gallery to display their work, a calendar for managing shoots and events, an inventory system to track equipment, and the ability to post job openings for freelancers. Freelancers got a lighter version) a portfolio, a gallery, and a job search to find both permanent positions and temporary gigs. Customers browsing the platform could explore studios across the country, go through galleries, read about what each studio offered, and contact them directly.
The public-facing side of the platform was built as a server-side rendered application using Nuxt 2. This was a deliberate decision, photographers and studios needed to be discoverable on Google, so server rendering was chosen to make public content readily available to crawlers. Every profile, every gallery, every listing needed to be indexable from day one.
Firebase was chosen as the backend. For a two-person team building a full-featured product in under four months, managing server infrastructure would have consumed time better spent on product decisions. Firebase gave a complete backend (authentication, a real-time NoSQL database, file storage, and serverless Cloud Functions) all in one ecosystem. The trade-off of vendor lock-in was an acceptable one given the scope and timeline.
The Authentication Architecture
One of the more interesting technical challenges was building a role-based system that felt secure and seamless at the same time. When a user signs up, they choose whether they are a Studio or a Freelancer. That role gets embedded into a custom JWT token issued by Firebase. On every page navigation, a Nuxt middleware reads that token and either allows access or redirects the user to the appropriate page.
This meant authorization wasn't just a client-side check (it happened at the server level on every request. A freelancer trying to access the studio inventory page would be redirected before the page ever loaded. The token also contained all the session data needed to personalize the experience) no extra API call required on mount.
VuexFire was used to bind Firestore collections directly to Vuex state, giving real-time updates across the UI without manual subscription management. When a studio updated their calendar or posted a new job, it reflected instantly across the platform.
The Product Decisions
FullCalendar was integrated for studio event management because a real calendar (with day, week, month, and list views) was essential for how studios actually work. A simple date picker or table would not have served the use case.
Razorpay was integrated early as groundwork for future premium features. It wasn't needed in V1, but building the payment infrastructure in while the codebase was still young was the right call.
The platform was built as a Progressive Web App, installable directly from the browser on both desktop and mobile. Photographers often work on site at events with their phones. Having a native app experience without needing an app store was both a product advantage and a practical one for a team that couldn't build and maintain separate native apps.
The Outcome
Picxilens was deployed as a complete application with three user roles, authentication, real-time data, payment integration, and an installable PWA experience. It was built by two developers in under four months as a final year major project, and it was the first time either of them had shipped a multi-role, authenticated, cloud-deployed product.
Looking back, there are clear things that would be done differently. Nuxt 3 with the Composition API and TypeScript would have made the codebase significantly more maintainable as it grew. Firestore worked, but the relational nature of users, studios, jobs, and applications was a constant friction point. PostgreSQL would have been a better fit. And there were no tests, which led to a few auth edge cases causing last-minute debugging sessions before submission.
But for what it was (a production-grade platform built from scratch under real constraints) Picxilens proved that shipping complete, working software was possible well before entering the industry professionally.
Stack
- Nuxt 2 (SSR)
- Firebase (Firestore, Auth, Storage, Cloud Functions)
- Node.js
- Vuex
- VuexFire
- Buefy
- Axios
- PWA
- JWT
- FullCalendar
- Razorpay
- Google App Engine