Mobile app development in Boston
Boston's clinical-stage companies and digital health teams increasingly put an app in the patient's hand: a daily symptom diary, a medication reminder, a questionnaire that feeds a trial's endpoints. The app is simple on screen and difficult underneath. Entries must carry the time the patient made them, not the time the phone found a signal. Nothing can be lost, silently edited or duplicated, and a patient on an old phone running an old version still has to produce clean data.
We build these in React Native for both stores. Entries are saved on the device first and synced with their original timestamps, every change is kept in a history nobody can edit, and the backend refuses writes from app versions that are no longer supported, with a clear prompt to update. Reminders arrive on time without draining the battery, and screens are tested on the older phones and larger text sizes patients actually use. The data that reaches the study team is complete, timestamped and ready to analyse.
Boston's software buyers mostly work in science, medicine, education and money: biotech and pharmaceutical companies in Cambridge and the Seaport, the hospital systems, digital health start-ups, the universities and the companies spun out of them, and the asset managers and insurers downtown. In most of them, software supports something else, an experiment, a patient or a portfolio. The people who commission it are often scientists and clinicians, many of whom write some code themselves and know exactly what they need the data to do. What they want from an engineer is not a new idea. It is the idea they already have, made reliable.
The work follows the science. Biotech labs need instrument output picked up as it lands and linked to the notebook entry that explains it, and internal tools that stay fast on thousands of assay results. Digital health companies need a backend that can read from a hospital's records system, and patient apps that save offline and keep the time each entry was made. Edtech companies selling to universities need platforms that know a teaching assistant from a department administrator. Lab suppliers need commerce that runs on purchase orders and negotiated prices, and the investment firms downtown need internal tools to replace the workbooks that run their operations.
Hiring has its own shape. Built In puts the average software engineer base salary in Boston at about $137,000, and the city's engineers are pulled between big tech offices, well-funded biotech and university spin-outs. The universities keep research talent in good supply. What teams more often lack is someone who has taken a system from a notebook or a prototype to something that runs unattended, is monitored, and survives its author going back to the lab. That gap, between a result that works once and a system that keeps working, is where we are most useful.
We are in Bengaluru and move our working day for Boston. Four hours of every working day overlap with your morning in Eastern time, stand-up included, so questions, reviews and decisions happen live with the engineer who writes the code. Runbooks and architecture notes are written as we go, so the system keeps running when the people who commissioned it go back to the lab.
We are the right fit for the gap between a result that works once and a system that keeps working: a pipeline, a hospital integration, a patient app, an internal tool. Senior capacity starts within days, the first piece is a fixed-price two-week engagement, and it can carry you from a funding round or grant to your first engineering hire.
Four ways this arrives.
And crashes on the ones your users own. We add crash reporting with readable stack traces, find the handful of devices and OS versions causing most of the crashes, and fix those before anyone touches a feature.
Signing keys on a laptop, a manual build, store notes written at midnight. We move builds and signing into CI, add over-the-air updates for JavaScript-only fixes, and write down exactly how a release goes out.
A Bluetooth device, a vendor SDK, a camera pipeline, a background task the OS keeps killing. We write the native module in Swift and Kotlin, expose a small typed interface to React Native, and keep it isolated so upgrades stay possible.
Forms that vanish, actions that send twice. We decide what must work offline, keep it on the device, queue writes with idempotency keys the backend understands, and show the user plainly what is still waiting to sync.
Our own React Native app on Android, with retraction built into the client because moderation can pull a message after it has been sent.
Read the write-up →Asked by Boston teams.
How do you work with teams in Boston?+
We are in Bengaluru and move our working day for Boston, so four hours of every working day overlap with your morning in Eastern time, stand-up included. We join your Slack, push to your GitHub and track the work in your Linear, so progress shows up where your team already looks. The person on every call is the engineer who writes the code, whether you are a scientist, a clinician or a CTO.
Do you build for Boston's biotech and life sciences companies?+
Yes. The work is usually the software around the science: pipelines that pick up plate reader, sequencer and imaging output as it lands and link it to the notebook entry, internal tools that stay fast on thousands of assay results, and search over protocols and SOPs that always cites the current version. We work alongside your computational scientists, turning what already works in their notebooks into systems that run unattended.
How does your rate compare to hiring in Boston?+
Built In puts the average software engineer base salary in Boston at about $137,000, before bonus and benefits. Our published rate is $35/hour, or $5,400 a month for an embedded engineer, with a $5,000 minimum. There is no recruiting time and no employment overhead, and work starts within days of the call. The first piece is a fixed-price two-week engagement at $2,800, so you judge us on what it produces.
What do the first two weeks look like?+
You share the context: the code, the data and the problem. Within two days you have a 30-minute call with the engineer who would do the work, and within a week a written plan. Then comes a fixed-price two-week piece at $2,800, such as turning one notebook or prototype into something that runs on its own. At the end you have working code in your repository, notes on how it runs, and a clear view of what comes next.
React Native or fully native?+
React Native for most products: one codebase, one team, both stores. Fully native makes sense when the app is mostly the hard native part, such as heavy camera or audio processing, complex background work, or a platform feature React Native does not support yet. We will tell you which side of that line you are on, and write the native parts by hand either way.
Expo or bare React Native?+
Expo, in almost every case now. Development builds and config plugins removed most of the old reasons to eject, and EAS handles builds and signing. We go bare only when a native dependency genuinely cannot live inside a config plugin, and we will explain why before doing it, because it makes every future upgrade more work.
Can you take over an app someone else built?+
Yes. We start by getting it to build on a clean machine, which is often the hardest step, then bring React Native and its dependencies up to a supported version before adding features. We tell you what state the app is in, including where the store listings, signing keys and accounts actually live, before quoting anything larger.
Who handles App Store and Play Store submission?+
We do, from your developer accounts, not ours. We prepare the builds, the privacy disclosures and the notes for the reviewer, and deal with rejections when they come. The accounts, signing keys and listings stay in your name, so you can change developers later without asking anyone's permission.
Does our backend need to change for a mobile app?+
Often, a little. A mobile client stays on old versions for months, retries on bad networks, and cannot be fixed by a server deploy. That means versioned endpoints, idempotent writes, and a way to tell an old client it must update. We check the backend for those before the first screen is built, because retrofitting them after launch is slower.