← All projects

P—01 · Case study

ShakeUp

An end-to-end platform for running nightlife events: guests book their table in the app, staff scan tickets and take orders on the floor, and the organizer runs everything from a back office. Live on the App Store and Google Play, and on its way to becoming a SaaS.

RoleFounder · Product Owner & full-stack dev
Team5 students · IMT Nord Europe
Timeline2025 – present
StatusLive · iOS, Android, web
01 — Context

A night out is an information system.

The project started under the codename The Forest as IMT Nord Europe’s second-year engineering project: a real client, a spec, a budget, and regular reviews with two faculty advisors.

The problem: an event organizer has to juggle table bookings, door entry, orders and payments all at once. The goal was to bring all of it into a single tool that works for guests at home and for staff in the middle of a packed night.

ShakeUp app screen listing past events
Past events
Table booking screen with entry QR code
Table booking + entry QR code
02 — Users

Six roles, one app.

The hard part of the product is that everyone sees a different app. On sign-in, the app reads the user’s role and routes them to the right interface.

RoleWhat they do
GuestBrowses events, books a table, shows their QR code, checks the menu.
StaffScans guests in, tracks tables live, takes orders at the table.
Bar prepSees orders come in in real time, marks them ready, then served.
CashierRings up walk-in sales during the event.
AccountingApproves payments from the back office.
AdminCreates events, the menu, the floor plan and staff accounts, and reviews results.
03 — The flow

From launch to last bottle.

  1. Launch. The admin creates the event and its floor plan in the back office. Users get a push notification.
  2. Booking. The guest picks a table on the floor plan, enters the party size and pays the deposit through the partner ticketing platform.
  3. Ticket. A confirmed booking generates a QR code in the app, which can also be added to Apple Wallet.
  4. Entry. Staff scan the QR code at the door: the table is marked “arrived” and the assigned server is notified.
  5. Order. At the table, staff scan the table’s QR code and enter the order. It shows up for accounting and for the bar.
  6. Payment. Accounting approves the payment; the deposit already paid is deducted automatically.
  7. Service and wrap-up. The bar marks the order “ready”, then “sent”. After the event, the admin reviews aggregated results.
04 — Architecture

Three clients, one backend.

The mobile app and the back office share the same Firebase project. Every sensitive write (bookings, orders, payments, roles) goes through server-side Cloud Functions, never straight from a client.

MobileReact Native app

Expo · iOS & Android · OTA updates

BackendFirebase

Auth · Firestore · Storage · 50 Cloud Functions (Node 22)

WebNext.js back office

Role-based dashboard · deployed on Vercel

Around that core: iOS push notifications via APNs, event images on Cloudinary, builds and updates with EAS, signed Apple Wallet passes, and a webhook for the partner ticketing platform.

05 — Technical highlights

What taught me the most.

  • AI-powered floor plan import. Placing dozens of tables on a floor plan by hand takes forever. The back office provides a prompt that you give to a multimodal LLM (ChatGPT, Gemini or Claude) along with a photo of the floor plan; the model returns structured JSON (categories, tables, positions). The back office validates it, corrects the coordinates for how the image is cropped, then merges it in without ever overwriting a table that’s already booked.
  • Interactive floor plan. In the back office, you drop tables onto the venue’s floor plan, move them and resize them. Positions are stored as percentages, so the app renders the same plan on any screen, with zoom.
  • Ticketing API. I wrote the spec for the integration with the ticketing platform (6 endpoints). Every call is signed with HMAC-SHA256 so nobody can validate a deposit from the outside.
  • Apple Wallet without a native module. The pass is generated and signed by a Cloud Function, then opened in Safari. As a result, the feature could ship as an OTA update, with no new App Store release.
  • Roles and security. The role lives in the auth token and is re-checked server-side in every function. Staff accounts can be disposable and scoped to a single event.
06 — The code

Verifying a webhook.

When the ticketing platform confirms a deposit, it calls this endpoint. We recompute the message signature with the shared key and compare it in constant time before touching the database.

functions/index.js — ticketingWebhookNode.js
exports.ticketingWebhook = onRequest(async (req, res) => {
  // … method, config and body size are checked first
  const header   = String(req.get("X-ShakeUp-Signature") || "");
  const expected = "sha256=" + crypto
    .createHmac("sha256", secret).update(rawBody).digest("hex");

  const a = Buffer.from(header), b = Buffer.from(expected);
  if (a.length !== b.length || !crypto.timingSafeEqual(a, b)) {
    return res.status(401).json({ error: "invalid-signature" });
  }

  // The booking must exist and match the event and table in the payload
  const resa = (await db.doc(`tablesReservation/${reservationId}`).get()).data();
  if (body.eventId !== resa.eventId) return res.status(422).json({ error: "reservation-mismatch" });

  await applyDepositValidation({ reservationId, source: "api" });
  res.status(200).json({ ok: true });
});
07 — My role

A project lead who codes.

  • Scoping and design: gathered requirements with the client, designed flows and screens in Figma, and got them signed off before development.
  • Architecture: chose the stack, designed the data model, split the logic into Cloud Functions, wrote the security rules.
  • Development: built a large share of the app, the back office and the backend.
  • Team lead: ran sprints across the team of five, kept the project within a €300 budget, reported to the faculty advisors.
  • Shipping: published to the App Store and Google Play, deployed the back office.
08 — By the numbers

What shipped.

100+users
2 storesApp live on iOS and Android
50server-side Cloud Functions
~38klines of TypeScript (app + back office)
6user roles
€300total project budget
09 — What’s next

From app to SaaS.

ShakeUp was built for a single organizer. The next step is to turn it into a SaaS that any nightlife event organizer in France can use, with their own events, team and menu.

In progress

I’m driving this as founder, drawing on both sides of what I’ve learned: architecture and product from building ShakeUp, prospecting and negotiation from my time at CLEEVEN.

10 — Takeaways

Lessons learned.

  • A multi-role product is designed around flows, not screens: who does what, and at what point in the night.
  • Putting business logic on the server from day one means you never have to trust the client’s phone.
  • An approved mockup costs far less than a feature you have to rebuild.
  • Leading a team is mostly about making it visible who’s doing what, and by when.