Half the people you send agreements to sign on a phone. For some industries — real estate, employment, anything consumer-facing — that number is closer to seven in ten. The default e-signature flow, built around a desktop browser and an email client open in a tab, fails most of those signers in small ways that add up. Here’s what mobile-first actually means in practice.
The default flow breaks on phones
A typical desktop-first signing experience: you receive an email, click a link, the document opens in an embedded PDF viewer, you scroll through, you click a signature field, you draw with a mouse or upload an image, you click sign, you’re done. Translated to a phone, every step has a gotcha.
- Email links sometimes open in the in-app browser of whatever email client the signer uses (Gmail’s, Outlook’s, the iOS Mail webview), which has its own quirks.
- PDF viewers on iOS Safari and Android Chrome handle XFA forms differently from each other and from desktop. Forms can render blank.
- Drawing a signature with a finger on a 6-inch screen produces a different artifact than drawing with a mouse — the platform needs to render that signature image at a resolution that survives PDF rasterization.
- Signers thumb back to email mid-flow to check a confirmation code, then return to the signing tab — which has been backgrounded, possibly killed by iOS for memory pressure, and the signing state needs to survive that.
What mobile-first actually requires
Building a signing flow that works equally well on a phone means making decisions other platforms haven’t:
- Pre-flatten every PDF. XFA forms, AcroForm fields, scans — all flattened to a single, viewer-agnostic canvas before the signer ever opens the document. No surprise blank pages on iOS Mail.
- State persistence across backgrounding. Every field interaction is saved server-side, not in browser memory. If iOS evicts the tab to reclaim RAM, the signer reopens the link and resumes exactly where they were.
- Signature capture sized for thumbs.A signature field that’s comfortable with a finger on a small screen is too big for a mouse — and vice versa. Resize per device, don’t pick one.
- OTP that works in the email app’s in-app browser. SMS one-time codes need to be readable and pasteable from the iOS auto-fill suggestions; email-based confirmation needs to deep-link back into the same session, not start a new one.
- Single-screen review.A summary screen before signing that shows the document, the recipient’s identity, and the consent disclosure on one screen — not three modals deep.
The signer doesn’t install an app
One of the most common “mobile-first” claims is “our app supports iOS and Android.” That’s the wrong frame. Signers are people you’re sending an agreement to once. They aren’t installing an app for the privilege of signing it. Mobile-first means the entire flow runs in the mobile browser, with no install prompt, no account creation, no friction beyond clicking the link.
What this looks like for senders
You don’t need to do anything special on the sender side. You compose the envelope on a desktop (or a phone — the composer works either way), add recipients, send. The platform figures out what each signer needs based on the device they open the link on. Field positions, signature canvas size, OTP delivery, session persistence — all adaptive.
The bar is invisible. A signer on a phone has the same experience as a signer on a desktop, in terms of how easy it is to get through. That’s the test. If your platform passes it, you’ll see completion rates climb without doing anything else.