Swasthya Sarathi
A healthcare-companion platform for Swasthya Sarathi
A website and mobile app development project for a multi-service healthcare companion — It helps peo...
Read itiOS, Android and cross-platform
Flutter, React Native and native apps that keep working offline, on old phones and on a metro platform with one bar of signal. We put them in both stores, with a release pipeline that you own.
Last updated
An app is not a website in a frame. It is software that has to work on a five-year-old Redmi with 3GB of RAM. It has to work on the Delhi Metro, where the network drops between Rajiv Chowk and Barakhamba. And the user decides in about eight seconds whether to keep it or delete it.
We build mobile products for teams who have a real reason to be on the home screen. Examples are a delivery fleet that works offline, field-service work with a camera and a signature, a members app where push is the main channel, and a fintech flow that has to pass an RBI audit. If your users would be just as happy with a good mobile site, we will tell you so. That saves you a year of app-store upkeep.
Cross-platform by default, native when the hardware needs it. Flutter and React Native cover most of what people ask us for. They do it with one codebase, one release flow and one set of tests. Sometimes you need Bluetooth Low Energy, an SDK that only comes for iOS, background location that has to survive Doze mode, or 120fps drawing. Then we write native modules, or the whole app in Swift and Kotlin. We tell you so before you sign.
| Flutter | React Native | Native (Swift / Kotlin) | |
|---|---|---|---|
| One codebase, both stores | Yes | Yes | No |
| Performance on 3GB Android | Excellent | Good | Excellent |
| Custom, brand-heavy interfaces | Excellent | Good | Excellent |
| Shares code with a React web app | No | Yes | No |
| Deep hardware and BLE work | Via native modules | Via native modules | Native |
| Hiring pool in India | Large and growing | Very large | Smaller, pricier |
| Typical cost vs native | ~60% | ~65% | Baseline |
Almost every rescue job we take fails in one of these six places. You cannot see any of them in a Figma file.
The delivery partner walks into a basement and the app shows a spinner until the OS shuts it down. Twenty minutes of proof-of-delivery photos are gone.
Every SDK the marketing team ever asked for starts on the main thread before the first screen shows. Users delete the app before they see your logo.
Nobody set up Crashlytics or Sentry, so no one can see the crashes. Your Play Store rating is dropping and no one can say why.
UPI intent returns to the app with no reply, the order is charged but never confirmed, and support matches refunds by hand every morning.
The old agency has the signing key. You cannot send an update for your own Android app unless they agree.
No plan for topics, no token refresh, and OEM battery savers shutting the service down. Your only way to bring users back is leaking.
You are in a TestFlight build by week six. Not staring at a Gantt chart.
We map the main job of the app, the phones it must work on, and the network it will really have. We choose Flutter, React Native or native, and we write down why, including what we give up. You get a scope, a list of test devices and a price.
We follow the normal rules of each phone, not a web layout squeezed into a phone. That covers gestures, screen changes, offline and error screens, and the screens that explain permissions. Before we build, we show a clickable prototype to five real users like yours.
The API, login, push and sync. This is usually the 40% of the work that other quotes forget. It includes safe storage on the phone, a write queue that survives the app being closed, and a rule for clashing edits that we agree with you clearly.
Every merge makes a signed build in TestFlight and the Play internal track. You install it on your own phone the same day. Widget and integration tests run in CI. The low-end phone sits on a desk here and we test it by hand every sprint.
Listings, screenshots, privacy labels, the data-safety form, the account-deletion flow, and the review rounds, including the rejections. On Android we roll out in steps of 5%, 20% and 100%, with the crash dashboard open all the way.
We watch crash-free sessions, ANR rate, cold start and where users drop off, using real traffic. We fix defects at no charge. Then we hand over the pipeline and the keys, or stay on to build what comes next.
Offline is where most Indian apps quietly fall apart. A form that loses twenty minutes of a field agent's work because the lift had no signal is not just a small UX annoyance. It is the reason the agent goes back to paper.
We treat the database on the phone as the truth for the session. The server is what it matches up with later. Writes wait safely in a queue on the device. Clashing edits follow a rule we agree with you at the start: last edit wins, the server wins, or a person merges them. We do not leave it to whatever the sync library happens to do. Uploads carry on after the app is closed. The user sees what is waiting, what has synced and what failed, because silence is worse than a bad number.
Fastlane lanes for signing, versioning and upload. Every merge to main makes a build in TestFlight and the Play internal track, tagged and linked back to a commit. Your team can release without us on day one, and without us on day four hundred.
FCM and APNs with token refresh, topic groups, links that open the right screen, and fixes for the OEM battery savers that silently stop background services on Xiaomi, Oppo and Vivo phones.
Razorpay, PhonePe or Cashfree with UPI intent, cards and netbanking. We also check webhooks on the server, so a charged but unconfirmed order cannot happen, not just unlikely.
Sentry or Crashlytics with source maps, ANR tracking, cold-start traces and a dashboard of where users drop off. You will learn about a bad release from a graph, not from a one-star review.
We keep a low-end Android with 3GB of RAM, a mid-range Samsung and an older iPhone on the desk. We measure cold start, jank and memory on them, because that is what your customer is holding. A screen that drops frames on the cheap phone does not go live.
Chosen for the phones people really use, and so you can hire people for them later.
These are release checks, not hopes. If a build misses one of them on the low-end phone in our test list, it does not go to the store, whatever the calendar says. Holding the line here is why our apps do not get a one-star average in week two.
Talk about your appMeasured across the device matrix
3GB RAM Android, cold cache
Android app bundle, split per ABI
No dropped frames on core screens
Field teams, delivery fleets and consumer products that work on real Indian networks.
A fleet, ePOD and route-planning platform that works offline first, for drivers on roads with poor signal. The two ready...
A Shopify store for a Surat ethnic-wear label. It has 200+ SKUs of lehengas, sarees and suits, sorted by type, colour, f...
A Shopify storefront for a Surat watch and eyewear retailer — where shoppers can browse by gender, brand, style and comb...
Bring the field process, the phone your users really hold, and the limit that everyone else told you was impossible. We will tell you what it takes.
Proof
Swasthya Sarathi
A website and mobile app development project for a multi-service healthcare companion — It helps peo...
Read itMV Tech Education
A website development project for a Bihar vocational institute. It is a course list and admissions s...
Read itPatna Taxi
A website development project for a Patna and Muzaffarpur cab operator. It is a fast taxi-booking si...
Read itLive web applications built on Laravel, Next.js and Postgres. They are typed, tested, easy...
ExploreCommerce platforms where the checkout turns visits into sales and the back office numbers...
ExploreERP systems built on a stock and money ledger that is only added to, never changed — multi...
ExploreLet's talk mobile app development
A senior engineer reads every enquiry. You'll get a real answer — scope, risk and a number — within one business day.