Wookie

Note: Some names and company-specific details have been generalized to protect confidentiality. The technical lessons remain authentic. Individuals named in this article have consented to being mentioned.

Why were hundreds of employees booking seats on Google Calendar? 🤔

It sounds ridiculous, but that was our reality.

After the pandemic, the company doubled in size. We had shiny new offices, but the “booking system” was a shared Google Calendar. Chaos.

• No visual floor plans: You booked “Seat A-23” but had no idea where that was.
• Double bookings: You’d show up, and someone else would be in your seat.
• Admin nightmare: HR mandated Return-to-Office (RTO) but had zero way to track it beyond manual RFID logs.

I showed up to my booked seat three times in one week only to find someone already there. That’s when I knew: this isn’t just annoying—it’s a real problem.

We needed a cinema booking app, but for office chairs.

The roadblock: “We have no backend developers”

I pitched the idea. Leadership loved it. But there was a catch: I had no team.

All our senior backend developers were billed out to clients. What I did have was the Mobile Team—my own team of talented juniors, interns, and trainees.

They knew Swift and Kotlin. They did not know SQL.

So I had a choice, wait for “perfect” resources, or build with what we had?

Here’s how the architecture worked:

flowchart LR
    subgraph Clients["Clients"]
        Admin["Admin Users"]
        Primary["Primary Users"]
    end

    subgraph Apps["Applications"]
        Web["Web App"]
        Mobile["Mobile App"]
    end

    subgraph Platform["Cloud Platform"]
        Supabase["Supabase"]
        DB[(Database)]
        Internal["Internal Systems"]
    end

    subgraph External["External Services"]
        OneSignal["OneSignal"]
        Analytics["Analytics"]
    end

    Admin --> Web
    Primary --> Mobile
    Web --> Supabase
    Mobile --> Supabase
    Supabase --> DB
    Supabase <--> Internal
    Mobile <--> External

How do you prevent double-bookings in real-time?

The hardest technical problem wasn’t the UI—it was concurrency.

Imagine 200 employees trying to book seats for Wednesday at 9:00 AM. Two people tap “Seat A-23” at the exact same millisecond. Who gets it?

If we built this wrong, we’d just digitize the chaos.

We solved this using Optimistic Locking and Supabase Realtime:

1. When you tap a seat, we “reserve” it instantly in a temporary table
2. We subscribe to database changes via Supabase Realtime
3. If someone goes to the screen 10ms after you, the UI already shows it blocked (thanks to Real Time Updates and Row Level Security policies)

It works exactly like a cinema app. Simple for the user, bulletproof in the database.

Here’s what happens when two people try to book the same seat:

sequenceDiagram
    participant UA as User A
    participant UB as User B
    participant Temp as Temp Booking
    participant Final as Reserved Seats
    participant RT as Realtime

    UA->>UA: Taps Seat #5 (GREEN)
    UA->>Temp: INSERT seat #5
    Temp->>RT: Broadcast
    RT->>UB: Seat #5 taken
    UB->>UB: Shows RED ✗

    Note over UB: User B blocked (10ms later)

    Note over UA: Within 5 mins
    UA->>Final: Confirm
    UA->>Temp: DELETE

    Note over Temp: Alt:<br/>5 min timeout<br/>Auto-cleanup

How did we train them?

Teaching juniors to write production SQL wasn’t easy. I asked questions instead of giving answers. When a query ran slow, I’d ask “What does EXPLAIN ANALYZE say?” instead of just telling them to add an index. We set hard rules through Architecture Decision Records (ADRs): no GOD tables, and Row Level Security (RLS) policies were mandatory—“If I can delete the CEO’s seat booking with a CURL command, you fail.”

Juniors shipped production code with proper security in 3 months.

Read how we did it →

How we handled rotating resources

Because this was an outsourcing company, our QAs and Designers were constantly moving between high-priority client projects. We rarely had the same team for more than a few months.

In most companies, this would kill a project. Knowledge would walk out the door every time someone left.

But our development standards were so strong that it didn’t matter.

We treated documentation as a first-class citizen:

• Figma as Truth: Living design system with tokens and annotations. New designers dropped in and knew exactly what a “primary button” looked like without asking.
• Living Test Cases: QA documented the process of testing. When one QA left, the next picked up the script and continued where they left off.

The process protects the product.

Did it actually work?

We launched mid-2023. The adoption wasn’t just “good”—it was total.

Who built this thing?

This wasn’t a solo act. It was a village.

The Mobile Team (already under my leadership as Head of Mobile):

• Core Developers: Christian Andrew Manuel, Bryan Esguerra, Geremy Ubaldo (later led the Flutter rebuild after completing the bootcamp I built), Christopher Olanolan, Aldrin Mayor, Jeofferson dela Peña, Steven Frio, Lhorice Nadora
• Senior Mentors: Yra Galvez-Alcantara and Bryan Esguerra handled code reviews and guided juniors through SQL

The Web Team (brought in for the admin dashboard):

• Gavin Salcedo and Jan Basoc built the admin dashboard for HR and ITSM. While the mobile team focused on user-facing features, these two built the backend operations panel that let HR track RTO compliance and manage floor plans.

The Cross-Functional Squad (I recruited for this project):

• Design & QA: Andie Santos, Maria Eunice Joy, Roi Placente, Monina Salamanca, Eugene Roca, Jervince Cada, Marjorie del Mundo, Karl Francisco. The “Plug & Play” squad, they rotated in and out of high-priority client projects, but our living documentation (Figma design system, test case scripts) meant new members could drop in and contribute immediately.
• PM/SMs: Carl Arcenas, Maritess Ventic, Maricris Bondoc came in after I got buy-in to formalize sprint planning, requirements gathering, and stakeholder coordination. They kept the team on track with deadlines and managed the feedback loops with HR and leadership.

The Guides:

• John Lee Mangahas, Mark Angeles, & Ernest John del Rosario (my native mobile capability leads), and Paolo Alcabao (my mentor): Part-time mentors who reviewed architecture decisions and helped me refine the teaching approach for the juniors.

Then we threw away the code

By 2024, the code underneath was becoming a liability. We’d built it in Kotlin Multiplatform (KMP) for upskilling, but maintaining two UI codebases (SwiftUI + Jetpack Compose) drained resources. When Xcode auto-updated and broke the build, I made the call: rebuild it in Flutter. KMP matched our team in 2023. Flutter matched our constraints in 2024. Tech stacks aren’t about “right vs. wrong”—they’re about what fits your reality right now.

Read the full rebuild story →

From “Seat Booking” to “Company OS”

Once you have 100% of employees opening an app every day, you’re not just solving a booking problem—you have attention. And attention is the most valuable real estate in any company.

In Q1/Q2 2024, I noticed Marketing struggling to get people to read email newsletters. Emails get buried. Slack messages scroll past. But everyone opened Wookie every single day to book seats.

I asked them, “Why don’t we just push announcements to Wookie?”

We integrated OneSignal for push notifications. I ran a cost-benefit analysis, OneSignal’s basic tier for our company size cost less than building custom. No custom behavior needed. We kept it. Done in less than a sprint.

Suddenly Wookie wasn’t just for seats. It became the place you went for company information:

• Who’s in the office today? Real-time presence
• What events are happening? Company calendar feed
• Office announcements? Push notifications everyone actually sees
• Free pizza in the pantry? You bet we pushed that

Marketing started using it for company-wide announcements. HR used it for office updates. Events team used it for… well… events. Wookie evolved from a utility to the company’s operating system.

We didn’t plan to build a communications platform. We built a booking app so good that it earned daily engagement. Then we listened to what other teams needed. The product evolved because we paid attention to how people actually used it.

Current State:

• 100% employee adoption for seat booking (sustained for 2+ years)
• HR, Marketing, and Events teams use it as one of their communication channels
• Used in client demos to showcase our product-building capabilities
• Feature requests from real users: Office Events (shipped), Business Continuity Protocol during emergencies (on backlog)

What made this work?

1. Constraints force creativity.

No backend devs meant we had to use Supabase. That decision saved us months of DevOps work.

2. Product over code.

The juniors didn’t just learn SQL. They learned to solve user problems. They sat with users to understand the pain points. That’s infinitely more valuable than syntax.

3. Ask questions, not give answers.

The hardest part wasn’t teaching them the answer. It was letting them struggle for 30 minutes to find it themselves.

4. Process protects the product.

Rotating resources would’ve killed most projects. Strong documentation standards kept us alive.

5. Build with what you have.

If I’d waited for the “perfect” team, this project never would have happened.

6. Get buy-in with demos, not slides.

I presented a working prototype. Real problems with real solutions get real support.

7. Tech stacks aren’t about “right vs. wrong.”

They’re about “what matches your constraints vs. what doesn’t.”

KMP worked in 2022 and 2023. Flutter worked in 2024.

“The best engineers aren’t loyal to tools, they’re loyal to reality.

---

I started this project because I showed up to my booked seat three times in one week and found someone already sitting there.

Two years later, that frustration became a company wide platform used by 100% of employees. Not just for seats—for everything. Office events. Company announcements. Who’s in the office today. It became an operating system.

Those juniors who didn’t know SQL two years ago? They’re not just “mobile devs” anymore. Some are multi-stack developers. Some became cloud engineers. Some are mentors to the next batch of trainees. They stopped treating the database as a “black box” they were afraid to touch.

If you’re staring at a team of juniors and thinking “they can’t build this”, remember: I had no backend developers. I had no perfect resources. I just had a frustrating problem and a team willing to learn.

Your constraints aren’t blockers. They’re your training ground.

---

---