Contactless Everything and What It Means for Apps

July 2020, and every restaurant had a QR code on the table. Every store had a sign about contactless payment. Every business was begging customers to use their app instead of visiting in person. What started as a temporary pandemic adaptation was becoming infrastructure.

I want to talk about what this permanently changed about mobile app requirements because I don't think we're fully grasping the shift yet.

The QR Code Moment

QR codes were dead. Everyone had agreed on that by 2019. They were a relic from five years prior. Useful maybe in specific logistics contexts but not relevant to consumer software.

Then overnight they became essential. Restaurant menus became QR codes. Event check-ins became QR codes. Payment links became QR codes. Restaurants didn't need to maintain a physical menu anymore—just a QR code that linked to a website or app.

This was a temporary hack that turned into a business model. We're now in a world where your app might be consumed primarily through QR codes instead of app store downloads. A customer sees the code, scans it, uses your app once, closes it, never sees it again.

But that single use had to work perfectly. No account creation. No friction. Just immediate, frictionless functionality.

Most apps weren't designed with that in mind. The onboarding flow assumed you were committed to using the app. The first-time UX involved sign-up, verification, permissions requests. Fine if you're downloading Uber. Terrible if you just want to see a restaurant menu.

The Ordering Problem

Restaurants went from "walk in, give your order to a human" to "order through an app" in weeks. This created a cascade of technical requirements that nobody had anticipated building quickly.

Real-time inventory: Your app needs to know what's actually available right now, not what a printed menu says is available. If the kitchen just ran out of the special, someone needs to update the app instantly. Customers don't want to spend five minutes building an order then find out half of it isn't available.

Kitchen integration: Someone's ordering through the app and someone needs to prepare the food. The app had to integrate with whatever kitchen system the restaurant used, or at least send orders somewhere humans could see them.

Pickup logistics: When customers arrive to pick up their order, how do they check in? Do they enter a pickup code? Does the app show their location? Does the restaurant notify them? Every restaurant solved this differently, and most apps weren't designed to handle any of these requirements.

Payment security: Suddenly millions of people were sending payment information through apps that were built hastily and not particularly well. The security implications were enormous and mostly unaddressed.

The Delivery Explosion

Delivery services like DoorDash and Uber Eats existed before COVID. But the volume exploded. Not just restaurants but groceries, pharmacies, retail stores all had to support delivery through apps.

This created a class of apps that needed to be incredibly reliable because they were handling actual money and food safety. But they also needed to be built incredibly fast because the market opportunity was closing (restaurants that don't have delivery are going out of business).

The developers building these were learning in production. Some lessons:

GPS is hard at scale: When you have fifty deliveries happening in a city simultaneously, GPS tracking becomes complex. Real-time traffic routing for fifty different vehicles is genuinely hard. Most apps hadn't thought about this.

The edge cases matter: What happens if a delivery driver's app crashes while they're carrying someone's meal? What if they go offline in a tunnel? What if they're delayed and the customer's food gets cold? These edge cases that you'd ignore in a normal app become financial and customer satisfaction liabilities.

The asymmetric load: A restaurant app has usage spikes during meal times. But a delivery app has unpredictable load based on weather (bad weather = more delivery orders), supply disruption, viral moments. You can't just capacity plan for average usage.

The Privacy Shift

Suddenly apps were collecting location data, payment information, order history, delivery addresses—enormous amounts of sensitive information. And they were doing it hastily.

Privacy became a selling point. Apple leaning into privacy with App Tracking Transparency made sense in this context—people were becoming aware that apps were collecting too much data.

The apps that survived were the ones that asked for the minimum necessary permissions and were transparent about what they did with data. The ones that asked for excessive permissions got a lot of negative reviews.

This is something existing apps should've been doing all along, but the rapid growth of these apps made it obvious what responsible mobile development looked like versus what didn't.

The Infrastructure Requirement

Every one of these apps required backend infrastructure that didn't exist before. Not just databases but real-time systems. WebSockets or similar for live updates. Push notifications that actually worked. Location tracking at scale.

The mobile development community had gotten used to building on top of Firebase, AWS, or GCP, but now they had to think about real-time architecture, database design, and infrastructure costs. A restaurant app that handles a thousand orders a day has different infrastructure needs than a casual app.

This elevated the bar for what counts as a "good" mobile app. You couldn't just build a nice UI and call it done. You needed to think about the backend, the reliability, the monitoring.

What This Means Going Forward

By July, it was clear that the temporary shift to digital-first ordering wasn't going to reverse. Even as restaurants reopened for in-person dining, they kept their apps and QR code menus because they were cheaper than printing menus and useful for customers.

This created a new baseline for mobile app expectations:

Frictionless onboarding: Apps need to work without account creation. Deep links, QR codes, and direct entry need to work.

Real-time data: Inventory, delivery status, order confirmation need to update instantly, not every five minutes.

Reliability at scale: Apps need to handle 10x the expected load without falling over.

Security by default: Payment information needs to be protected. Data collection needs to be justified.

Integration: Apps need to connect to real backend systems, not just display static content.

These were always nice features to have. COVID made them baseline requirements.

The Companies That Adapted

The apps that did well in July weren't necessarily the ones built specifically for COVID. They were the ones that understood mobile UX was fundamentally changing and adapted quickly.

Some of the best restaurant apps were built by restaurants themselves. They understood their business, built something simple and reliable, and made it work. Some were built by third-party developers who understood what restaurants actually needed.

The worst were the ones that tried to replicate their website in an app and call it done. Point-and-click menus that took forever to load. Checkout flows that assumed you could read a six-page form. Apps that required account creation before showing you anything.

The pandemic didn't invent good UX design. But it made the consequences of bad UX a business liability instead of an inconvenience.

By the end of 2020, this would become the new normal. Apps that don't work this way would feel outdated and broken. The temporary pandemic adaptation became the foundation for what people expect from mobile experiences forever after.