Hiring a firmware and Bluetooth app developer
One role or two, what a generic iOS developer will miss, and the screening questions that separate people who have shipped BLE hardware from people who have read about it.
Shailendra Kumar Ram
The listings for this role usually ask for one person who can write embedded C, design a GATT service, build a native iOS app and build the Android one too. Those people exist. There are not many of them, and the ones who are any good are rarely looking. So the first decision is whether you actually need one person or two, and getting that wrong is the most expensive mistake available at this stage.
One role or two
Firmware and companion app are different disciplines that happen to share a protocol. Firmware work is memory budgets, power states, interrupt timing and a debugger attached to a board. App work is platform frameworks, background execution rules, store review and a design system. The overlap is the characteristic layout and roughly a week of shared vocabulary.
Hire one person for both when the device is simple, the team is small and the same person can hold the whole protocol in their head. That is genuinely more efficient at the prototype stage, because the expensive coordination problem disappears.
Hire separately once the device has a roadmap. A generalist who is adequate at both will be slower on each than a specialist, and the firmware side is where the risk concentrates as the product matures. What you want in that case is an app developer who can read firmware and argue with the firmware engineer competently, not one who writes it.
What a generic iOS developer will miss
A strong mobile engineer with no Bluetooth history will build you something that works on their desk and fails in the field. The gaps are consistent enough to list.
- They will assume they can test in the simulator. CoreBluetooth is not available there, so either the test plan is wrong or there is no test plan.
- They will treat a dropped connection as an error state rather than the normal condition it is. Bluetooth connections drop constantly. The app's job is to make that invisible.
- They will miss background execution entirely until someone locks their phone during a demo.
- They will identify devices by an address that iOS does not expose. The identifier CoreBluetooth hands you is specific to that one iPhone and changes over time. Firmware or app logic built on a stable hardware address works on Android and fails on iOS every time.
- They will not have a device matrix, because in normal app work you do not need one.
None of these are exotic. They are the first five things you learn shipping this kind of product, which is exactly why they make good screening material.
Screening questions that work
Ask these in a call rather than in writing. You are listening for whether the answer arrives from memory or from reasoning.
How do you develop against hardware that is not built yet? You want to hear about a mock peripheral, a spare development board flashed with a stub service, or a phone acting as a peripheral. Anyone who has done this has a habit here.
What happens when the user turns Bluetooth off and back on while your app is open? The right answer covers the central manager reporting its state asynchronously, everything queued before that being discarded, and the need to rebuild from the state callback rather than retrying blindly. A vague answer means they have not lived through it.
Walk me through what happens when the app is killed while connected. This is the state restoration question. On iOS the system can relaunch your app into the background on a Bluetooth event, and the restoration callback runs before your normal startup. People who have shipped background Bluetooth apps get animated about this. People who have not will say the app just reconnects on next launch.
Which Android manufacturers have given you trouble? Any real answer names Samsung, and usually a second one. The specific complaint matters less than whether they have one.
How would you handle a firmware update over the air? Listen for whether they mention what happens when the update is interrupted halfway. A candidate who describes the happy path only has not shipped one.
How do you decide chunk size when writing a large payload? The answer involves the negotiated MTU rather than a fixed number, and ideally mentions that writing without waiting for a response is much faster but needs its own acknowledgement scheme. This one sorts senior from mid quickly.
What the rates mean
Specialist marketplaces list CoreBluetooth developers around sixty to a hundred dollars an hour and up. Across US freelance mobile work generally, the median senior rate sits near a hundred and forty-five, with genuine specialists well above that. The open marketplaces will show you people at ten dollars an hour.
The spread is not really about skill level, it is about who is bidding. Experienced Bluetooth people tend to avoid the large bidding platforms, because the work is hard to evaluate from a listing and the auction rewards whoever is most optimistic rather than whoever is most accurate. That is worth knowing before you conclude that the cheap end of the market is a bargain.
The real cost comparison is not hourly rate. It is how many weeks the project runs. Somebody at a hundred and forty an hour who has debugged a Samsung MTU timing problem before will finish that problem in an afternoon. Somebody at forty will find it eventually, and you pay for the search.
Red flags
- A quote produced without asking to see your characteristic layout or firmware spec. Nothing was estimated.
- A portfolio of Bluetooth apps with no mention of what the hardware was. Connecting to a commercial fitness tracker with a published profile is a different job from bringing up a custom board.
- Enthusiasm for a cross-platform framework as the first technical opinion. It can be the right call, but on Bluetooth-heavy work the usual advice is to write the radio layer natively regardless of what the interface is built in.
- No questions back about your device. Anyone who has done this wants to know the chip, the power budget and whether the firmware team is in-house.
Structure the first engagement small
Do not hire for the whole build on the strength of a call. A paid piece of scoped work first, one to two weeks, tells you more than any interview. Good candidates prefer it too, because it lets them price the real project honestly instead of guessing.
The most useful version of that first piece is a protocol review and a connection prototype: they read your firmware spec, build the scan, connect and subscribe path against your real hardware, and come back with a written list of what will be difficult. You end up with working code, a real estimate, and a clear read on whether you want to keep working with this person.
A two-week paid trial costs less than the third month of a bad six-month engagement.
If you are at that stage and want the protocol review done, or a second opinion on a candidate you are already talking to, get in touch and we can work out which of those you actually need.