A practical guide to your next project

How I work

Clear milestones, regular updates and direct collaboration across time zones. I work primarily with overseas teams, and with clients in India too.

Start a conversation See my availability

The short version

What you can count on.

Six essentials. Pick any one to take a closer look.

Go a little deeper

Your project,
step by step.

Open the topics that matter to you. Everything else can wait.

Who you work with

Direct access to me, with an experienced team around the project.

I am Shailendra Kumar Ram. I lead your project and write the iOS and Bluetooth code, with a small team covering the other disciplines.

I write this myself

  • iOS and Swift, all of it
  • CoreBluetooth: scanning, pairing, GATT, background modes
  • Firmware update flows over the air
  • Architecture, and the App Store submission at the end

My established team

  • Native Android, Kotlin and Jetpack Compose
  • Python backends: Django, DRF, FastAPI, AWS
  • Product and interface design
  • QA automation and release testing

You work directly with the people building your product. We bring in Android, backend, design and QA expertise where your project needs it.

My production work includes Tuya and TTLock smart locks and the Barsys robotic bartender. Explore the technical writing for a closer look at how I solve these problems.

How payments work

A working build and a clear approval at every milestone.

We agree a deliverable for each milestone. You fund that milestone, review a working build, and approve it before the next one begins.

  1. Agreement

    Scope, milestones and deliverables written down

    No payment

  2. Milestone starts

    Work begins on the agreed deliverable

    Pay: that milestone

  3. Demo

    A working build you install and try yourself

    No payment

  4. Approval

    You accept it, or it gets fixed first

    No payment

  5. Next milestone

    Repeat until launch

    Pay: the next one

Milestones usually run for two to three weeks, depending on the project. We agree currency, payment method and invoicing requirements before the first invoice, whether you are based overseas or in India.

What you own

Your source code, store accounts and repository.

The contract assigns each milestone’s work to you on payment. Your accounts, repository and documentation stay under your control.

The source code

Assigned to you under the agreement when the milestone is paid, not implied by an invoice.

Your Apple and Google accounts

Registered to your company, and I work inside them. You can never be locked out of your own listing.

The repository, from day one

On your organisation where you have one, so you watch the commits arrive instead of waiting for a handover.

Documentation

Architecture, build and release, written so another developer can pick the project up without me.

Third-party libraries and services retain their own licences. We review those at the start.

Confidentiality

Your product and technical information stay confidential.

I can sign your NDA or provide one. Your product, business information, firmware specification and source code are treated as confidential from the start.

Find a time to talk

Three fixed IST windows, with times for your region.

Choose the window for your region below. For clients in India, all three windows are shown in IST. Written updates keep work moving between calls.

AAsia-Pacific

India (IST)

9:30 AM – 12:30 PM

Your local time · standard time

Australia (AEST)
2:00 PM – 5:00 PM
Singapore & Hong Kong
12:00 PM – 3:00 PM
Japan
1:00 PM – 4:00 PM

BEurope & Middle East

India (IST)

2:00 PM – 6:00 PM

Your local time · standard time

UK (GMT)
8:30 AM – 12:30 PM
Germany, France & Netherlands (CET)
9:30 AM – 1:30 PM
UAE / Gulf Standard Time (UTC+4)
12:30 PM – 4:30 PM

CAmericas

India (IST)

7:30 PM – 10:30 PM

Your local time · standard time

US East (EST)
9:00 AM – 12:00 PM
US Central (CST)
8:00 AM – 11:00 AM
UK (GMT), afternoon overlap
2:00 PM – 5:00 PM
Central Europe (CET), afternoon overlap
3:00 PM – 6:00 PM
IST is UTC+5:30 and does not observe daylight saving. The local times above use standard time; where daylight saving applies, they are one hour later. My IST windows stay fixed. Check the booking calendar for available dates and times in your timezone.

Between calls, three things help us resolve hardware questions quickly:

  • A protocol document that is the single source of truth for the GATT table.
  • Packet captures instead of prose descriptions of what the device did.
  • One named person on your side who owns firmware questions and can answer them without a meeting.

I go into why in hiring a freelance CoreBluetooth developer in India.

Stay close to the progress

Weekly updates, visible commits and regular builds.

You know what has shipped, what is next and what needs your input. Updates follow a predictable rhythm.

Every week

A written update

What moved, what did not, and what is blocked. Whether or not there is good news in it.

Every milestone

An installable build

On TestFlight for iOS, so your team is using the real thing rather than reading about it.

Continuously

Commits you can see

In your repository as they happen, rather than one delivery at the end of the project.

On the calendar

A call for decisions

Demos and reviews in a booked window, in one shared channel on Slack, Teams or email, whichever you already use.

When the scope changes

An agreed scope, with changes approved before work begins.

Requirements are documented before development starts, and each milestone has a defined deliverable. The number you agreed is the number you pay unless you decide otherwise.

Fixed once we agree

  • The scope, written down before development starts
  • The deliverable at the end of each milestone
  • The price of the work inside that scope

Quoted separately, and only with your approval

  • New features you decide you want along the way
  • A platform added after the project has started
  • Firmware churn, when the characteristic layout changes underneath the app

Firmware changes can require app work to be repeated. We account for that in the estimate. See how I estimate a Bluetooth build.

Tested on real hardware

Real devices, protocol tests and builds your team can try.

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 it runs against

  • iPhone, current generation
  • iPhone, one generation back
  • Google Pixel
  • Samsung Galaxy
  • Budget Android, different Bluetooth silicon

The same call behaves differently on each of those, which is exactly why they are all here. On top of the hardware:

  • Automated tests where they are worth having, around protocol encoding and state handling.
  • Manual testing on real devices, against your real peripheral rather than a mock.
  • TestFlight builds for your team to try before anything is submitted.
  • Crash reporting and analytics wired up before launch, not after the first bad review.

Launch, handover and support

Store submission is included; ongoing support is optional.

Submission is part of the job rather than a handover: certificates and signing, the privacy and data disclosures, background mode declarations, and the release itself.

At launch

Submission handled

Including the background mode declarations, which reliably invite reviewer questions on Bluetooth apps and are the usual reason a first submission bounces.

Optional

Launch support

A defined window for bug fixes, store updates and watching crash reports while the first real users arrive.

Optional

Ongoing development

A monthly arrangement for new features and iOS releases. Every September iOS ships and something in CoreBluetooth behaves differently.

Launch support and ongoing development are optional. We agree either arrangement before release.

What it costs

A proposal based on your scope, with the assumptions spelled out.

Your quote reflects the scope, platforms, hardware integration and testing your project needs. We agree the currency and milestone costs in the proposal.

Background operation

An app that must stay connected while backgrounded is a different piece of engineering from one that works while open.

Android coverage

How many Android models you support, because BLE behaviour varies by manufacturer far more than iOS does.

Firmware updates over the air

Whether OTA is in version one, which is the single largest swing in a hardware companion app estimate.

For a closer look, read how I estimate a Bluetooth build and developer rates by market.

After our first conversation, you receive a milestone proposal with clear assumptions to review.

A few more things

Already have a project?

We can start from where you are.

Do you work with overseas clients and clients in India?

Yes. My main focus is overseas teams, and I also work with founders and businesses in India. We agree call times, currency and billing details before work starts.

Can you take over an existing application?

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.

Can you work with our existing backend or design team?

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.

Your next step

Tell me what
you are building.

A first conversation is enough to find out whether we are a good fit.

Send project details
  1. 1

    You send the details

    Share what you are building, where it stands and what you need next. A datasheet is welcome, but optional.

  2. 2

    You get an honest read

    Usually within one business day, I will tell you whether it is a fit and flag the main questions.

  3. 3

    A call, then a milestone plan

    We talk for 30 minutes, then outline the scope and milestones. If it is not a fit, I will say so.