Who you are hiring, how milestone payments work, who owns the code, and how a project runs across time zones. The questions worth settling before a call.
Hiring a development team on the other side of the world means trusting people you have not met with your product, your budget and your idea. Most of that trust is won or lost before anyone gets on a call, so the things you would otherwise have to ask about are written down here instead.
I am Shailendra Kumar Ram. I lead the work and I write the Bluetooth and iOS code myself, which is the part most projects live or die on. Behind that sits a small team I have worked with for years: native Android, Python backends, product design and QA automation.
That means you get direct access to the person building the difficult part, without the project stalling the moment it needs an Android build or an API. You are not routed through an account manager, and you are not relying on one person to cover five disciplines badly. When you email, I answer.
Six years of that work has been iOS apps talking to hardware over Bluetooth Low Energy, including production work on Tuya and TTLock smart locks and the Barsys robotic bartender. The writing on this site is the same material, in public.
Work is split into milestones with a defined deliverable, and you pay for the next milestone rather than the whole project up front. Each one ends in something you can run, not a status report.
| Stage | What happens | What you pay |
|---|---|---|
| Agreement | Scope, milestones and deliverables written down | Nothing |
| Milestone starts | Work begins on the agreed deliverable | That milestone |
| Demo | A working build you can install and try | Nothing |
| Approval | You accept, or we fix it first | Nothing |
| Next milestone | Repeat until launch | The next one |
Invoices are international and issued as an export of services, which is routine. If your finance team needs specific documentation or a particular payment rail, ask early; it is easier to set up before the first invoice than to change after it.
On payment for a milestone, the work product from it is yours. That is written into the contract rather than implied by the invoice, because the difference matters if anything is ever disputed.
I sign NDAs and I am happy to work under yours. Your product, business information, firmware specification and source code are treated as confidential by default, whether or not a document has been signed yet.
On hardware projects the firmware specification is usually the genuinely sensitive part rather than the app, so make sure whatever you send covers it.
I am in Gurugram, India, at UTC+5:30. The approach is async-first with scheduled overlap, not a daily call at an unreasonable hour for one of us. On a hardware project the blocking questions are firmware questions, and the teams that move fastest are the ones that answer them in writing rather than in meetings.
| Your region | Live overlap | Your local time |
|---|---|---|
| UK and Europe | Weekday afternoons | 8:30am to 1:30pm |
| US East and Central | Weekday mornings | 9:00am to 1:00pm |
| US West | Early mornings, Tue and Thu | 9:00am to 10:00am |
| Australia and Asia | Afternoons, Tue and Thu | 2:00pm to 5:00pm |
What carries the project between those windows is written material: a protocol document that is the single source of truth for the GATT table, packet captures instead of prose descriptions, and one named person on your side who owns firmware questions. I go into why in hiring a freelance CoreBluetooth developer in India.
The most common complaint about remote development is silence. The defence against it is a rhythm you can predict:
Requirements are documented before development starts, and each milestone has a defined deliverable. New features are quoted separately and start only when you approve them, so the number you agreed is the number you pay unless you decide otherwise.
On hardware projects one thing does move on its own: firmware. When the characteristic layout changes underneath the app, work already tested has to be redone. That is normal and it is priced honestly as churn rather than discovered as an overrun. What a Bluetooth build actually costs shows how I estimate it.
There is no Bluetooth radio in the iOS Simulator, so BLE code that has not been run against real hardware has not been tested at all. The lab here covers a current iPhone and the one before it, a Pixel, a Samsung Galaxy and a budget Android with different Bluetooth silicon, because the same call behaves differently on each.
Submission is part of the job rather than a handover. That covers certificates and signing, the privacy and data disclosures, background mode declarations, which reliably invite reviewer questions on Bluetooth apps, and the release itself.
After launch there are two ways to continue, and you can take neither:
Projects are priced on scope, not on a rate card, and you get a proposal broken into milestones after a conversation about what you are building. A Bluetooth companion app for a single peripheral typically lands in the tens of thousands of dollars rather than the thousands, and the drivers are background operation, how many Android models you support and whether firmware updates over the air are in version one.
Rather than hide that reasoning, it is published: how to estimate a Bluetooth app build works through it hour by hour, and what a CoreBluetooth developer costs covers rates by market. If a quote you have from someone else looks wrong against those, that is worth a conversation on its own.
Yes, and most of the work is with teams in the US, UK, Europe and Australia. The process on this page is built around that rather than adapted to it.
Milestone by milestone. You pay for the next piece of work rather than the whole project up front, and each milestone ends in a build you can install. Currency and payment method are agreed before the first invoice.
Yes, yours or mine. On hardware projects make sure it covers the firmware specification, which is usually the genuinely confidential part.
You do, assigned under the contract on payment. Your Apple and Google accounts stay registered to your company, and you have repository access from the first commit.
Async-first with scheduled overlap. There is a live window with every major region, listed above, and written artefacts carry the project between them. A protocol document and a packet capture are worth more than extra hours on a call.
New features are quoted separately and start when you approve them. Firmware churn is the one thing that moves on its own, and it is priced in from the start rather than presented as an overrun later.
Yes, either as a defined launch support window or as an ongoing monthly arrangement. Neither is compulsory, and both are agreed before launch rather than negotiated during a crisis.
Often, yes. It starts with a paid review of the code and the protocol document so you get an honest assessment of what is salvageable before anyone commits to a rewrite.
Yes, and it is common. The team here covers backend, Android, design and QA where you need them, and stays out of the way where you already have people.