Should a mobile app be built in Flutter or native?

Flutter suits most business applications: one codebase for Android and iOS, roughly 60 to 70 percent of the cost of building twice, and a single team maintaining it. Native development suits apps depending heavily on camera, sensors, background services or deep platform integration. The decision should follow from what the app must access, not from preference.

Does GegoSoft build the backend as well as the mobile app?

Yes. The API, database, admin panel and business rules are typically more than half of a mobile project, and splitting them across two vendors is a common cause of delay. GegoSoft builds backends in Laravel and NestJS with the same team accountable for both the app and the server.

Who publishes the app to the store?

Publishing under the client's own developer account is usually preferable, because the listing, reviews and install base belong to the client and nothing needs transferring if vendors change. GegoSoft sets up the accounts, prepares listing copy, screenshots, data safety declarations and privacy policy, and manages submission.

Can GegoSoft take over an existing mobile app?

Yes. Typical cases are apps that have fallen behind store SDK requirements or whose original developer is no longer available. The process starts by getting the app building again and documenting its behaviour, then agreeing what to upgrade and what to rewrite. Sometimes rebuilding in Flutter costs less than rescuing the existing codebase.

Does GegoSoft provide App Store Optimisation?

Yes. Two in-house SEO specialists handle App Store Optimisation including listing title and description, keyword research, screenshots and store page conversion testing. GegoSoft does not provide paid reviews or install manipulation, as both violate store policy and risk listing removal.

Mobile apps built by a team that ships its own

Q: How much does it cost to develop a mobile app?

Scope drives cost far more than platform choice. A companion app for an existing system costs a different order of magnitude from a marketplace app with payments, chat and offline sync. Two costs clients routinely omit are the backend, which is often more than half the work, and annual maintenance, which is unavoidable because app stores force periodic updates.

Q: What maintenance does a mobile app need after launch?

Both Google Play and the App Store raise their minimum target SDK requirement annually, forcing an update regardless of feature changes. Add operating system releases with new permission models, dependency and SDK upgrades, and periodic policy changes. An app left untouched for eighteen months usually requires significant remedial work before it can be updated.

Three dedicated mobile developers in Madurai, building in Flutter and Kotlin. We publish and maintain our own apps on Google Play, which means we've lived through the policy changes, the SDK deadlines and the rejection emails — and we plan for them in your project rather than discovering them at submission.

Get a free quote See apps we've shipped

Last reviewed: September 2026

Mobile application development at GegoSoft Technologies, Madurai

THE SHORT VERSION

Who we are: GegoSoft Technologies (OPC) Private Limited, Madurai, Tamil Nadu, India, established 2017. Eighteen engineers in total, including three dedicated mobile developers.
What we build with: Flutter for cross-platform apps where one codebase serves Android and iOS. Kotlin for native Android where the hardware or platform integration demands it.
Our own apps: Daybook, a transaction and cash-book app on Google Play, and AndroidNewsWire, built on headless WordPress with Next.js and Flutter. We publish under our own developer account.
Backend included: Most apps need a server. We build those too — Laravel or NestJS APIs, by the same company, so there's no gap between the app team and the backend team.
How AI changes it: All eighteen engineers use Claude Code daily. On mobile it mainly buys widget test coverage, device-matrix edge cases and the state handling apps usually ship without.
Typical timeline: Eight to twelve weeks for a Flutter app with a backend, from discovery to store submission. Store review adds a few days to a week on top.

// Proof

We're on the store as a publisher, not just a contractor

Most agencies build apps and hand over the keys. We maintain apps under our own Google Play developer account, which means we absorb the parts clients usually get surprised by: target SDK deadlines that force an update whether you planned one or not, policy reviews, data safety declarations, and the occasional rejection with a vague reason attached.

OUR PRODUCT · LIVE ON GOOGLE PLAY

Daybook

A daily transaction and cash-book app for small businesses and individuals who track money by hand. Simple enough for someone with no accounting background, which is a harder design problem than it sounds.

ANDROID OFFLINE-FIRST IN PRODUCTION

About Daybook

OUR PRODUCT · CONTENT PLATFORM

AndroidNewsWire

A publishing platform running headless WordPress with a Next.js front end and a Flutter app against the same API. A useful reference for anyone wanting web and mobile fed by one content system.

FLUTTER HEADLESS WP NEXT.JS

Visit androidnewswire.com

Alongside these, our school ERP GegoK12 runs mobile access for parents and staff across twenty-plus schools — apps that get used every school day by people who did not choose to use them, which is the most honest usability test there is.

// The first decision

Flutter or native? It depends on what the app has to touch

This is the question that decides your budget, your timeline and your maintenance cost, and it should be answered in week one rather than assumed. Here's how we reason about it.

Consideration	Flutter (cross-platform)	Native (Kotlin / Swift)
Codebases to maintain	One, for Android and iOS	One per platform
Cost for both platforms	Roughly 60–70% of building twice	Full cost per platform
Best suited to	Business apps, content apps, forms, dashboards, commerce — most projects	Heavy camera or sensor work, background services, complex platform integration
Look and feel	Consistent across platforms; can follow platform conventions with effort	Native by definition
New OS features	Usually available via plugins, occasionally with a lag	Available on day one
Finding developers later	One team can maintain both platforms	Separate specialists for each
Our default	Chosen for most projects	Chosen when the hardware demands it

A note on iOS

Our mobile team's depth is in Flutter and Android. We deliver iOS through Flutter, which covers the great majority of business applications well. If your project genuinely needs deep native iOS work — ARKit, complex background processing, tight HealthKit integration — we'll tell you that at proposal stage rather than take the work and learn on your budget.

// Applications

What we build most often

Apps people use to get work done, rather than apps that exist because a brand felt it should have one.

Companion apps for a web system

Your existing platform in someone's pocket — approvals, notifications, quick entry and lookups. Usually the highest-value app a business can build, and the least glamorous.

Field force & logistics

Check-ins, route tracking, job status, photo capture and proof of delivery, built to keep working when the signal drops and sync when it returns.

Data collection & inspection

Structured forms, checklists and audits for teams working away from a desk — with offline capture, validation and an admin console behind it.

Commerce & ordering

Catalogue, cart, payment and order tracking, including B2B ordering apps where reps place orders for accounts with negotiated pricing.

Community & communication

Member directories, messaging, events and announcements — the pattern behind our school and church products, adapted to other kinds of organisation.

Content & publishing apps

Reading apps fed by a headless CMS, with offline caching, push notifications and a content workflow your editors can actually run.

// The other half

An app is usually the smaller half of the project

Behind almost every app is an API, a database, an admin panel and a set of business rules — and that's typically where more of the work sits. Splitting it across two vendors is where most mobile projects lose time, because every ambiguity becomes a negotiation between companies.

One team, both halves — the same company builds the Laravel or NestJS API and the Flutter app against it
Admin console included — someone has to manage users, content and support requests from day one
Push notifications done properly — with delivery tracking, not fire-and-forget
Offline and sync — designed in from the start, because retrofitting it is close to a rewrite
Analytics and crash reporting — configured before launch, so the first bad review isn't your first signal

Mobile app connected to a Laravel backend built by GegoSoft

// How we work

An AI-assisted team, on a platform where you can't hotfix

A web bug is fixed in an afternoon. A mobile bug waits for store review, and then waits again for users to update. That asymmetry is why thoroughness matters more here — and why AI tooling changes the economics in our clients' favour.

Widget and integration tests that actually get written

Test coverage is the first casualty of a mobile deadline. Generating it is now cheap enough to stay in scope, which is what keeps the app safe to change after launch.

The states apps normally ship without

No connection, slow connection, session expired, permission denied, storage full, background kill mid-upload. Enumerated and handled rather than discovered by a one-star review.

Device matrix reasoning

Small screens, large screens, old Android versions, unusual OEM behaviour and accessibility settings — worked through systematically rather than tested on whatever handsets are in the office.

Store submission prepared, not improvised

Data safety declarations, permission justifications, privacy policy and listing copy drafted alongside the build. Rejections usually come from paperwork, not code.

Where the line is: AI drafts, tests and reviews. A named engineer owns the app, approves every merge, and signs off the release. Nothing reaches a store listing without a person deciding it should.

// Engagement

How a mobile project runs

You get a build on your own phone early, because opinions about an app formed from screenshots are worth very little.

Week 1

Scope and platform decision

What the app does, who uses it and in what conditions, then Flutter or native, and which platforms at launch. Store account and policy requirements identified now, not at submission.

Week 1–2

Flows and interface design

Screens designed including empty, loading, error and offline states. Our UI/UX team leads this — GegoSoft was founded by a designer and it shows most on mobile.

Week 2–3

API and data model

Backend endpoints, authentication, sync strategy and push infrastructure. Built in parallel with the app rather than waited on.

Week 3–9

Build with test builds every sprint

Installable builds via TestFlight and Play internal testing at the end of every two-week sprint, on your actual phone, with your actual data.

Pre-launch

Device testing and store preparation

Testing across a device matrix, performance and battery profiling, crash reporting configured, then listing copy, screenshots, data safety forms and privacy policy.

Launch+

Submission, release and maintenance

Store submission and any rejection handling, staged rollout, then a maintenance arrangement for OS updates and SDK deadlines. Full source in your repository either way.

App store listing and branding work by GegoSoft

// Plan for this

A mobile app is never finished, and you should budget accordingly

Unlike a website, an app has landlords. Google and Apple raise minimum SDK requirements annually, which forces an update even if you've changed nothing. Policies shift. Payment libraries deprecate. An app left alone for eighteen months usually can't be updated without significant remedial work — and in the worst case gets removed from the store.

Annual target SDK updates — mandatory on both stores, non-negotiable deadlines
OS releases — new permission models and behaviour changes every year
Dependency upgrades — payment, maps, analytics and auth SDKs all move
Policy changes — data safety, privacy and advertising rules are revised regularly

We quote maintenance as a line item rather than leaving it out to make the initial number look better. If you'd rather run it in-house, we hand over the source and train your team — but you should know what you're taking on.

// Sectors

Where we've built before

Domain familiarity shortens discovery. These are areas where we already understand the vocabulary and the usual requirements.

Education

Banking & finance

Healthcare

Logistics & field ops

Media & publishing

Retail & commerce

Construction

Community & faith

// Why GegoSoft

Nine years of shipping, and we still maintain the first things we built

GegoSoft started in Madurai in 2017. GegoK12 has been in production across twenty-plus schools since close to the beginning, alongside ChurchCMS, BOQ Manager, ChemTracker, eTender and Daybook. Maintaining your own software for years teaches you what a two-year-old codebase costs — and that knowledge is what we design against on client projects.

2017Building software from Madurai, Tamil Nadu

3Dedicated mobile developers, in a team of 18

6Production products we build and maintain ourselves

4Continents with long-term clients — US, EU, Australia, Gulf

// Questions

Frequently asked questions

How much does it cost to develop a mobile app?

Scope drives the number far more than platform does. A companion app for an existing system with a handful of screens is a different order of cost from a marketplace app with payments, chat and offline sync. Two costs clients routinely leave out: the backend, which is often more than half the work, and annual maintenance, which is not optional because the stores force updates. We give a fixed scope and price after the first week.

Should we build in Flutter or go native?

Flutter for most business applications — one codebase for Android and iOS, roughly 60 to 70 percent of the cost of building twice, and one team maintaining it afterwards. Native when the app depends heavily on the camera, sensors, background services or deep platform integration, where the cross-platform layer creates more problems than it solves. We decide this in week one based on what the app has to touch, not on preference.

How long does mobile app development take?

Eight to twelve weeks is typical for a Flutter app with a backend, from discovery through to store submission. Add time for payments, offline sync or complex integrations. Store review itself takes anywhere from a day to a week, and can be longer if a reviewer queries a permission or a data safety declaration — which is why we prepare that paperwork during the build rather than after it.

Do you build the backend as well as the app?

Yes, and we'd usually recommend it. The API, database, admin panel and business rules are typically more than half the project, and splitting them across two vendors is where mobile projects lose time — every ambiguity turns into a conversation between companies. We build backends in Laravel and NestJS, with the same team accountable for both halves.

What happens after the app launches?

Both stores raise their minimum target SDK requirement annually, which forces an update whether or not you've changed anything. Add OS releases with new permission models, dependency upgrades, and periodic policy changes. An app left untouched for eighteen months usually needs significant remedial work before it can be updated at all. We quote maintenance as a line item rather than hiding it, and we'll hand over the source and train your team if you'd rather run it yourselves.

Do you publish the app, or do we?

Either. Publishing under your own developer account is usually better — the listing, reviews and install base belong to you, and there's nothing to transfer if you change vendors. We'll set the accounts up, prepare the listing, screenshots, data safety declarations and privacy policy, and manage submission on your behalf. Where a client needs to launch before their own account is verified, we can publish under ours and transfer later.

Can you take over an existing app?

Yes, and it's a common request — usually an app that's fallen behind on SDK requirements or whose original developer is gone. We start by getting it building again and documenting what it does, then agree what to upgrade and what to rewrite. Sometimes the honest answer is that rebuilding in Flutter costs less than rescuing what's there, and we'll say so with the reasoning.

Do you do App Store Optimisation and launch marketing?

Yes. We have two in-house SEO specialists who handle App Store Optimisation — listing title and description, keyword research, screenshots and conversion testing on the store page. We don't do paid reviews or install manipulation; both violate store policy and risk your listing being removed.

// Related services

Tell us who uses the app, and where.

A commuter on patchy signal and a technician in a warehouse need different apps. That answer shapes the platform choice, the architecture and the cost — so it's where we start.

Get a free quote Message us on WhatsApp