You have a device. It needs an app. The obvious move is to hire an app developer — there are thousands of them, they are easy to find, and their portfolios look great. Then the first build arrives, the app cannot hold a Bluetooth connection for more than four minutes, and nobody can say whether the fault is in the firmware or the phone. Two teams start emailing each other. Six weeks disappear.
This is the most common and most expensive failure in connected product development, and it is almost never caused by bad developers. It is caused by putting the hardware and the software under separate roofs without deciding who owns the seam between them. Choosing who builds your companion app is really a question about that seam.
First: does the app belong in version one at all?
Before choosing a vendor, be sure the app is genuinely required. An app adds a permanent cost line — store compliance, operating system updates twice a year, new phone models, and a support channel that never closes. Plenty of products get to market faster with physical controls and a web page, and add the app in the second release once real customers have said what they want it to do. Does your product really need a companion app is worth resolving honestly before anyone quotes on one.
If the answer is yes, the second question is what the app is for. An app that only configures a device at setup is a fundamentally different project from one that streams live sensor data, or one that is the entire user interface. The scope drives the choice of who builds it more than any other factor.
The four options, honestly compared
| Option | Typical rate | Strength | Risk |
|---|---|---|---|
| Mobile app agency | $90–$200/hr | Polished UI, store process, design depth | Often no hardware experience; treats the device as an API that works |
| Product development firm with app team | $100–$220/hr | Owns the hardware-firmware-app boundary end to end | Fewer of them; may be less design-led than a pure agency |
| Freelancer or small pair | $60–$150/hr | Cheap, fast, direct communication | Bus factor of one; support after launch is uncertain |
| In-house hire | Salary plus overhead | Long-term ownership, deep product knowledge | Hard to hire, expensive to keep busy on one app, slow to start |
| Offshore team | $25–$70/hr | Lowest hourly cost | Time zones, BLE debugging without the device in hand, spec dependency |
The rate column is the least important one. A cheaper team that cannot debug a Bluetooth connection problem will consume more calendar time and more of your firmware engineer's attention than a more expensive team that has done it before. Total cost drivers are covered in what actually drives mobile app development cost, and hardware companion apps sit at the harder end of that range for reasons that have nothing to do with screens.
Why hardware apps are different
A conventional mobile app talks to a server that is available, documented, and behaves the same way every time. A companion app talks to a physical object that may be out of range, asleep, low on battery, running old firmware, or already connected to somebody else's phone. Almost everything hard about the project lives in that difference:
- Connection lifecycle. Scanning, pairing, bonding, reconnecting, and handling the user who walks away mid-operation. This is most of the app's real complexity and none of its visible surface.
- Platform behavior differences. iOS and Android handle Bluetooth permissions, background execution, and bonding very differently, and Android varies further between manufacturers. Experience here cannot be bluffed.
- Firmware versions in the field. Within a year you will have several firmware revisions live, and the app has to work with all of them.
- Debugging across the boundary. When data arrives corrupted, someone has to determine whether firmware sent it wrong or the app parsed it wrong. That requires access to both sides.
A team that has only built apps against web services will meet all of this for the first time on your budget. Ask candidates how many shipped Bluetooth products they have worked on, and ask them to describe a reconnection bug they solved. The answers separate the field quickly.
The interface contract decides who you can hire
Here is the leverage point. If the boundary between device and app is properly specified — every characteristic, every command, every value, every unit, every error code, every state transition, written down and versioned — then a competent app team can work against it without needing to understand your firmware. If it is not specified, no split arrangement will work, regardless of who you hire.
That document is the deliverable that makes multi-vendor development possible, and it is described in the interface contract between hardware and software. Write it before the app work starts, keep it under version control, and require both sides to update it before changing behavior. Products that do this can hire an app agency safely. Products that do not should keep everything under one roof, which is the case made in developing a product that combines hardware, firmware, and software.
A decision rule
- Simple configuration app, mature firmware, written interface spec. A good app agency or a strong freelancer is fine, and often the best value.
- App and firmware being developed at the same time. One team should own both, or one firm should own the integration. Concurrent development across two vendors is where schedules go to die.
- The app is the product's primary interface. Hire for design strength as well as connectivity, and expect the app to be the larger half of the budget.
- Regulated product. Medical, safety, or anything with claims attached needs a vendor with a documented process, traceability, and a quality system — not the cheapest quote.
- You will have an ongoing product line. Building the capability in-house starts to make sense after the second or third product, not the first.
Contract terms that matter more than the rate
Whoever you choose, four clauses determine whether you actually own what you paid for.
- IP assignment. Work-for-hire language does not automatically transfer copyright for independent contractors in the US; you need an explicit written assignment. Read who owns the IP a contractor creates for you before signing anything.
- Repository and account ownership. The code lives in your organization's repository from day one. The Apple and Google developer accounts are registered to your company, not the agency's. Signing certificates and keys are yours. This sounds pedantic until the relationship ends badly.
- Third-party components. Get a written list of every library and its license. A copyleft library in a shipped app is a genuine legal problem discovered at the worst possible time.
- Handover and maintenance. Documentation, build instructions that work on a clean machine, and an agreed rate for post-launch work. Somebody has to handle the operating system release that lands nine months after launch.
The bill that arrives after launch
Founders budget for the build and forget the rest. Both platforms ship a major operating system version every year, deprecate APIs, and tighten store requirements; an unattended app eventually breaks or gets removed. Plan on ongoing spend in the range of 15 to 25 percent of the original build cost per year just to keep it functioning, before any new features — the breakdown is in app maintenance costs after launch. Whoever builds the app should either commit to that work or hand over a codebase clean enough for someone else to take it on.
Projects House develops connected products with the device, the firmware, and the app treated as one system and one point of accountability — which means nobody gets to say the problem is on the other side. If you are deciding how to get your product's app built, describe the product through the contact form.