"How does private album access work in Albumo?"

All albums are private by default. The owner grants access to specific people from their contacts, or to an entire group at once. Once access is revoked, viewing stops immediately — that's built into the architecture, not a separate setting.

"Why not just cache photos by their link?"

Photo links are refreshed periodically for security reasons, even though the file itself doesn't change. We cache photos by a unique fingerprint of their content, not by a link that can change.

"Why is photo deduplication necessary?"

So the server doesn't end up storing several copies of the same image if different users upload it, or one user uploads it twice. The copy just references the original that's already saved, which cuts storage costs.

"How is Albumo different from iCloud or Google Photos?"

Albumo isn't a replacement for your phone's cloud storage. Its job is to give you a private way to share photos with specific people without forwarding files through messengers. The value here is in controlling who sees what, not in gigabytes.

"How will Albumo make money?"

The core model is selling additional storage and subscriptions, including family plans. Down the road — printing physical photo albums.

"What's the tech stack?"

Mobile — React Native (New Architecture), TypeScript, TanStack Query; backend — PHP 8.4, Laravel 12, PostgreSQL, Redis; media — S3-compatible storage with a CDN and perceptual hashing for deduplication and caching.

Private Photo Storage & Sharing App Development

Task

The client and their partners came to us with an idea: an app where you can store photos and open access to them for specific people.

We always start projects like this with a Discovery phase: breaking the idea down into prototypes, user stories, and architecture before moving into development. At the outset, the client had only a description of the idea, with no technical groundwork — which made Discovery especially valuable here. That's where the principles that shaped the entire product took form:

Simplicity
a minimum of screens and actions, large and clear elements.
A clear line between "mine" and "shared"
your own photos and the ones shared with you never mix.
Deliberate interaction over noise
no automatic Stories, no pop-up notifications; the user decides what to show.
Photos come first
Photos come first, the interface stays out of the way.

The audience for the product is families, including children and older users, which made simplicity a hard requirement.

The Product: What We Built

What shipped is a small set of features, each doing one obvious thing — photos live in one place, albums are curated views of them, and access is granted person by person.

Personal and shared photos never mix

Every photo a user uploads lands in one system album — a personal camera roll. Albums that a user creates are curated selections from that same camera roll: the same photo can live in several albums at once without the file being duplicated. An album can be renamed or deleted without touching the original photos.

Access closes instantly

All albums are private by default. To share an album, the owner simply picks someone from their contacts or invites them by phone number — sharing with an entire group is just as easy. And if access is revoked, viewing stops right away, with no delay. That's built into the product's architecture — more on that in the technical part of this case.

"Highlight": temporary posts inside an album

Alongside permanent albums, Albumo has a feature called "Highlight" — a way to temporarily draw attention to specific photos inside an album. Only people who already have access to the album can see a Highlight, and its lifespan (say, one or two days) is configured on the product side.

Reactions, favorites, and the activity feed

You can leave a like or one of six reaction types on a photo — available to anyone with access to it. Favorites is a personal collection that only the owner can see. And the activity feed on the home screen shows, in one place, who opened access, who added new photos, and who joined the app.

Search

Search works across albums, photos, and favorites at once — you can search by album name, date, or location.

Monetization Model and Market

The client plans to monetize through selling additional storage and subscriptions, including family plans, and is also considering printing physical photo albums down the road.

Positioning matters here: the price of storage itself is already low and effectively a lost battle against the big players — a 2TB family plan on iCloud+, for example, costs around $9.99 a month, shared across six people. Competing on price per gigabyte against players like that doesn't make sense. Albumo's value is in privately sharing photos with specific people without forwarding files through messengers, and that's exactly the positioning the client has put on their landing page — we think it's the right call.

According to 2026 survey data, a third of social media users aren't confident their data is protected at all — a growing demand for privacy plays directly into the hands of a product built around it from day one.

How It's Built

Albumo's idea is simple, and that's a deliberate choice on the client's part — but a simple idea doesn't mean simple engineering. It's precisely where a product feels effortless (open a photo, tap a like) that the most demanding engineering usually hides: privacy, speed, and reliability only feel invisible to the user when everything underneath has been thought through. Here's how, exactly.

Photo links keep changing, the photo doesn't

The most technically interesting problem: for security reasons, links to photos are issued for a limited time and keep getting refreshed, even though the file's content never changes. Ordinary caching "by file address" doesn't work here — tomorrow the same photo will have a different address. We solved this by caching photos by a fingerprint of the image itself — a perceptual hash, or pHash: instead of the file's address, the app remembers a unique "fingerprint" of the photo and stores it locally under that fingerprint. If a photo is already saved on the device, it opens instantly with no server round-trip. We use the same fingerprint on the backend too — for deduplication, covered below.

Privacy is built into the API, not bolted on top

Instant access revocation works thanks to how requests to the server are architected: the app first receives only a lightweight list of what exists in the gallery, and requests the address of a specific photo separately, at the moment it's shown — with permissions checked at that exact second. So as soon as access is closed, the next request for that photo simply fails the check; an old link doesn't help anyone get around it.

One photo, one file on the server

If different users upload the same photo (or one user uploads it again), the server still keeps only a single original — every other copy just references it by the same image fingerprint. That cuts storage costs without the user having to do anything.

A custom-built transition to full-screen photos

Opening a photo from the grid is expected to animate smoothly into full-screen view — the familiar "Hero" animation. React Native's built-in tool for this turned out to be incompatible with long photo lists: the animation simply broke on real data. We built our own mechanism from scratch and, along the way, solved several related problems: the photo morphs smoothly from its grid card to full-screen without a visual jump, the original card in the list is properly hidden during the animation, and when returning from full-screen — including after swiping to a different photo — the app re-locates the right card in the list and lands the animation exactly on it. The swipe-to-dismiss gesture runs on the same logic, so it behaves predictably at any point in the transition.

Thousands of photos in the gallery, no lag, no flicker

The photo list is built so it never waits to load the entire archive at once: a lightweight metadata list loads first, and the photos themselves come in small batches of 30 as the user scrolls. The system also makes sure the same batch isn't requested twice if someone scrolls quickly back and forth, and background refreshes happen without the telltale flicker of a list disappearing and reappearing.

Uploads to the cloud survive a dropped connection

Every photo uploads to cloud storage in parts and is tracked individually: if the connection drops or the app gets backgrounded, the upload automatically pauses and resumes on its own once the connection is back — no need to start over. Once an upload finishes, the app refreshes the cache for the whole batch of photos in one action rather than one at a time, which protects performance during bulk uploads.

Changes reach every screen that needs them, on their own

The same data shows up on different screens that aren't directly wired to each other: deleting a photo, for instance, needs to be reflected right away in "All Photos," in every album that contained it, and in the counters. Hard-wiring screens together to make that happen is a bad idea — the more features an app has, the more those direct dependencies slow everything down and add complexity. We built a domain events system inside the app: when something changes (a photo gets deleted, say), an event goes out, and every screen that cares about it decides for itself whether to update. Screens stay independent of each other, and the data stays accurate everywhere.

Private storage and a CDN don't usually get along — we made them work together

To serve photos quickly worldwide, we used a CDN, but by default a CDN doesn't work with private file storage. We found a workaround that preserved both fast delivery and network-level access control.

Tech Stack

We deliberately picked the newest versions of our tools only where they delivered a real gain in speed or developer experience — not "the latest version just because."

Mobile:

React Native 0.82 on the New Architecture (Fabric + TurboModules) with Nitro Modules and the React Compiler — the most current layer of React Native, with no legacy bridge between JS and native code; React 19, TypeScript.
State and data — Zustand with MMKV for instant local storage, TanStack Query v5 for server state, Orval for auto-generating the API client from an OpenAPI schema (so the client and backend never drift out of contract).
UI and animation — React Navigation v7, Reanimated 4 with Worklets, custom gestures on react-native-gesture-handler, FlashList and @legendapp/list for fast long lists, turbo-image for native image caching.
Push and growth — Firebase Messaging with Notifee, Universal Links and Play Install Referrer (to correctly attribute where a new user came from — also groundwork for a future referral program),
AppMetrica,
i18next for multi-language support.

Backend:

PHP 8.4, Laravel 12 on Octane with OpenSwoole — the app stays resident in memory between requests instead of rebooting the framework on every call, which gives noticeably lower latency under load.
PostgreSQL, Redis, Docker. A strict layered architecture (Controller → Service → Repository), typed DTOs via Spatie Laravel Data for the contract with the mobile app, and role-based access via Spatie Laravel Permission.

Media and search:

S3-compatible storage with a CDN, imgproxy for generating previews from signed URLs, perceptual hashing (pHash) for deduplication and mobile-side caching, full-text search on Meilisearch.

Authentication:

Laravel Sanctum, one-time codes over SMS with cascading delivery (SMS, then a phone call if it fails), phone number validation via libphonenumber, IP-based geolocation via MaxMind GeoIP2.

Quality:

static code analysis (Pint, PHPStan), the backend API is covered by e2e tests, and key components — such as the perceptual hash generator — have additional unit test coverage.

We've applied a similar approach to handling large volumes of media and in-app purchases in SmilesOn (a React/Next.js web platform for storing, selecting, and purchasing photos) and Yoga Stacks (a React Native mobile app with image optimization and subscriptions).

Team

Jennifer M.

Project Manager

Vlad M.

Backend Developer

Ilya Z.

Backend Developer

Eugene S.

Mobile Developer

Nastya P.

Lead UX/UI Designer

Ekaterina S.

QA

Timeline

The project started with a Discovery phase, out of which grew a detailed specification with epics and user stories. From there, the full cycle followed: design, backend, mobile development, testing. The MVP is already shipped to production and available in the stores.

Results

The MVP is fully built and shipped to production — the app is available on the App Store and Google Play.

📱

A full feature set is live: phone-based authentication, a personal gallery, private albums with no file duplication, flexible access control with instant revocation, invites by contact and by group, temporary "Highlight" posts with a configurable lifespan, likes and six reaction types, personal favorites, an activity feed, and search across albums, photos, and favorites.

⏩

Built a custom system for smooth transitions between the photo grid and full-screen view — no off-the-shelf solution fit the job.

🌆

Solved photo caching against unstable links — the app displays already-saved photos instantly, without extra server round-trips.

🌃

Built server-side photo deduplication — saving storage space when the same file gets uploaded more than once.

📦

Combined private file storage with a CDN, even though the two don't work together out of the box.

Albumo: Building a Mobile App for Private Photo Storage and Sharing with Family