A private meetup app, built end to end

A native iOS private-meetup app, a real-time backend and an admin platform with moderation built in

The Scenes app on an iPhone: a scene called Night Party marked Happening Now, with who is here, Add Comment and Add Photo actions, and a photo shared into the scene.
Client
Scenes

Most social apps ask you to broadcast. Scenes asked the opposite question: how do you tell a handful of people you are free tonight, without posting it to everyone you have ever met? Toobler built the product that answered it — a native iOS app, a real-time Node.js backend, and the rules that make a private invitation behave the way people expect.

Customer and context

Scenes, Inc. set out to make being sociable less work. You open the app, create a “scene” — a title, a time, a place — and make yourself available. Friends and connections nearby can see it and join, or not. Nobody sends a message; nobody posts to a whole friend list.

The privacy model is the product. A scene, and every photo and video shared inside it, is visible only to the people who were invited and accepted. That is what lets someone open one without deciding first whether it is worth telling everyone about.

Toobler was the engineering partner. The client brought the interface design; Toobler built what sits under it — the native iOS app, the backend and its APIs, and the admin platform behind both — over roughly eleven months, with an eleven-person team.

The challenge

A private, spontaneous meetup app is harder than it looks, because most of the difficulty is in the rules rather than the screens.

  • Availability is a state, not a post. A scene starts, runs and ends. Someone can be in one at a time. Those are product rules, and they only work if the backend enforces them rather than hoping the app does.
  • An invitation has to reach people who are not users yet. The point is to invite the friends you actually have, wherever they are — which means Scenes, Facebook, email and the phone’s own contacts, each with its own idea of what a valid identity looks like.
  • Conversation inside a scene has to feel live. A comment or a photo that appears a refresh later reads as a different, slower product.
  • Real phone networks, not lab conditions. People open this in a bar, on a carrier network, on a phone that has just changed IP. Real-time connections have to survive that.
  • An open social product attracts abuse. Anything that lets strangers invite strangers needs a way to see and stop it, from the first release.

The solution

A scene lifecycle, enforced server-side. Scenes end themselves when their time is up. Users are notified when one starts. Creating a new scene while you are already in another cancels the first, and you cannot join a second while you are in one. One person, one scene, at any moment — a small-sounding rule that shapes the whole data model.

Real-time inside the scene. Socket.IO carries comments and images so they land instantly for everyone in the scene. The team took this into the awkward conditions it actually runs in, working through real-time sockets over mobile carrier IPs rather than assuming a stable connection.

Invitations across four channels. Invite through Scenes itself, through Facebook, by email via Mailgun, or straight from the phone’s contacts — with validity checking per channel, and tracking that follows an invited person through to signing up.

Privacy enforced in the API, not the interface. Scene visibility, membership and media access are decided on the server, so a scene stays private regardless of what any client asks for.

Native iOS, built properly. The app is native — a slide menu, a searchable scene list with lazy-loaded imagery and pull-to-reload, distance-from-you calculated per scene, Google Maps, a downloadable location map, and push notifications through APNs. The list screen alone carries distance, timing, invitation state and network-failure handling.

Trust and safety from the start. The admin platform, built on Backbone.js, carries spam management with per-user spam counts, a view of inappropriate users and activity, and user deletion that also clears the user’s data and stops notifications reaching a deleted account.

Engineering discipline underneath. The team built a test framework with a pre-commit suite, including coverage for scene creation itself, and ran the backend on Node.js and MongoDB with automated deployment and monitoring agents across both servers.

Results

Scenes shipped to the App Store as a complete product: a native iOS app, a real-time backend, and an admin platform with the moderation tools a social product needs from day one.

What the project shows is not a feature list. It is that the hard parts of a consumer social product are usually invisible — a lifecycle rule that stops two scenes existing at once, an invitation that works for someone who has never heard of the app, a comment that appears before you wonder whether it worked. Toobler built those, and the client’s own designs came through intact.

This is a build of its time — Objective-C, App Store only, 2013 into 2014. The engineering question it answers is not: it is still what a founder is asking when they need a product built end to end, by a team that will take the rules as seriously as the screens.

The team at Toobler has been a pleasure to work with. They put out quality work with great turnaround time. The iOS developers have taken my UI and brought it to life.

Tate J Howe

Founder, Scenes

Let's talk about your project.

Start with one measurable use case.

A Readiness Sprint is a fixed-scope engagement that maps your integration and AI readiness and produces a production-oriented plan — before anything is built.