Pre-Launch Checklist for Phone as Gateway

A demo that “sends one test SMS from the phone on the desk” is not a production launch. This pre-launch checklist is the gate you run before customer OTP, transactional alerts, or any paced bulk work leave an android phone as sms gateway. Each row has a reason, a verification, and an owner so the go/no-go meeting is evidence-based, not optimistic.

If the only evidence is “it worked once on the desk,” you are launching hope, not a gateway.

Hub series articles cover how-tos in depth; this page is the printable control list that maps those topics into yes/no launch rows. Priced by devices and SMS send volume. You use your own phone and operator SMS credit. Plans are billed as device + SMS volume tiers—not aggregator-style $0.0x-per-message platform charging. Starter, Professional, and Business include unlimited platform send volume; Developer and Free have published SMS caps. Operator airtime remains separate, and carrier fair-use still applies.

Why a pre-launch checklist

Phone-as-gateway launches fail in boring ways: empty prepaid, OEM battery kill after first night, wrong account pairing, webhook that never gets signed deliveries, marketing CSV sharing the only SIM with login OTPs, and zero on-call when last-seen goes stale at 02:00. A checklist does not make radio magic — it makes those classes of failure visible before they hit paying users.

Treat the checklist as a change-control artifact. Attach screenshots, canary message IDs, asset tags, and secret storage locations. When deliverability drops in week two, you know whether the launch package ever locked OEM exemptions. Without that paper trail, every incident restarts archaeology.

Pre-launch is also a scope tool. If bulk campaigns are not ready, the checklist forces an explicit delay line instead of a silent half-launch. Partial go-lives (OTP only) are legitimate; unscoped go-lives are how teams learn the hard way that carrier fair-use and plan allowances are real.

Compare this gate with Setup for first install steps (device setup guide), Pricing for allowance math (device and SMS volume pricing), and Developer Center for live parameter names (SMS API documentation). Security posture honesty lives on the Security & Trust Center.

Glossary

Pre-launch gate

Signed checklist that blocks production SMS until evidence exists for each critical readiness row.

Canary SMS

Staff-facing test send verifying end-to-end path after each material configuration change.

Last-seen

Dashboard timestamp of device contact with the control plane; stale values fail the monitoring pre-launch row.

OEM kill path

Vendor battery/optimization settings that stop background gateway work overnight until exempted.

Lane isolation

Separate device or routing priority so bulk traffic cannot starve OTP and transactional messages.

Dual ledger

Platform plan allowance vs operator airtime — both required for sustained send; checked independently before go-live.

DLR

Delivery report when the handset and carrier expose status; pre-launch proves webhook or poll path works with a canary.

Go/no-go

Explicit launch decision: ship, delay, or reduce scope (e.g. OTP only, no bulk) based on checklist evidence.

Owners and success metrics

Start here. Hardware work without owners produces orphans — phones nobody top-ups and alerts nobody claims. Write success metrics before the first canary so launch day is measured, not performed.

Recommended week-one metrics for OTP-shaped launches: median and p95 time from API accept to Delivered (where DLR exists), percent OTP sessions requiring resend, maximum device offline minutes, and operator airtime burn versus model. If DLR is sparse on your carrier, document secondary validation (user success rate) instead of inventing absolute delivery SLAs the radio cannot prove.

Metrics also need freeze rules. Agree which graph must stay green overnight before marketing bulk may begin. If your OTP resend rate stays above an agreed band, bulk remains off — that single rule prevents campaigns from amplifying a filter or airtime problem into a customer-facing auth crisis.

Rollback is more than “ssh to kill process.” Write the product switch that routes authenticator to email/WebAuthn fallback if SMS must pause, and the ops switch that marks the device maintenance in the dashboard. Both should be practiced in a dry run so on-call is not inventing UI paths at 03:00.

Hardware and SIM readiness

You need a working Android phone with a SIM and SMS credit from your mobile operator. Operator message costs are yours—we do not sell carrier SMS balance. The checklist assumes you already know that. Pre-launch forces proof that the physical path is dedicated, labeled, powered, and funded for launch volume including retries.

Prefer mid-range handsets with stable AOSP forks over unknown OEMs with aggressive memory cleaners. Dual-SIM is a routing feature, not two free devices on pricing — device count still follows connected phones. Document which slot owns OTP if dual-SIM is used so support tickets do not route to the wrong MSISDN.

Airtime math should include OTP retries, wrong-number attempts, and canary burn during drills. A model that assumes one SMS per login undercounts real traffic. Cross-check forecast against monthly operator cost estimation and prepaid vs postpaid choices in prepaid vs postpaid SIM guidance.

Spare devices fail silently if never charged. The pre-launch row is not “spare exists in a drawer” — it is “spare booted weekly, paired or ready to pair, with known airtime.” Photo the shelf layout so night cover can find the right charger when the primary label peels.

Install, pair, and autostart

Install from official download the Android gateway app paths and record version. Pairing to the production account — not a sandbox alias — is a launch item many teams discover when billing and audit trails split.

Reboot drills are non-negotiable. A phone that works for an engineer holding the screen active is not a gateway. Cycle power fully, wait for last-seen, then canary. Time the recovery; if recovery exceeds your OTP SLA, fix OEM autostart before opening traffic.

Permissions should be verified both in Android UI and with a stock Messages app send. When stock SMS works but gateway fails, branch to pairing and app permissions. When stock SMS fails, branch to SIM/RF/airtime — not API key rotation.

OEM power and permissions

OEM kill paths cause most “mysterious night outages.” Pre-launch captures screenshot evidence of unrestricted battery and any required always-on helpers. Vendor menus change by One UI / MIUI / ColorOS version — write the path you actually clicked on this handset.

Overnight hold tests belong on the calendar before launch, not after the first Sev-1. Schedule a canary every hour overnight or use a synthetic check that requires the device to process a small job. One eight-hour green night is the difference between a launch and a weekend pager.

Freeze OS updates for launch week when possible, or stage OS updates on a spare that re-runs this checklist. OS upgrades that revoke SMS roles present as silent API-success / radio-fail. Revisit testing on real handsets when validating new OS builds.

Network and placement

The control-plane channel (Wi-Fi or mobile data for the app) is not the same as RF for SMS, but both must work. Guest Wi-Fi that isolates clients breaks heartbeats and re-pair flows. Shelf placement that looks neat but sits in RF nulls raises fail rates only customers feel.

Document failover if corporate Wi-Fi maintenance is scheduled the launch week. Dual-path devices (Wi-Fi + data) help; so do calendars that ban full-building network windows without warm-spare phones. For cross-country send, local SIMs often outperform international paths — see geo notes when expanding launch markets (SMS gateway by country).

API keys and first canaries

Live request shapes live in SMS API documentation (documented send path on the control plane). Pre-launch is not the place to invent unofficial REST hosts. Prove canaries with production credentials that will actually serve traffic — and store keys outside tickets.

Number format mistakes (missing country code, trunk prefixes) account for many “random” fails. Prefer E.164 normalization in the client before launch. Document whether plus signs are stripped per product docs so every microservice uses the same rule.

Idempotency and timeouts prevent double OTP when gateway or phone is slow. Launch traffic is where ambiguous timeouts explode: users hammer resend, clients retry, SIMs burn. Pre-launch should include a deliberate timeout simulation so product and eng agree what the user sees.

Align API readiness with secure key handling from securing API keys in environment variables. Launch week is a poor time to learn keys were screenshotted into a shared docs folder.

DLR and webhooks

Delivery status closes OTP loops and prevents blind resends. Configure the path documented in the DLR guide and webhook guide. Pre-launch demands a canary that produces a webhook body your logger understands.

Signature verification is not optional if callbacks mutate auth state. Negative-test the verifier. Train support that delayed DLR is normal when handsets sleep or carriers aggregate receipts — otherwise every three-minute DLR lag becomes a false Sev-1.

If you only poll status endpoints, document poll cadence and when to stop polling. Infinite poll loops look like API abuse and waste rate budget that should be reserved for real OTP.

OTP vs marketing lanes

Lane isolation is the highest use soft-gate on shared hardware. OTP that waits behind a bulk CSV is not authenticated login; it is a queue design failure. Launch checklist forces a written routing decision.

Template design for OTP should stay short, branded carefully, and free of marketing fluff that trips filters. See OTP template design and avoiding spammy wording. Pre-launch canary using the real production template string, not “hello test.”

UX cooldowns belong on the checklist because SMS is not free infinite traffic. Align client resend buttons with both user experience and SIM capacity. Document when support escalates vs asks the user to wait.

Throughput and pacing

Single SIMs do not send cloud-scale bursts. Pre-launch models peak hour OTP, expected backlog minutes, and whether bulk is even allowed. If peak exceeds one phone, add devices or reduce concurrent features — do not hope.

Service pricing is based on device count and total SMS sent through the gateway. Free tier 300 lifetime SMS is for proving the path, not absorbing unplanned marketing dumps. Paid plans from $19/month raise device and volume caps. Launch forecasts should list both operator pack headroom and platform allowance so finance is not surprised when sends pause at plan cap.

Use load thinking from careful load testing and throughput expectations from the hub series. Load tests themselves need airtime budget and should never be run against customer numbers.

Monitoring and on-call

Unattended gateways without last-seen alerts are science experiments. Launch requires alarm paths proven by chaos: unplug Wi-Fi, power-cycle without plugging charger, or force-stop the app once — then confirm someone is paged.

Queue depth alerts prevent radio-throttling when a phone returns after outage with thousands pending. Write the drain policy: pace, freeze marketing, OTP priority. On-call rosters must include weekend/holiday coverage if launch windows span them.

Pair monitoring with incident preparation from outage incident response and runbooks in documentation of runbooks. Pre-launch is the right time to print shelf cards, not during an outage.

Consent, STOP, and quiet hours

Authenticator SMS and promotional SMS are not the same legal class. Classification is a pre-launch ownership row. If any promotional or opt-in campaign sits near launch, STOP handling and quiet hours must be green before CSV uploads.

Link STOP implementation checks to STOP and opt-out handling and privacy-minded handling to GDPR-minded data handling. This is not legal advice — it is operational scaffolding so counsel policies actually reach the SIM.

Log retention decisions belong pre-launch so engineers do not dump full OTP bodies into forever indexes. See log retention policy.

Two money ledgers

Every pre-launch review should open a two-ledger slide: operator airtime/bundle vs gateway service plan. Mixing them produces false “Twilio is cheaper” math or surprise pauses. Priced by devices and SMS send volume. You use your own phone and operator SMS credit.

Platform truth: Plans are billed as device + SMS volume tiers—not aggregator-style $0.0x-per-message platform charging. Starter, Professional, and Business include unlimited platform send volume; Developer and Free have published SMS caps. Operator airtime remains separate, and carrier fair-use still applies. Operator truth: prepaid packs empty mid-campaign and postpaid FUPs still apply. Launch capacity that only prices one ledger is underfunded.

Document who tops up SIMs and who upgrades platform tier. Confused ownership during launch spikes means tickets bounce while logins fail. Finance should see forecast messages × rate + plan fee before go-live, not after the first invoice.

Failure drills

Checkboxes without drills are cosplay. Before go-live, run at least these timed exercises with evidence attached:

• Power loss / reboot recovery. Measure minutes to last-seen + successful canary.
• Network path loss. Drop Wi-Fi or data; confirm alert and recovery process.
• Empty prepaid simulation. Or use a spare SIM low on balance; prove support path for top-up without engineering spelunking.
• Device offline while API receives sends. Confirm queue behavior and user messaging when delivery lags.
• Webhook receiver 500s. Confirm retries/backlog handling and that OTP UX does not infinite resend.
• Rollback switch. Disable SMS path from product config and confirm fallbacks.

Record durations against RTO targets in your metrics sheet. If boot-to-canary exceeds OTP timeouts, either shorten recovery or redesign UX expectations before launch, not after.

Optional advanced: secondary device failover. If multi-device is in scope, dry-run traffic shift per multi-device dual-SIM and rotating devices for volume.

Printable master checklist

Copy this into your launch ticket as a closed checklist. Every critical row needs attached proof (screenshot, canary ID, or link). Non-critical can defer but must be explicit.

• [O1] Named launch owner and on-call for launch week — Owner: Ops lead. Verify: Calendar invite + pager/chat channel documented with backup person.
• [O2] Written success metrics for week one — Owner: Product + eng. Verify: One-page metrics signed by product + eng.
• [O3] Rollback defined (pause client send path) — Owner: Engineering. Verify: Flag/config name + who can flip it in <5 minutes.
• [O4] Scope frozen: OTP only / OTP+txn / include bulk — Owner: Launch approver. Verify: Scope line in launch ticket.
• [H1] Dedicated Android device assigned and labeled — Owner: Ops. Verify: Asset tag photo + shelf map link in runbook.
• [H2] SIM active with known MSISDN and plan type — Owner: Ops. Verify: Handset Settings shows number; test stock SMS to staff phone.
• [H3] Operator airtime/bundle covers launch volume + retries — Owner: Ops / finance. Verify: Balance or postpaid limit check + 20% headroom math.
• [H4] Power path: charger, cable, optional UPS — Owner: Ops. Verify: Boot after unplug/replug test completes without human rescue.
• [H5] Spare charged device exists if OTP is revenue-critical — Owner: Ops. Verify: Second device paired dry-run or documented as warm spare.
• [I1] Official APK installed from trusted Downloads source — Owner: Ops. Verify: Match published integrity notes / SHA when provided; installed version recorded.
• [I2] Device paired to correct account — Owner: Ops + eng. Verify: Dashboard lists device ID matching shelf label.
• [I3] Autostart / boot recovery proven after reboot — Owner: Ops. Verify: Full power cycle → last-seen fresh → canary within target minutes.
• [I4] SMS default / role permissions accepted — Owner: Ops. Verify: Stock SMS app send + gateway canary both succeed.
• [E1] Battery unrestricted / ignore optimizations for gateway app — Owner: Ops. Verify: OEM menu path screenshotted + overnight hold test (8h).
• [E2] Lock-screen / always-on policies set intentionally — Owner: Ops. Verify: Written decision: always-on helper or OEM-native setting; overnight canary schedule.
• [E3] OS update freeze until after launch week (or tested update) — Owner: Ops. Verify: Auto-update disabled or staged on spare device first.
• [N1] Stable path for control plane (Wi-Fi or data) documented — Owner: Ops. Verify: Path choice + fail scenario written (guest Wi-Fi isolation, ISP outage).
• [N2] RF coverage acceptable at shelf location — Owner: Ops. Verify: Signal bars at shelf; optional carrier-to-carrier test to top destinations.
• [N3] Firewall/proxy allows device and server callbacks — Owner: Engineering / IT. Verify: Webhook receiver reachable from internet; canary DLR arrives.
• [A1] API key minted for production, not shared in chat — Owner: Engineering. Verify: Secret in env/secrets manager; rotation owner named.
• [A2] Canary via documented send endpoint succeeds — Owner: Engineering. Verify: Canary to staff E.164; response message ID stored; DLR observed if used.
• [A3] Client timeouts, retries, and idempotency documented — Owner: Engineering. Verify: Code review note or runbook section for ambiguous timeout path.
• [A4] Rate and 429 handling tested — Owner: Engineering. Verify: Controlled burst shows backoff behavior in logs.
• [D1] Webhook URL (or poll path) configured and authenticated — Owner: Engineering. Verify: Canary triggers webhook with expected status progression.
• [D2] Signature verification enabled for callbacks — Owner: Engineering. Verify: Negative test with bad signature rejected.
• [D3] Team trained that carrier DLR is not absolute real-time SLA — Owner: Support lead. Verify: Support FAQ + launch metrics use realistic windows.
• [L1] OTP device pool isolated from marketing bulk — Owner: Eng + ops. Verify: Routing table or single-device role: OTP-only at launch.
• [L2] OTP template length and brand prefix decided — Owner: Product. Verify: Sample string segment count checked; staff readability test.
• [L3] TTL and resend cooldowns match product UX — Owner: Product + eng. Verify: Code + SMS body minutes agree.
• [T1] Peak hour forecast vs single-SIM capacity — Owner: Eng + ops. Verify: Peak-hour model + backlog minutes estimated.
• [T2] Bulk deferred or paced if in scope — Owner: Product. Verify: Bulk off until OTP stable, or separate SIM + paced jobs.
• [T3] Platform plan devices/SMS allowance covers launch week — Owner: Finance + eng. Verify: Tier vs forecast table attached to launch ticket.
• [M1] Last-seen alert with threshold — Owner: Ops + eng. Verify: Simulated offline triggers alert within agreed minutes.
• [M2] Queue depth alert — Owner: Engineering. Verify: Alert on rising pending; flush policy written.
• [M3] On-call roster for launch window — Owner: Ops lead. Verify: Roster list in channel topic.
• [C1] Opt-in / transactional vs promotional classification written — Owner: Compliance. Verify: Counsel or compliance owner sign-off note.
• [C2] STOP / opt-out path works for non-OTP traffic if any exists — Owner: Product + eng. Verify: STOP canary suppresses next campaign row.
• [C3] Quiet hours policy known for markets served — Owner: Product. Verify: Scheduler windows documented or bulk postpones.

Total critical rows above cover ownership, hardware, install, OEM, network, API, DLR, lanes, throughput, monitoring, and compliance — the minimum for a careful OTP-capable launch. Customize IDs into your ticket system so incomplete rows block merging.

Sister checklists in this series (when published) deepen weekly ops, security hardening, device health, API production readiness, focused OTP launch, and bulk campaign gates. Do not wait for them to run this master gate — OTP readiness cannot defer forever on checklist completeness.

Go/no-go sign-off

Use three outcomes only:

• Go. All critical rows green with attachments; metrics watchlist owned; on-call live.
• Go reduced. OTP/txn only; bulk and multi-region deferred with dates.
• No-go. Any of: unrecovered reboot drill, empty airtime model, missing API/DLR canary, unisolated marketing bulk on sole SIM, no on-call, platform allowance known-insufficient for forecast.

Signatures: launch owner, engineering, ops, and product (or combined roles on tiny teams). Date/time and ticket link belong in the repo or ITSM pack. Post-launch, reopen the checklist 48 hours later for leaky items found in production — do not reinvent.

Reduced go is a feature. Many teams ship OTP on a hardened phone first, then enable bulk spreadsheet campaigns after a quiet week of metrics. That sequence is professional, not timid.

Common launch mistakes

• Lab-only validation with screen-on devices that later die to OEM killers overnight.
• Shared SIM for OTP and bulk during the first marketing win campaign.
• Ignoring dual ledgers and treating platform plan as unlimited cloud SMS.
• No rollback switch besides “hope the radio recovers.”
• Unsigned webhooks or never proving DLR receives canaries.
• Keys in chat logs from thrashing config on launch day.
• Skipping reboot drills because “we’ll reboot after launch.”
• Invented API hosts in client code that only worked against a mock.
• Zero spare airtime headroom for retries and support canaries.
• No human on-call for the first weekend of production OTP.

Each mistake maps to a checklist ID above. When you see a failure pattern in postmortems, add a new permanent row rather than assuming memory will hold.

Next steps

Return to the hub Android phone as SMS gateway for conceptual orientation. Complete Setup (device setup guide), confirm API details (SMS API documentation), verify pricing fit (device and SMS volume pricing), and install from trusted download the Android gateway app. Wire DLR early (SMS delivery reports (DLR)) and webhooks (SMS webhook integration).

After this master gate, schedule weekly ops habits and security reviews so launch week gains do not rot. Keep runbooks current, train support on real SIM failure branches, and expand devices only after OTP metrics are boring. That is how an android phone as sms gateway becomes reliable infrastructure instead of a lab trick.

Final reminder: You need a working Android phone with a SIM and SMS credit from your mobile operator. Operator message costs are yours—we do not sell carrier SMS balance. Service pricing is based on device count and total SMS sent through the gateway. Free testing capacity is 300 SMS lifetime on the free tier; production load needs a plan from $19/month upward with enough device slots and SMS allowance — plus operator credit you buy yourself. Sign the checklist only when both ledgers and the radio path are proven under failure, not just under sunny-day demos.

Copy the master bullet list into your launcher document today, assign red owners for open rows, and do not open customer OTP until green is honest. That discipline is the entire product of this checklist.

Suggested launch-week timeline

Checklists work better as a calendar than a single late-night scramble. A realistic single-device OTP launch for an android phone as sms gateway often looks like this — compress only if spare hands and hardware already exist.

T-10 to T-7 days: freeze scope (OTP only or OTP plus transactional). Name owners. Order spare phone and prepaid packs if needed. Confirm product fallback paths (email/WebAuthn) still work without SMS so rollback is real. Draft metrics sheet with p95 and resend targets.

T-6 to T-4 days: physical install on dedicated shelf. Official APK, pairing, reboot drill, OEM battery unrestricted. Overnight hold canary every hour. Begin dual-ledger forecast: operator pack size and platform plan allowance both modeled for two weeks including support canaries.

T-3 days: production API keys in secrets store. Canaries through the real application path, not only curl. Webhook/DLR proof including signature failure negative test. Document idempotency for timeouts. Dry-run on-call page by deliberately offline-ing the phone for fifteen minutes.

T-2 days: lane isolation confirmation. OTP template locked. Support FAQ published. Bulk disabled or parked on separate device. Quiet-hour / classification note signed if any promotional content exists near the product. Run failure drills that still red; re-run until green or declare no-go.

T-1 day: freeze config changes except emergencies. Re-verify airtime balance and platform allowance remaining. Confirm spare phone charged. Launch channel open with on-call roster in topic. Final canaries with production templates to three staff handsets on different operators if you serve multi-carrier destinations.

T-0 go window: flip feature flag for limited cohort (5–10% logins if product allows). Watch resend rate, last-seen, queue depth, and airtime for the first two hours. Expand cohort only if green. If any critical alarm fires without recovery under your RTO, roll back SMS path and keep the cohort on alternate factors.

T+1 to T+7 days: open full OTP traffic when metrics stay boring. Defer bulk at least until one quiet week unless a separate SIM was in the launch package. Reopen the checklist, archive attachments, file improvements for weekly ops and security hardening lists. Schedule the first post-launch retrofit for any OEM menu that changed after an accidental OS update.

What to put in the evidence pack

Auditors and future on-call do not care that someone said “we checked.” Attach artifacts:

• Photos of shelf label, charger, and asset tag next to the phone.
• Dashboard screenshot showing device online with matching ID shortly before go-live.
• Canary message IDs with timestamps and destination staff numbers (partial redaction ok).
• Webhook log snippets (no full OTP codes) proving signature verification accepted a real event.
• Airtime balance screen or operator portal snapshot within 24 hours of launch.
• Platform plan screenshot showing device slot and SMS allowance headroom after canaries.
• Reboot drill timer: wall-clock from power-on to successful canary.
• On-call roster screenshot for launch dates.
• Signed go/no-go comment on the ticket with reduced-scope notes if applicable.

Store the pack where ops actually finds it during incidents — same place as runbooks. If you use MCP-style doc tooling or internal search, tag the pack with the device asset ID so agents and humans land on the right handset context. Documentation tools do not send SMS; they only index decisions.

Redact secrets ruthlessly. API keys, webhook secrets, and full MSISDNs of customers do not belong in a broadly shared pack. Prefer secret manager paths and last-four patterns. Launch thrash is when keys tend to leak into screenshots — assign a second person to review the pack for secrets before it lands in chat.

Multi-site and franchise pre-launch

If several locations each run a phone, the checklist multiplies. Central engineering owns API patterns and key policy; local ops owns shelf power and operator top-ups. Do not centralize airtime cards that only one HQ team can recharge if stores open on weekend evenings without HQ support.

Run a pilot site to green before cloning. Cloning a half-configured image across twenty stores clones OEM mistakes. Require each site’s reboot drill attachment before that site enables SMS OTP in the product toggles. Franchise playbooks should link this article as the master gate and store local photos per site wiki.

Number formats differ by market. Pre-launch for multi-country expansions must include localization of E.164 normalization and language templates — see multi-country number formats and localizing message language. A template that works in English GSM-7 can explode segment cost and filter rates in Unicode markets.

Stakeholder communications at cutover

Tell internal stakeholders what SMS launch means operationally: phones can go offline, carriers throttle, and platform allowances pause when exhausted. Over-promising “carrier-grade 99.99%” on a single Android SIM sets you up to miss trust later. Point enterprise buyers at the honest Security & Trust Center for certification roadmap language rather than inventing SOC 2 completion in launch emails.

Customer-facing status pages should use plain language: “SMS authentication may be delayed; email code available” beats silence. Pre-write that status blurb so marketing does not improvise technical falsehoods under pressure.

Sales teams occasionally promise global reach from one local SIM. Pre-launch is when product must veto those claims. Coverage is the SIM’s operator footprint — not a magically global aggregator network. Link sales to Twilio vs Android SMS gateway for honest tradeoffs before they quote timelines that depend on cloud coverage.

First seventy-two hours after go

The checklist is not finished when traffic turns on. Hold a short stand-up each morning of the first three days covering: overnight last-seen, resend rate trend, airtime remaining, platform allowance remaining, and any support tickets with “code not received.” Escalate OEM or filter issues early while memories of launch configuration are fresh.

Resist feature adds during those seventy-two hours. No bulk CSV, no template redesign, no OS updates, no “quick” dual-SIM experiment unless the reduced-go plan already scheduled it. Stability is a feature ship.

When green holds, graduate into weekly ops: power inspection, balance checks, alert audits. Future checklist articles in this hub will specialize those routines; this pre-launch gate remains the immutable prerequisite whenever a new site or new critical lane goes live.

If metrics degrade, re-enter the no-go mindset without ego. Rolling back SMS OTP while email factors hold is professional. Leaving half-broken SMS live because launch optics hurt is how reputations burn faster than airtime packs.

Capture three improvements into runbooks within a week of launch. Checklist culture compounds only when launch pain updates permanent procedures. Otherwise the next site relearns the same OEM path under a different manager.

How to prioritize when short on time

If leadership demands a cutover tomorrow with incomplete rows, rank ruthlessly:

1. Dedicated powered phone with airtime and reboot recovery.
2. Working API canary + key not in chat.
3. OTP not sharing queue with bulk.
4. Last-seen alert reaching a human.
5. Rollback switch exercised once.
6. Webhook/DLR canary if product depends on delivery state.
7. Everything else with explicit debt tickets and dates.

Items 1–5 are rarely negotiable for unattended OTP. Shipping without them is gambling, and the house is the carrier radio. Document what you skipped so debt is visible — silence converts temporary hacks into permanent architecture.

Never skip dual-ledger awareness even under time pressure. Empty SIMs and exhausted platform allowances have identical customer symptoms (codes never arrive) but entirely different fix paths. If finance cannot confirm money/airtime for three days of traffic, that is a no-go irrespective of green OEM screenshots.

One-page launch declaration template

Paste and fill before the go meeting:

ANDROID PHONE AS SMS GATEWAY — PRE-LAUNCH DECLARATION
Site/app: ____________ Date: ____________ Ticket: ____________
Scope:  [ ] OTP only  [ ] OTP + transactional  [ ] Bulk scheduled for ______
Device asset ID: ____________ MSISDN last4: ____________ Slot: ____________
Platform plan: ____________ Allowance remaining after canaries: ____________
Operator plan/prepaid status: ____________ Headroom %: ____________
Reboot-to-canary minutes: ____________ Overnight hold: [ ] pass [ ] fail
API canary message IDs: ____________
DLR/webhook canary: [ ] pass [ ] n/a because poll-only
On-call primary/backup: ____________ / ____________
Rollback owner + method: ____________
Bulk isolated from OTP: [ ] yes [ ] not in scope
Known deferred debt: ____________
Decision: [ ] GO  [ ] GO REDUCED  [ ] NO-GO
Approver signatures: Ops ______ Eng ______ Product ______

Filling this declaration forces honesty. Empty fields are no-go by default. When everyone can see the blanks, political pressure to “just ship” collides with paper evidence — which is the point of a pre-launch checklist for phone-as-gateway systems.