Mobile App Development

Connected experiences for customers and teams.

Start with whether you need an application at all

Mobile app development here means a connected experience staff or customers use on a phone to finish a job — not a listing in a store because a competitor has one. A lot of Kerala SMEs need a website that calls and messages well, or a web application that works in the phone browser. A store binary is a later decision with later costs: accounts, reviews, release trains, and two platforms if you are honest about iOS and Android. If you cannot name the job that fails in the browser, do not start in the store.

We work from Chengannur. The phones we care about are the ones already in your warehouse, your bay, and your customer’s pocket — often mid-range Android, patchy data, a WhatsApp chat that already carries the real process. The app has to beat that chat on a Tuesday, not in a demo on office Wi-Fi. If it does not, people will screenshot the screen and send it to the group. That is the failure mode. Treat it as the test.

When a website is enough

If the user is a visitor who needs to understand you, find a number, and enquire, you want web development. A responsive site with tap-to-call, WhatsApp, and a short form will beat a thin store app that opens slowly and asks for a rating. Public pages also need to be found. Store apps do not rank like service pages. Do not spend a quarter on a listing so that a stranger can do what a contact page already does.

If staff will do the same job they do at a desk, and a decent connection exists, a web application in the phone browser is the default. Today’s list, a confirm, an undo — those can be a logged-in site. The distinction is the same one on website versus web application: anonymous visitors versus signed-in work. A web application is still software. It is not a store listing. Price it as software. Do not call it “the mobile app” in the same breath as the brochure.

A website is also enough when the “app” is really a PDF, a price list, or a visiting card. Those should be pages or files with a date, not a binary you have to update through a store whenever the rate changes.

When an app is the wrong spend

It is the wrong spend when nobody can write the one job that must work offline or on a home screen. It is the wrong spend when the API does not exist and you are asking the phone to invent a system of record. It is the wrong spend when you want “our brand in the store” and the only screen is a WebView of the site. Reviewers will say that out loud. We will say it in the briefing so you hear it before you pay.

It is also the wrong spend when the users are your own staff and they will not install from a store on a personal phone. Then you need a clearer plan: a web app, a sideload you will regret, or devices you own. Bring that constraint on day one. Do not discover it at UAT when half the team refuses the download.

Festival deadlines make this worse. An app store review is not a date you control. If the festival is in six weeks and you do not already have accounts, certificates, and a privacy text, you are briefing a web slice, not a listing. Call it that. Keep the rest of the money.

Staff apps and customer apps are different products

A staff app is a tool. It can look plain. It must be fast on last year’s phone, obvious with gloves or grease nearby, and honest when the network drops. Login is a role, not a marketing moment. The test is whether the night shift completes the list without a supervisor in the group chat. Notifications should mean “do this now”, not “we miss you”.

A customer app is a product. It must earn a home-screen slot against WhatsApp, UPI, and Maps. If they only open it once to book and then forget it, a website or a short link would have been cheaper. Loyalty, repeat orders, tickets, or a status they check daily — those are reasons. A brochure they already saw on the site is not.

Do not build one binary for both audiences because the icon was expensive. Different roles, different stores of trust, different failure modes. They can share an API. They should not share one “mobile” estimate. Write two sentences of done. If you can only staff one, pick the users who already cost you hours — usually staff — and let customers keep the website for a phase.

	Staff	Customer
Job	Finish today’s work correctly	Repeat a purchase or a status check
Look	Clear, large controls, undo	Brand, trust, a reason to keep it
Notify	A task or an exception	Something they asked to hear
Fail if	The WhatsApp group stays	They delete it after the first booking

Talking to systems you already have

A phone without an API is a pretty camera. The app should read and write the system of record you already trust — Tally for the bill, SQL Server for the job, the website for the catalogue — through a backend you own. That backend is usually ASP.NET Core. Building screens first and “wiring Tally later” is how you launch a notepad. Bring the edition, a sample export, and the person who already reconciles Friday.

If the existing system has no safe API, the first slice may be the API and a web screen, not two store listings. That order feels unimpressive in a demo. It is how you avoid a year of the app and the ledger disagreeing. GST amounts, item codes, and branch-wise stock are not details for the designer. They are the payload. If accounts will not own the exceptions, do not put a post button on a phone.

Photos from the bay are a common brief. They are also a storage, compression, and permission problem. Say how long you keep them, who may see them, and what happens when the upload fails on a bad tower. “Just put it in the group” is the current system. Beating it means a retry the user trusts, not a spinner that dies when they switch apps.

Stores versus a PWA — the honest version

A progressive web app can live on the home screen, work in a browser, and skip store review. It is a good fit when you control the users, you need to ship weekly, and you do not need deep device features. It is a poor fit when you promised an App Store badge in a board meeting, or when you need background location, heavy offline maps, or payments that the store’s rules will fight you on.

Native or cross-platform store apps earn their keep when you need those device features, when customers already look for you in a store, or when the web screen is genuinely too limited on the phones you have. They cost more to release. Apple and Google can delay you. You will need privacy text, store listings, screenshots, and someone who owns the certificates when a phone number leaves the company.

We will not sell you both in the same month “to be safe”. Pick the thinner path that tests the sentence. If staff complete the job in a PWA for two weeks, you earned a conversation about a listing. If they do not, a store icon will not save the workflow. That discipline is the same as any MVP: one job, real devices, measured use.

What a first mobile slice looks like

One role, one job, on the phones people already carry. Login that works. The happy path. The three failures that already happen — no network, wrong quantity, the manager is away. An undo or a clear reversal. A handover that includes the store account or the PWA install steps. Out-list: the second role, the customer clone, last year’s reports, a chatbot. If the list grows in standups and nobody re-baselines, you do not have a slice. You have a programme.

Time: two to four weeks for a paid discovery with real devices and a written out-list. Eight to sixteen weeks for a staff tool that talks to an API you already have. Longer when the API is the work, when both stores must ship, or when offline is real rather than a slide. Customer apps that must earn a slot sit at the longer end because the design bar is higher and review is not a day you own. We will not invent a rupee total for your store fees and your SMS gateway. The estimate shape is on how much custom software costs.

Test on the worst phone in the building, on the tower near the yard, not on a flagship in the meeting room. If we cannot get that phone for an afternoon, we will say the test is incomplete. Incomplete tests are how you discover the font is unreadable after go-live.

Notifications, offline, and other ways to lie to yourself

A notification that is not actionable will be muted in a week. If you cannot write the sentence the banner should show, do not build the banner. Offline is not “it caches everything”. Offline is: which actions may happen in a shed with no data, and how they reconcile when the phone returns. If you cannot list those actions on one page, you do not have an offline project. You have a hope.

Location tracking is a trust event. Staff will ask why. Customers will delete you. If you need it, write the why on the permission screen in Malayalam or English they actually speak, and keep the collection to the job. “For a better experience” is not a why.

Handover — stores, certificates, and who ships week twelve

You get the source, the backend repo, the store listings in accounts you own, and the certificates in a place that is not one laptop. If the Apple ID is a personal email, fix that before we start, not after the first rejection. A week of support after the first store version is normal. A forever unpaid bug-bash is not. Name who bumps the version when a phone OS breaks you. If that name is nobody, budget a retainer with a sentence, or accept that the app will rot.

Design files and the component list belong with the build. If the screens were designed first, they should have come through UI and UX as journeys and forms, not as a moodboard dumped on an engineer in week nine. We would rather delay a listing than encode a pretty dead-end.

What we will not do

We will not wrap your website and call it an app. We will not promise a store feature Apple has not approved. We will not cut the API so the screens can film well. We will not invent download counts. We will not staff “iOS and Android” as one junior and a hope. We will not start from a template that assumes a US credit card and a suburban address when your user pays UPI and types a GSTIN.

We will not pretend a staff tool needs a delight animation more than it needs undo. We will not put customer chat inside the app if WhatsApp is already the relationship and you have no one to staff a second inbox.

How to brief a mobile job

Write who holds the phone and the one job they must finish. Say whether they are staff or customers. Name the system of record that must stay true. Say what must work when the tower is bad. Say whether a store listing is a requirement or a wish. Attach the unofficial process — the group chat, the sheet, the paper job card. Name who owns the store accounts and who will test on a bad phone.

If that page is thin, the useful first week is discovery, not icons. If it is specific, we can say website, PWA, or store — and what is out. Send it through contact. Bring the worst phone. Leave the competitor’s screenshot in the folder unless you can say which of their screens you are actually copying and why.