Shipping an App in Ten Days
When the COVID-19 pandemic hit, the UK’s National Health Service found itself facing a communications challenge: how do frontline staff communicate with patients when both are wearing masks, or when the patient is deaf or speaks limited English? Phil Smith, founder of the digital agency amillionmonkeys, responded by building CardMedic, a mobile app that displays medical information as text on a screen. In this episode of the Smashing Podcast, Drew McLellan speaks with Smith about how he was able to go from idea to deployed application in roughly ten days.
Why Mobile First
Smith chose a mobile approach for practical reasons. A hospital environment is noisy and chaotic, and phones are the most accessible piece of hardware available to both staff and patients. The app needed to work reliably in that setting: no Wifi in some areas, no time to teach users a complex interface, and no margin for errors in critical medical communication. The result is a tool that presents common assessments and phrases — everything from pain scales to pre-surgery instructions — as readable cards on a handset screen.
The Build Stack
Rather than a native development effort, Smith leveraged a toolchain that could ship quickly across platforms. The core decision was React Native for the mobile application. To ensure a decent user experience before the constraints of the clinical setting, the app uses React Native for the fast-moving codebase, but links to the web layer of React Native. That web layer, provided by React Native for Web, allowed a single codebase to run both on iOS, Android, and in browsers.
To keep the development cycle lean, Smith also relied on Expo. Expo handled a significant chunk of the configuration and build process, making it possible to iterate quickly without the low-level complexities of native toolchains. On the data side, he used Apiary for API design and documentation.
Prototyping to Production
In a typical agency context, building an app in ten days sounds like a heavy compromise. But Smith’s path was all about ruthless prioritization. The team focused on the clinical user journey rather than chasing feature breadth. Where tradeoffs had to be made, the team looked at the impact on users straight away and steered clear of improvements that only mattered in edge cases. The result is an MVP that solves a major real-world problem, rather than a shallow demo with ambitious promises — a balance Smith generally advocates, partly informed by his long background in building short, intense projects.
By using a single React codebase to serve both the native and web experiences, the project not only stood up fast but also allowed another key distribution pathway: the web version could be reached without requiring anyone to download the app. In an emergency-response setting, minimizing friction at the point of care was decisive.
The CardMedic project offers a strong case study for teams wanting to ship high-stakes products in a compressed timebox. Using modern tooling to minimize configuration, consolidating work around a web/native bridge, and being disciplined about scope can turn an emerging crisis into an opportunity to release something genuinely useful.
Turning a COVID Flashcard Site Into a Native App in 10 Days
When the COVID-19 pandemic hit, full-stack developer Phil Smith found himself in the same position as many technologists: stuck at home, trying to homeschool kids and keep his Brighton-based studio amillionmonkeys afloat. A conversation with a friend via the local tech group Wired Sussex changed his focus.
A contact named David had a friend, Rachel, who had built a Squarespace site called CardMedic. The site was a flashcard system designed to help medical practitioners communicate with patients during the crisis — particularly where language barriers or the impersonal nature of PPE made standard interaction difficult. Rachel needed a developer to turn that site into a native mobile app and add features. She had no budget and an extremely tight deadline.
What CardMedic Does
CardMedic addresses a specific set of problems that emerged as the pandemic spread. Clinicians with no respiratory experience were suddenly caring for COVID patients, and those patients often did not speak English as a first language. The app presents flashcards for common clinical scenarios — say, explaining to a patient why they are having difficulty breathing — that the practitioner can show directly to the patient. The text can be read aloud, and the content is available in 10 languages, all machine-translated at the time of launch.
Smith and Rachel agreed from the start on a tight scope for version one. The core feature set coming from the existing website would ship: language translation, text-to-speech read-aloud, and an alphabetical card list. One new feature made the cut as well: a card where practitioners can take a headshot and pair it with an introductory note, helping patients connect a face to the voice hidden behind PPE.
Everything else was parked and prioritised after launch. Once the app shipped, feedback came quickly — including from non-practitioners — and the challenge shifted to filtering constructive clinical suggestions from general noise.
A Stack Built for Speed
Smith’s first move was conceptual: he sketched data models on an A3 pad to define how a multilingual API might be structured. He then turned to Apiary to write API documentation and generate a mock API. This served two purposes: it gave him a concrete standard to build against and allowed him to switch between back-end and app development as the mood (and available time) took him.
The back-end itself was built with Laravel, Smith’s default for any server-side work. He credits the framework’s speed and documentation for getting the back-end roughly 90% complete within three days. One particular pain point Laravel smoothed over was throttling: the APIs used for audio transcription and translation are heavily rate-limited, and managing request queues manually would have been a significant time sink.
With the back-end standing and an admin interface in place for content editing, Smith turned his full attention to the mobile app. It is written in React Native and compiled for both iOS and Android. The critical accelerant was Expo.
Expo’s wrapper around React Native eliminated the slowest parts of the mobile development loop. Instead of submitting a full build to the App Store or Play Store every few hours, Smith could push a JavaScript bundle to Expo’s servers. Rachel could then load that bundle inside the Expo Client app on her Android device and see changes almost immediately. Expo also handled the notoriously difficult production build process, including certificates and keys, from its CLI — a level of documentation quality Smith says is rare and constantly kept current with the storefronts' changing requirements.
On the client side, Smith leaned on a familiar pattern: Redux for state management, with a layer of stateless components at the presentation layer. He also chose to write the app in TypeScript this time round, even knowing it would slow initial development. The editor intelligence and type safety prevented undefined errors early, and Smith sees refactoring the loose types later as a known technical debt.
Why Not a PWA?
PWA technology was considered, but Smith felt it was not ready for this specific use case. An announcement he had read on Jeremy Keith’s blog made him nervous about the platform’s stability. More importantly, he judged that asking users to install an app from the store was a simpler, more familiar instruction than asking them to understand what a progressive web app is. "It just felt safer," he said, "to get the app done."
Interestingly, Smith plans to standardise the entire front-end on React Native Web in the future. This package allows a React Native codebase to spit out HTML and JavaScript for the browser. He notes that one included package does not currently transpile to React Native Web, so he plans to drop it and unify the flashcard experience so that a single codebase calls a single API, whether on the app or the marketing site. For now, the website itself runs on Squarespace with Vue script tags for interactivity, because it was the fastest way to get the functionality in place without a build step.
Multilingual Content and Translation
The multilingual capability relies on Weglot, a service Smith found surprisingly robust. It is typically a Squarespace plugin that proxies subdomains and translates pages on the fly. CardMedic’s back-end post up-to-date card data to Weglot's API with a list of active languages, and Weglot sends back machine translations.
The plan is to move past machine translation. CardMedic expected a professional translation service to pick up the work, and volunteers from countries like Hungary have also come forward. Smith built an editor tool so that these volunteers can claim untranslated articles and deliver native-language updates, which can be pushed live as completed.
The Tricky Path to App Store Approval
The most stressful part of the project was not the development but the store submission process. The first iOS submit came from Smith's personal developer account and was promptly rejected with a stern notice referencing a policy that only registered companies could release COVID-related apps — a document Smith had not seen. He rushed Rachel through registering a company developer account, and once the app was resubmitted under her ID, it was approved immediately.
The Android process was drawn out over 10 days. Google’s initial rejection was harsher, alleging profiteering from the pandemic and insensitivity. Smith responded with a firm appeal, pointing to a letter from a hospital consultant plus coverage in The Guardian, the BBC, and the government’s own site. Google approved the app the following morning.
Hosting and Future Work
The back-end runs on a Digital Ocean droplet, which is set up and managed via Forge, a service created by Laravel’s founder Taylor Otwell. Forge automates the sysadmin side of things — cron jobs, deployments, and even the process of provisioning S3 buckets. A COVID relief program from Digital Ocean covered the hosting costs, so nothing was paid for.
Smith concedes the API layer could probably have been serverless, since the workload is light — content is cached and flushed hourly. But the serverless ecosystem was not something he could churn out quickly under this deadline. In hindsight, his one regret is not building with React Native Web from the beginning, and he wishes he could have had a designer’s eye on some of the screens — particularly the one The Guardian chose to feature.
Where does CardMedic go from here? The immediate roadmap involves better translations, illustrations for certain cards, and a reworked “My name is” screen that must work offline. Smith also sees a steady need for new cards as more use cases and stories surface from the field.
His parting advice for other front-end developers is straightforward: if you already work in React, React Native is well within reach. Expo's tooling and documentation handle the historically dreadful certificate and store-submission process, and Smith believes the barrier to entry is far lower than the reputation suggests. "Even if you don't ship," he says, "it will take you through the whole process."
