Turning Missed Calls Into Reliable Revenue Infrastructure for a Beauty SaaS Platform

voip push

triggers

device-aware

routing

Call

Survivability

Solutions

Custom Software & Platform Engineering, Mobile App Development, Product Discovery

Industries

Business Automation, Technology

Technologies

Android, AppSync, AWS Amplify, AWS Lambda, AWS SAM, AWS SQS, DynamoDB, EventBridge, iOS, Node.js, Twilio SMS, Twilio Voice

About THE Project

A beauty and wellness SaaS platform offering an AI receptionist needed to move beyond browser-based calling into a mobile experience that could be trusted in real-world conditions.

In this business, missed calls are not a UX issue, they are lost bookings. Salon staff operate on personal devices that are often locked, in use, or restricted by battery settings. If the phone does not ring, the system fails regardless of how advanced the AI is.

Before committing to a full mobile build, the client needed a clear answer to a single question: can a mobile VoIP system reliably behave like a real phone across devices and operating systems, without rebuilding their entire backend?

OBJECTIVES

Validate whether inbound calls can reliably reach mobile devices in real conditions
Define a routing model that reflects actual device state, not static numbers
Extend existing backend systems without introducing long-term technical debt
Identify the real QA and hardware requirements for production readiness
Establish a realistic effort model based on system constraints, not assumptions

Challenges

Solutions

Challenges

Browser-based calling breaks in real environments

The existing system relied on browser-based calling. In practice, this failed in common salon scenarios. Phones are locked, apps are backgrounded, and operating systems aggressively suspend browser processes. Calls simply did not reach the device.

This was not an edge case. It was the default operating condition.

Solutions

Native VoIP execution model

We designed a native VoIP architecture that allows the system to wake devices at the operating system level. This included defining how devices register, how their state is tracked, and how the backend holds and routes calls while waiting for a response.

The result is a system where the call can reach the device even when the app is not actively in use.

Challenges

Number-based routing breaks with real users

The original system routed calls to static phone numbers. This breaks down immediately in real usage. Staff use multiple devices, switch between them, or share hardware at the front desk. Routing to a number does not reflect where the user actually is.

Solutions

Device-aware routing

We replaced number-based routing with device-aware logic. The system resolves which device should receive the call at the moment the call happens, based on activity and availability.

This removes hardcoded assumptions and allows the system to evolve without rewriting the core orchestration layer.

Challenges

QA cannot be simulated

VoIP reliability cannot be validated in simulators. The system must be tested on real devices under real conditions: locked screens, background apps, battery restrictions, and concurrent calls.

This turns QA from a supporting function into a core part of the system.

Solutions

Hardware-first validation model

We defined a device and OS coverage strategy based on real market usage. Physical devices were treated as required infrastructure, not optional tooling.

This allowed the team to validate behavior in the conditions that actually matter.

Challenges

Pressure to compress scope

There was pressure to reduce scope and accelerate delivery by simplifying the initial build. The risk was creating a system that appears to work in controlled scenarios but fails in production.

Solutions

Define the minimum viable foundation

We identified the true minimum as inbound call reliability and device-aware routing. Everything else can be layered on top.

This avoided building a system that would need to be reworked later and the client would receive a production-ready foundation.

project Strategy

Our production judgment centered on risk containment before financial commitment.

Validate the hardest problem first

We prioritized whether the phone can reliably ring under real conditions before investing in UI or secondary features.

Extend systems, don’t rewrite them

We worked within the existing backend, introducing schema-level changes to support device-aware behavior without creating long-term complexity.

Build for independence

All architectural decisions were documented so the client’s internal team could execute without ongoing reliance on external support.

Project Results & Impact

This phase did not produce a finished mobile app. It produced something more valuable: a clear path to a system that will work in production.
A validated approach for delivering calls to mobile devices under real conditions
A defined backend extension model for routing and device management
A QA framework grounded in actual hardware requirements
A realistic roadmap that avoids wasted development cycles