What started as a simple idea — a private, secure way for family to share photos and videos without handing everything to Big Tech — has grown into a full software project with its own hosting, Windows installer, face recognition pipeline, and a growing feature set. Here's an honest account of how it happened, the wrong turns, the wins, and where it's headed.
The Idea: Keep It in the Family
Like a lot of people, I'd grown uncomfortable with the idea that family photos — candid moments, kids growing up, holidays, the dogs doing daft things — were effectively being handed over to platforms like Facebook or Google Photos in exchange for "free" storage. The business model of those platforms is data. Our family moments aren't data to me, they're memories.
The original concept was straightforward: a private, invitation-only system where family members could register, upload photos and videos, browse galleries, and share moments without a third party sitting in the middle. No advertising. No algorithmic feeds. Just a family space online, controlled by us.
Phase One: The WordPress Plugin
The first attempt was built as a WordPress plugin — a logical starting point given WordPress's ubiquity and my existing familiarity with PHP. The plugin, which I called Family Media Manager (FMM), grew quite capable over time. It handled invitation-based registration, video streaming via Google Drive integration (to keep storage costs manageable), gallery collections, category-based access controls, and even a media approval workflow so content could be reviewed before going live.
Google Drive integration was a clever compromise at the time. Instead of paying for large amounts of web hosting storage, full-resolution files lived in Google Drive while the WordPress site served thumbnails and streamed video on demand. In theory, it meant family members got free Google storage while I kept hosting costs low.
What went well: The core concept worked. Invitations, approvals, streaming, galleries — it all functioned. The database schema grew mature, and the code reached a point of real usability.
But WordPress came with its own headaches. Theme conflicts, plugin compatibility issues, SELinux permissions on the home server, WordPress's opinionated way of handling URL rewrites and file paths — every feature addition meant wrestling with the WordPress ecosystem as much as building actual functionality. Getting a simple gallery viewer working reliably across WordPress themes took far longer than it should have.
The Pivot: Going Standalone
The moment of clarity came during one particularly frustrating session debugging why a gallery viewer broke every time the WordPress theme was updated. The question asked almost as a joke was: what if we just stripped WordPress out entirely and ran the same PHP on a plain Apache host?
The answer, when we actually looked at it, was: it would be easier, not harder. All the PHP logic, CSS, JavaScript, and database structure we'd built was ours — none of it fundamentally needed WordPress. The WordPress layer was adding complexity and friction, not value.
So the decision was made to start a new standalone project. The codebase was ported to a clean Apache/PHP/MySQL stack without any WordPress dependency. Direct file paths, simple session-based authentication, full control over routing and templates. The application moved to Ecenica shared hosting at familymediamanager.co.uk, and suddenly things that had been battles became straightforward.
Building the Feature Set
With the WordPress shackles off, development accelerated. Over the following months the platform grew steadily:
Galleries and media management were refined — proper lightbox navigation with keyboard support, upload limits raised beyond PHP's default 20-file cap (which had been silently dropping files on Ecenica's LiteSpeed server, a particularly frustrating discovery), and video thumbnail generation added using client-side canvas capture for environments where server-side FFmpeg wasn't available.
A rich posts system was added alongside galleries, allowing family members to write announcements, share documents, and create narrative posts with embedded images — better suited to family history content than a plain photo gallery.
Admin tools grew too: pinned homepage posts, social media link management, a branding customisation page, and an approval workflow for both galleries and posts.
One idea that emerged during development was extending FMM beyond just family use — a photographer mode where clients could log in to a private gallery, view their session photos, and mark the ones they wanted. The branding customisation work already laid groundwork for this, allowing custom headers and themes. That remains an interesting direction.
A Different Way of Building: Claude as Coding Partner
I should be honest about how this project has actually been built, because it's not the conventional story of a developer sitting down and writing code from scratch. From relatively early on, I've been working in collaboration with Claude — Anthropic's AI assistant — and the dynamic has been more interesting and more educational than I expected.
The workflow is straightforward enough: we discuss a feature or problem, Claude produces the code, and I deploy and test it. But what surprised me was the learning that happened almost as a side effect. Pasting commands into a terminal and watching what they do — then asking why that worked, or why it didn't — turned out to be a remarkably effective way to understand what was actually going on under the hood. PHP configuration, Apache directives, MySQL queries, Python libraries — I absorbed more practical knowledge this way than from any amount of reading documentation in the abstract.
It's not a replacement for deep expertise, and I wouldn't pretend otherwise. But for a retired engineer who wants to build something real without spending years becoming a full-stack developer first, it's been genuinely powerful. The ideas, the decisions about architecture, the judgement calls about what matters — those stay human. Claude handles the syntax and the boilerplate. Between us, things get built.
What it's also meant is that this project has proper documentation, session notes, thought-through rationale for decisions — the kind of discipline that solo hobby projects often lack because there's no one to explain yourself to. Having a collaborator, even an AI one, creates that accountability naturally.
Windows: Making It Accessible
One challenge I hadn't fully anticipated was making FMM accessible to family members who aren't comfortable with web hosting or Linux. The solution was a Windows installer package — a bootstrap script that downloads and configures XAMPP (Apache, MySQL, PHP) and FMM together, so a non-technical family member could theoretically set it up on a Windows machine for local use.
Testing this involved running Windows 11 in a VirtualBox VM on my Fedora workstation, sharing files via Samba, and iterating through a surprising number of edge cases — PHP config mangling by batch scripts, MySQL InnoDB crashes, privilege escalation, the works. And this is where I want to be clear about something that doesn't show up in any changelog: the sheer volume of testing involved. Code that looks correct on paper has a habit of failing in the real world in ways nobody anticipated. Getting the Windows installer to actually work — reliably, on a clean machine, for someone who isn't a developer — meant running it over and over again, spotting the failure, feeding it back, adjusting, and running it again. Hours of this. The kind of methodical, patient, unglamorous work that makes the difference between software that sort of works and software that actually works. That testing burden has fallen almost entirely on me across the whole project, and it's been substantial. Every gallery fix, every upload limit change, every lightbox navigation tweak — tested against real browsers, real files, real hosting environments. Claude can write code, but it can't plug a USB drive in, watch a video fail to thumbnail, or notice that sound playback is slightly off. That part is irreducibly human, and it's taken a lot of evenings. And if I'm being fully honest about the development environment — it's also taken a fair number of afternoons that were simultaneously dedicated to entertaining the grandkids. There's a particular kind of focus required to track down a PHP configuration bug while also referee-ing a disagreement over whose turn it is on the iPad. Somehow the project survived both.
The Photo Archive: A Parallel Project
Running alongside FMM development has been a separate but related project: organising my personal NEF (Nikon RAW) archive. Over years of shooting with a D500 and D850, I'd accumulated more than 16,000 NEF files — around 535GB — scattered across card dumps, Google Drive syncs, and multiple folders with inconsistent naming.
The NEF Archive Manager project tackled this in phases: ExifTool-based indexing, MD5 deduplication, a clean date-based folder structure, and then — most ambitiously — a face recognition pipeline using Python and the face_recognition library. Family members were enrolled using a visual GUI tool, XMP sidecar files were written alongside the NEFs to preserve metadata without touching the originals, and the results were integrated with digiKam for browsing.
Over 3,600 NEFs were tagged in the first full scan — recognising 13 enrolled family members and both dogs. The longer-term plan is for this pipeline to feed directly into FMM, so the family website automatically knows who's in a photo.
Challenges That Haven't Gone Away
Honest reflection on the harder bits:
Shared hosting constraints remain real. Ecenica runs LiteSpeed, not Apache, which meant PHP configuration directives in .htaccess were silently ignored for a long time. Server-side video processing (FFmpeg) isn't available. These constraints push creativity but also add complexity.
The non-technical user problem is genuinely hard. Making a self-hosted family platform approachable for relatives who aren't developers is a different challenge to building the platform itself. The Windows installer work is a step in this direction, but there's more to do — setup guides, video walkthroughs, and forgiving error handling all matter.
Memory and context across development sessions is something I've managed by maintaining detailed session notes — uploading them at the start of each new session so work can continue without losing thread. It's a workflow quirk of building something complex over many sessions.
Where It's Going
The roadmap has a few clear directions. Face recognition integration with FMM — so photos are automatically tagged and searchable by person when uploaded — is the most exciting near-term goal. The pipeline exists; it's a matter of connecting the two systems.
The photographer client gallery concept is worth pursuing properly — a clean, brandable gallery experience where a photographer's clients log in with a private link, browse their session, and select favourites. FMM's existing gallery and approval infrastructure is closer to supporting this than it might appear.
There's also the ongoing question of making the whole thing more shareable — whether as an open-source project, a packaged product, or documentation good enough that other technically-minded people could run it for their own families.
The core principle hasn't changed: family memories should stay in the family. Everything else is implementation detail.
Family Media Manager is self-hosted at familymediamanager.co.uk. It's a personal project built in PHP, running on Apache/MySQL, with a Python face recognition pipeline on the side. Built by a photographer and retired NCR engineer who'd rather host his own than hand it over.
Posted by Bob — photographer, developer, and firm believer that your family photos are nobody else's business.