Building Apps During a Pandemic

By early April, we were three weeks deep into something nobody had a name for yet. Lockdown. Shelter in place. The economic shutdown. Our team was scattered across the city in separate apartments, working on Zoom calls while our clients were dealing with the end of their revenue streams.

And we were building a mobile app.

I'd question the sanity of that decision, except we also discovered—as did hundreds of other software teams—that keeping people focused on concrete deliverables was one of the few psychologically stable things we could do.

The Context Switching Never Stopped

In the office, you can context-switch by walking to someone's desk or calling a meeting. Remote, it's all Zoom. Every problem requires scheduling. Every quick question becomes "sorry, can I get ten minutes on your calendar?"

We had a backend team, a mobile team, and a design team all working on the same app. Integration issues would surface on video calls. Someone would need to unblock someone else. The coordination overhead went up by maybe 60%, which sounds manageable until you apply it to eight-hour days and realize everyone is exhausted by 2 PM.

We ended up doing daily standups that ran longer than we'd budgeted because everyone was also processing the surreal reality of the situation. The anxiety leaked into the meetings. People were worried about family members. The news was bad every day. And we were trying to be productive.

What saved us was being extremely disciplinary about async communication. We had a Slack channel where we documented everything. What's being built. What's blocked. What needs review. People who weren't in the 10 AM standup could catch up. If you needed to reach someone on a specific issue, you left a detailed message instead of demanding an immediate call.

Design in Uncertainty

Our designer was trying to mockup features while literally not knowing what the world would look like in two weeks. The apps everyone was building in April 2020 were either survival tools for the crisis or completely tone-deaf luxuries depending on your perspective.

We scrapped three mockups because they assumed a normal economy. We redesigned to assume scarcity. Fewer features. Simpler interface. Focus on the core job the app needed to do, because nobody had bandwidth for anything else.

There's something clarifying about designing when uncertainty is existential. You stop worrying about whether the spacing is perfect and focus on whether the feature actually works and whether anyone will care if it does.

Testing When You Can't Hold the Phone

QA normally involves passing physical devices around, having people tap through the app, watching where they get confused. Remote QA meant recording video, sharing screenshots, describing interactions in Slack.

We used Testflight more than we'd ever planned to. We had beta testers sending in reports from home. The feedback loop was slower but also broader—we were getting real-world usage patterns instead of just people clicking through a script.

The downside: you can't debug something in person anymore. "The payment form doesn't work" means you need the tester to send a full screen recording, detailed reproduction steps, and hopefully a screenshot of error logs. It takes ten times longer than walking over and watching someone's screen.

We learned to build better error messages. When the only way to debug is through remote reporting, you need the app to tell you exactly what went wrong. Vague failures became visible liabilities.

The Async Release

Normally we'd do releases from the office, sit around watching Crashlytics for the first hour, be ready to hotfix if something broke. In April, releases happened across time zones, with people checking in periodically from home while doing laundry and video calls with family.

It was terrifying in a way I hadn't anticipated. Your app goes live, and you're distributed across the city with laptops and spotty wifi. Someone reports a critical bug via Slack while you're on a video call. Someone else is available to fix it, but they need the third person to review and you're both busy.

We automated a lot more. Better staging environment. Better tests. Rollback procedures that didn't require anyone to ssh into servers. By our second release, we'd learned to release conservatively and check in asynchronously.

Nothing broke catastrophically, but only because we learned the hard way to assume the worst-case scenario: nobody's immediately available.

Why It Mattered

The apps we shipped weren't miraculous. They were probably no better than apps we would've shipped in normal times. But shipping them mattered to the people using them.

One app helped restaurants manage limited capacity and outdoor seating. Another helped essential workers find free COVID testing. Another was just helping people check if local businesses were still operating.

The psychological effect on our team was real too. We were shipping things. Making something work. Having small wins in a period when almost every other metric in society was negative.

The Burnout Didn't Hit Until June

I thought we'd collapse in April. We didn't. I thought the uncertainty would paralyze us. It didn't, really. Everyone just adapted and worked and didn't think too much about what else was happening.

The burnout came later. By June, I noticed people were quiet on Zoom. Less engaging in standups. Turning off cameras. The initial sense of purpose had worn off and what remained was just exhaustion.

We ended up working less hours, not more. We ended up shipping slower, not faster. We learned that building apps during a pandemic works fine for a couple of months and then stops working because humans need things that remote work doesn't provide.

But for those couple of months, the structure of software development was exactly what people needed.

The apps shipped. The team survived. And we learned that when everything else is falling apart, having a clear technical problem to solve is sometimes the most stabilizing thing there is.