A business phone app for one-person service businesses
LarLine gives one-person service businesses a separate business number that lives in an app on their phone and texts back the callers they could not answer. VLO Labs designed, built and runs the product, including the iOS and Android apps, the web portal and the calling and billing backend.
- Industry
- Business phone and texting software
- Project type
- VLO Labs product
- Status
- Live on iOS and Android in the US
- Platforms
- iOS, Android, Web
The challenge
A plumber on a job or a stylist with a client cannot stop to answer every call, and a caller who reaches voicemail may simply try the next business on the list. Using a personal cell for the business also means printing that number on the truck and on every listing, with work and private calls arriving on one line.
To the phone network, a forwarded call picked up by a cell carrier's voicemail looks answered, so a connected call does not prove a person picked up. A business phone app also has to ring like a real phone when it is closed or the screen is locked, which depends on each platform's own calling and push systems.
Texting and billing added their own constraints. US carriers expect businesses to register before they text, and traffic from one bad sender can get messages filtered for others on the same registration. Because LarLine sells through Apple and Google as well as the web, subscriptions had to work across three separate payment systems and still give one clear answer to whether an account is paid.
Our approach
VLO Labs built one backend as the single source of truth, with the web portal and the mobile app as clients of it. The phone app holds no carrier API key and connects to calls with short-lived credentials issued by the backend, so permissions, call history and routing stay in one place. Carrier-specific code sits behind a single adapter layer.
Product decisions followed from who uses it. The owner's screens say your number, your cell, calls, texts and missed, and avoid telecom terms. An incoming call goes to the app or the owner's cell, never both. When a call goes to a cell, the person answering is asked to press 1 before the caller is connected, so that a carrier voicemail pickup is not counted as an answered call. Automatic answering-machine detection was rejected because its mistakes can hang up on real customers.
Two areas were kept deliberately narrow. On customer lines the AI only drafts and suggests, and a person taps Send on every AI-written reply. Sending limits are designed around how service businesses actually text, so ordinary contact with existing customers is left alone while bulk messaging patterns are refused. Calling and texting were also tested on a real iPhone and a real Android phone, because some failures only appear on real devices.
What we built
Business number and call routing
A US business number in the area code the owner picks. Calls ring the app or the owner's cell, callers see the LarLine number and not the personal cell, and business hours send after-hours calls to voicemail with a written transcript.
Missed-call text-back
On the Business and AI Pro plans, an unanswered call triggers a text to the caller from the business number, in the owner's own words. Delivery is tracked and the reply lands in the same thread.
iOS and Android app
One Expo and React Native codebase covering calls, texts, a To do list of open items, number settings, signup and billing, with the operating system's own incoming-call screen.
Web portal with browser calling
A React portal at app.larline.com gives owners the same calls and texts in a browser, including a softphone for placing and answering calls without a phone.
AI Pro assistant
Pulls the promises out of the owner's texts and tracks them, drafts replies for the owner to send, and warns before a double booking. The plan also adds a caller menu.
Subscriptions on three payment systems
Plans sold through Stripe, the App Store and Google Play feed one set of account entitlements, and a number is bought only after payment is accepted.
Engineering highlights
Calls that reach a closed or locked phone
An incoming call wakes the app through Apple and Google push and appears in CallKit on iPhone or ConnectionService on Android. Answering from a killed or backgrounded app takes separate code paths, and each case was tested on physical phones.
One account model across three billers
The backend keeps each store's differences at the edge and shares one provisioning path. Store notifications only prompt a check with the store's own server, and an account billed by one system is refused by the others on the server.
Proving a signup comes from a real app
Signup requires a browser check or device attestation (Apple App Attest or Play Integrity). Each verification step has a test that fails when that step alone is broken, and the suite includes an attestation from a real device, because a verifier tested only on its own fake data can pass while rejecting real phones.
AI that structurally cannot send
The code that extracts promises and drafts replies has no path to the send function, so a person remains the sender on customer lines. Models run on Cloudflare Workers AI, so this message content does not go to an outside AI company. The model never does date arithmetic: it copies dates from a calendar placed in its prompt.
Where it stands
- App Store
- Live on the App Store
- Google Play
- Live on Google Play
- Backend in production
- Since August 2026
- Automated tests
- More than 900 on the backend and more than 200 on the web portal
Technology
Have something similar in mind?
Tell us what you need to build and we will give you a straight answer on how to approach it.
Get a free consultation