Mavicats · Own project
Mavicats: community, camera database and a game with one login
A community platform for retro digital photography enthusiasts, with a feed, a marketplace and a searchable database of 38 camera models. The community is small; the database gets found on its own and brings in affiliate clicks.
- Project type
- Own project
- My role
- Owner, development and infrastructure
- Status
- Website online
- Duration
- Ongoing since April 2026
- Team size
- 1
- The question
- A retro photography community needs a shared place for photos, camera information and trading.
- The result
- A community with a camera database, marketplace and shared login for its separate game.
The question
This started as an experiment: I wanted to get a grip on the infrastructure side of this work by building something that really runs, has users and can fall over. It became a community for retro digital photography enthusiasts, with a feed, a marketplace and a searchable camera database. The learning goal was met. The community is small, but the database gets found on its own and the search traffic leads on to affiliate clicks.
Building a general community is hopeless against existing platforms: there is nothing to win there that Instagram or eBay does not already do. So the real problem was strategic: why would anyone come here instead of going there?
There was also a learning goal: this project had to teach me the side of the trade you can't practise casually on client work. Deploying, monitoring, recovering from a mistake, keeping costs under control. That only works if it is real.
Key issues
- A general community has no reason to exist next to existing platforms
- You can't learn deploying, monitoring and recovering without a system that really runs
- A marketplace between members needs accounts, messages and moderation
- The upcoming game must not get in the platform's way
Constraints
- My own time and money; no budget for wrong bets on infrastructure
- The platform has to keep running while the game is built separately alongside it
Project background
My own work, not a client project. I wanted to really learn the infrastructure side of this trade (keeping things running, deploying, measuring, recovering), and you don't learn that from reading. For that you need something that really runs, has real users and can really fall over.
It became a community for retro digital photography enthusiasts, built around one camera family. Members share work in a feed and can trade vintage gear with each other, and there is a searchable database of cameras and accessories plus a knowledge base.
My approach and decisions
Start with the subject. A place for exactly one camera family, with a database that describes those cameras really well, does have a reason to exist. And that is exactly where the traffic turns out to come from.
Keep the game separate. The platform comes with a game that runs as its own application at its own address, with one shared login. That way the platform can keep growing without the game having to move with it, and the other way round.
Steer performance by measurement. The game started out on a custom 3D engine written in CSS. After the first playtest it ran at 11 to 21 frames per second in some places; after targeted optimisation, with a before and after figure recorded for every decision, it reached 56 to 59. Measurements then showed that 84% of the frame time was spent in the browser itself; since August 2026 the game has run on Three.js, with 88% of the code carried over unchanged.
Technical details
Technologies used
- Next.js
- React
- TypeScript
- Python
- FastAPI
- Three.js
- Cloudflare Workers
- PostgreSQL
- Sentry
What it delivered
The learning goal was met. The infrastructure side, from keeping things running and deploying to measuring and recovering, is exactly what this project delivered. One example: after a migration, five indexes were missing in production, which made search slow for months. Since then, every pull request gets its own database branch with a drift check. That knowledge now goes into every client project.
And it actually brings something in: search traffic that lands on the camera database leads on to affiliate clicks to two large marketplaces. Not a big amount, but it proves something I also tell clients: a database with strong content and a sound structure gets found on its own, without an advertising budget.
- Frames per second in the game
- Measured per decision
- 11 to 21 → 56 to 59
- Traffic to the camera database
- Leads on to affiliate clicks
- None → Ongoing, from search engines
- Automated tests
- Game rules are verified
- 0 → 373 on the platform, over 700 on the game
Delivered
- Search traffic to the camera database leads on to affiliate clicks
- Game from 11–21 to 56–59 frames per second
- 373 automated tests on the platform, over 700 on the game
- Platform and game developed separately, with one shared login
Outcomes
- Search traffic lands on the database and leads on to affiliate clicks, without an advertising budget
- Platform and game can grow separately, with one shared login
- The game runs in the browser, without a game engine
- What I learned about deploying and monitoring goes straight into client work
What I take forward
Lessons
- Focus on one subject and do it well; that is where the search traffic comes from
- A database with strong content gets found without an advertising budget
- Two separate applications with one login give more freedom than cramming everything into one system
- You improve performance by measuring every decision
The platform becomes the foundation for the upcoming game. And the knowledge this project produced (deploying, monitoring, keeping costs under control, recovering from a mistake) now goes into every client project.