Customers complete the task
Account, order, booking, or payment happens in the application, with a path short enough to repeat. Push is used for the events that matter, not for noise.
Mobile applications
Naraway takes a mobile product from a written scope to the App Store and Google Play. One team covers the interface, the application, the services behind it, and the releases after customers start using it. Companies hire us when the phone is a sales channel, an operations tool, or both.
Naraway takes a mobile product from written scope to the App Store and Google Play, covering interface, application, backend services and releases.
Why companies commission this
A website explains the offer. An application is where a customer orders, a partner checks status, or a field team updates a record. Naraway builds that product for startups, operating companies, and enterprises that need it to hold up outside a single office.
Account, order, booking, or payment happens in the application, with a path short enough to repeat. Push is used for the events that matter, not for noise.
Staff see the same job, stock, or case the back office sees. The application talks to the systems you already run, instead of becoming a second source of truth.
Catalogue, checkout, and order status live next to the website. Listing, screenshots, and review response are part of the release, not an afterthought.
Products we are hired to build
Scroll the row. Each card is a different buyer, a different first release, and a different first message to us.
Catalogue, saved payment, and order status for a brand that already sells. Version one is the repeat purchase, not a second website.
Scope a commerce appJob list, photo proof, and a status the back office can trust. Built for teams who currently close work on WhatsApp and paper.
Scope a field appAvailability, confirmation, reminder, and reschedule. The release is done when a customer can book without staff retyping it.
Scope a booking appSign-in, the content or service they are entitled to, and renewal. Useful when the website login is where people drop off.
Scope a member appA buyer side and a supplier side, with the rules for who can list, who can pay, and who can see a dispute. Scoped before any screen is drawn.
Scope a marketplaceCrashes, a release nobody will own, or a codebase the last vendor kept. We read the repository first and say what can be repaired.
Ask for a code reviewScope of work
If a piece already exists, a design file, an API, a brand, we start from that. We do not rebuild it to make the engagement look larger.
Who uses version one, which jobs it must finish, and which jobs wait. You review a screen list and a time estimate before design production starts. A narrow first release is often planned across 8 to 14 weeks. A product with several roles, a new backend, or heavy integrations takes longer, and the estimate says so.
Task flows, then screens in a shared design file. Engineering builds from approved screens. Type, colour, and components follow your brand, so the application looks like the company, not like a template.
React Native or Flutter when one codebase should serve both stores. Swift and Kotlin when the product depends on the device itself: camera, offline work, or platform APIs. The choice is written into the scope with the reason.
Accounts, permissions, data, and the API the application calls. Payments through Razorpay, Stripe, UPI, or the gateway you already use. Messages through the provider you approve.
TestFlight and Play testing tracks, store listing, and submission. The public application is published from your Apple and Google accounts. After approval, the same team handles crashes, new OS versions, and the features you queued.
Platform choice
Most products that must reach both stores start cross-platform. Native is the right call when the phone is the product. You still receive design, the API, store release, and your repository either way.
| Cross-platform | Native | |
|---|---|---|
| Stack | React Native or Flutter | Swift on iOS, Kotlin on Android |
| Use it when | Both stores, one team, a shared product | Heavy device use, or one store first |
| Tradeoff | Faster to both stores, small platform gaps | Closer to each OS, two codebases to maintain |
One working session names the user, the jobs in version one, the stack, and what waits. You keep that note if you hire us and if you do not.
App Store
An iPhone release fails for paperwork as often as it fails for code. Naraway builds the application and prepares the submission Apple actually checks: privacy answers, permission text, TestFlight, and the account the listing will live on.
The App Store listing is published from your Apple Developer account, not ours. If you do not have one, the scope includes opening it in the company name before the first build is uploaded.
Missing privacy labels, a login with no way to delete the account, and permission prompts that do not say why the camera, location, or contacts are needed. Those are written before submission, not after a rejection.
TestFlight goes to the people you name. You use the real build on an iPhone before it is public. Native work is Swift. A shared codebase is React Native or Flutter when both stores are in version one.
Google Play
Play is a wider set of screens, OS versions, and manufacturers. Naraway does not claim to test every handset. We agree a short device list for your markets, ship through your Play Console, and fill the Data safety form before the listing goes public.
The listing stays on your Google Play developer account. Internal and closed testing tracks are used first, so staff and a pilot group install the build before it is open to everyone.
A current target API, a Data safety form that matches what the app collects, and store listing assets. If the app takes payment, the billing path is the one your gateway and Play both allow.
Native Android is Kotlin. If iOS is in the same release, one React Native or Flutter codebase is usually the practical choice, with Kotlin only where a device API needs it. The scope says which.
Who this is for
Naraway is a global business partner. Mobile is one line of that work. Legal, brand, marketing, and hiring stay separate unless you ask for them in the same plan.
The smallest application that proves the offer. Version one is scoped tightly so you can learn from real use before you fund the rest.
Booking, orders, cases, or field work. We map the current process, then build the screens people will repeat.
Checkout and order status, using the catalogue rules your backend already has. The application is a channel beside the site.
Sign-in against the systems you run. Access, data, and who approves a release are written down before build.
Handover
The flows and the screens that shipped.
Application and API on GitHub, GitLab, or Bitbucket.
TestFlight and a Play testing track before the public release.
Listing copy, screenshot guidance, and the submission checklist.
The listing stays on your Apple and Google developer accounts.
How to build, where secrets live, and how a release is cut.
Questions
Next step
A new product starts with the job version one must finish. An application already in the stores starts with the repository. Either way you get a written reply: what is in, what is out, and how iOS and Android should be built.
Starting price
iOS and Android, shaped around the product you want to launch.
Request a scope note