App Developers in Boston, Sorting a Health App One Feature at a Time

Updated November 2026 · Written and maintained by the Progression Agency strategy team

A reminder button that nudges a patient to take a pill is one kind of software at the FDA. Put a number behind it that tells a clinician what dose to give, and it can be a different kind. App developers in Boston work in a state with some 375 digital health companies by MeHI’s count, and the question comes up in the first week of nearly every project here. This page sorts one app’s feature list into the agency’s three buckets, then says what building it costs. Progression is based in New York, builds for Boston companies remotely, and offers on-site sessions on request.

If your Boston app has nothing to do with health, drop the FDA and keep the method: write the feature list first, then ask which feature changes the rules. Our app development agency page covers the rest of the work.

One button, three possible answers

Picture one screen in an app that does not exist. Illustrative example. It has a button and a time, and it comes in three versions. The first reminds the user to take a pill at eight. The second adds a log of what was taken. The third calculates a number that a clinician uses to choose a dose.

The first two versions resemble software the FDA names in its own examples. The third is not on those lists, and a feature like it is a question to put to counsel and to the FDA before any code is written.

Why does the same screen get different answers?

Because the agency looks at what a function does and not at how the screen looks. A reminder and a dose calculator can share a button and still be different kinds of software.

What app developers in Boston sort first

The Massachusetts eHealth Institute says on its Why Massachusetts page that the state is home to approximately 375 digital health companies and 79 hospitals. Those are MeHI’s figures. They explain why a Boston app team meets the FDA question early.

The FDA’s page on device software functions says its policies are independent of the platform, are function specific and apply across platforms. It sorts software into three categories: software that is not a medical device, software that is a device but for which the agency intends to exercise enforcement discretion, and software that is a device and the focus of its oversight. Function specific means feature by feature.

• Some features are not devices at all.
• Some features are devices that the FDA says it intends not to actively enforce against.
• Some features are the focus of FDA oversight.
• A single app can contain features from all three categories.

Who decides which bucket a feature belongs in?

Counsel and regulatory staff, with the FDA when the question is close. The app developer’s job is to write the feature list clearly enough that they can answer.

The triage sheet

Below is a sheet for eight hypothetical features. Each row names the feature, what the FDA’s own examples say about its kind, the bucket the examples suggest, and what the build needs. The last column is the same on every row: ask counsel.

Features that stay out of device territory

The FDA’s list of examples that are not medical devices includes medical dictionaries, electronic copies of textbooks, interactive anatomy diagrams and quiz apps, software that is not intended for diagnosis or treatment of a specific patient. A feature like these builds like any other content app.

Features the agency says it will not actively chase

Enforcement discretion is the middle bucket. The FDA’s examples for enforcement discretion include software that provides reminders or motivational guidance to pregnant people, smokers trying to quit or people recovering from addiction, and software that keeps track of medications and provides user-configured reminders. Enforcement discretion does not mean the rules do not apply. It describes what the agency says it intends to enforce, and counsel can say what it means for your product.

Features that turn a phone into a device

The FDA’s examples of device software functions it regulates include software that uses a sensor or lead connected to a mobile platform to measure and display the electrical signal of the heart, and software that uses a built-in speaker to produce controlled test tones for diagnosing hearing problems. A feature in this category changes the plan for the whole app.

What each category does to the build

The category does not change how an app looks. It changes the work around it, and that work is where the schedule moves.

• Ask which category before the design sprint starts.
• Write the answer next to the feature, with the date.
• Revisit the answer whenever the feature changes.
• Keep the note from counsel with the brief.

Does the category change the price?

It can. The build price follows the roles, integrations and admin tools, and a feature in the oversight category usually adds work around testing and records that counsel scopes.

What the screen says to the user

The FDA looks at what a function does, and what the screen tells the user is part of that. A line of copy can change a feature from a reminder to advice.

• Read every sentence on the screen as a claim.
• Avoid numbers the app calculates unless counsel has cleared them.
• Avoid telling a user what a result means unless the feature is meant to.
• Show the same wording in the app store listing and the website.
• Keep a list of every message the app can send.

Who writes the copy on the screen?

The product owner, with counsel reviewing anything that touches health advice.

Boston app development: what the triage does to the budget

The triage changes the budget by changing what is built. A content app, a reminder app and a sensor app are three different projects, even when the screens look alike. Regulatory work has no band on this page, and counsel and the FDA decide what it involves.

A Boston app development company prices the build the way any app is priced: by roles, integrations and admin tools. The table shows the market spread, and Progression quotes after a written scope.

Which row does a health app usually fall in?

A content app with accounts is near the simple row. A reminder app with an admin side and integrations is mid-complexity. An app with a feature in the oversight category is often the complex row, because of the testing and records around it.

For timelines and what drives cost, see our app development cost guide.

When a single feature moves the whole app

One feature in the third category can change testing, records and release plans for everything around it. That is why the triage comes before the design.

If the sheet puts a feature in the oversight category, the next step is a conversation with counsel and a look at the agency’s guidance. Our medical device software development page covers the device software life cycle, and this page does not repeat it.

• Move the feature to a later release, if the first release can work without it.
• Split the feature into a simpler version and a later one.
• Plan the whole app around the feature, with counsel at the table.
• Keep the feature list current, since each new idea gets its own row.

Can an app launch without the risky feature?

Often yes. A first release with the content and reminder features can ship while the question about the third feature is answered.

The hospitals on the other side of the contract

MeHI says the state has 79 hospitals. A hospital that buys or pilots an app asks its own questions, and its security reviewer asks different ones than the FDA does.

Keep the feature sheet as the common language. The hospital reads the same list and asks where the data goes and who can see it. The answers go on the brief, next to the features they relate to.

• List which systems receive data from the app.
• Name who at the company answers a hospital’s questionnaire.
• Keep the feature sheet and the data list together.
• Update both when a feature changes.

Does the feature sheet replace a security review?

No. It makes a review faster, because the reviewer sees what the app does before asking what it stores.

The question to send the FDA early

The FDA encourages software developers to email the agency as early as possible if they have questions about their software, its level of risk and whether a premarket application is required.

A Boston app developer can draft the feature description, since it is a plain account of what the app does. An app developer in Boston cannot answer the regulatory question itself, so counsel reviews and signs the email.

• Describe each feature in one or two sentences.
• Say who the user is and what the app tells them.
• Say whether a clinician acts on anything the app shows.
• Ask the question you actually need answered.
• Keep the reply with the brief.

Boston app developers who keep that email in the file find it useful long after launch, because the next release starts from it.

What goes in the first sentence of the email?

What the app does, in words a person outside the company would understand. Leave marketing language out.

A brief for a Boston health app

Copy the card below into the brief. Each line has an owner and each line is a decision.

With the six lines filled in, the feature sheet and the build plan can start together. Our app development agency page covers how builds run, and our software development company page covers larger systems. Claims in health marketing have their own page, marketing agency in Boston.

Who fills in the brief?

The product owner, with a regulatory contact if the company has one. If it does not, counsel.

Related services and guides

Pages that sit beside this one:

• App development agency
• Medical device software development
• Software development company
• App development cost

Frequently asked questions