DEV Community: Israr Kundi

What changes the cost of a Flutter app in Pakistan

Israr Kundi — Fri, 30 Oct 2026 10:51:40 +0000

Ask three developers for the cost of an app and you will get three very different numbers. That is not always dishonesty — it is because "an app" can mean very different things. Here is what actually moves the cost, so you can read a quote and share the details that make a quote useful.

The number of screens is the first factor. A five-screen catalogue app and a thirty-screen app with accounts, search, filters, and settings are different projects, even if both are called "an app". List your screens before you ask for a price: home, listing, detail, cart, checkout, account, and anything else the user touches.

The backend is the second factor, and usually the biggest. An app that only shows content is much simpler than one with login, orders, payments, an admin panel, and notifications. Each backend piece — user accounts, order handling, payment handling, admin tools — is real work, and it keeps working after launch.

Design and content readiness come next. If designs are ready and photos, menus, and prices are prepared, development moves fast. If the developer has to design screens and wait for content, the timeline stretches — and content delays cause more missed dates than coding does.

Integrations add cost one by one: maps, live tracking, chat, push notifications, camera, and payments. Each one needs setup, testing, and store permissions. A maps feature and a chat feature are not small extras; they are features with their own testing and edge cases.

Platforms matter less with Flutter than with native development, because one codebase covers Android and iOS. But the store release still takes work for each store: listings, screenshots, privacy details, and review. Budget time for review on both stores, and expect small rejections over policy details — fixing them is normal.

Maintenance is the cost people forget. Phones update, store rules change, and users report bugs. An app without a maintenance plan slowly breaks. Ask who handles updates and what that costs before launch, not after something stops working.

To get a useful quote, share four things: who uses the app, the list of screens, whether you already have a backend or website to reuse, and your must-have features versus nice-to-haves. A developer who asks hard questions before quoting is doing you a favour — the answers change the work.

Watch for quotes that skip the questions: a complete app promised in a week, a single number with no breakdown, or pressure to pay everything upfront. Good quotes explain what is included, what is not, and what happens after launch.

Agree on milestones, not just a total: a small payment to start, payments as working builds arrive, and a final payment after the store release and a short bug-fix window. Put source code handover and store account ownership in writing. You should own your app, not rent access to it.

Cost is not the only number that matters. An app that ships, gets used, and can be maintained is cheaper than a cheap app that never launches or dies a month later. Judge a quote by what it includes, what it leaves out, and whether the developer's shipped apps prove they can finish the job.

How FoodMate was built: a food delivery app in Flutter

Israr Kundi — Fri, 30 Oct 2026 10:46:01 +0000

FoodMate is a food delivery app for Dera Ismail Khan that I founded and built with Flutter. It has a customer app, a rider app, a restaurant web panel, and an admin panel — four tools that have to work together, because an order touches all of them before the food arrives.

The starting problem was simple: local restaurants took orders by phone, and customers had no easy way to browse menus, track an order, or pay except in cash. The goal was not a fancy app. It was an app that a restaurant owner could run and a customer could use on an ordinary Android phone.

Flutter was the practical choice. One codebase covers Android and iOS, which matters when the team is small and the budget is real. The customer app, the rider app, and the restaurant panel share the same ordering logic, so a fix in one place does not have to be rebuilt three times.

The customer side covers the full journey: browse menus, place an order, pay by cash on delivery, wallet, or digital payment, track the order live, and reach support in the app. Each of those sounds small on its own. Together they are the difference between an app people try once and an app they open again.

The rider and restaurant sides are where delivery apps usually fail. Riders need clear, simple job views. Restaurants need to manage menus and orders without training. The admin panel ties it together. If any one of the four tools is hard to use, the whole order breaks down — so each one was kept as simple as the job allowed.

Building for local users shaped the details. Most customers are on Android, often on low-end phones, so the app had to stay fast and usable on a weak connection. Cash on delivery stayed a first-class payment option, because that is still how many customers prefer to pay. Designing for the real phone and the real payment habit mattered more than any single feature.

Working builds came early and often. A food app cannot be judged from screenshots — it has to be tested with a real order, a real rider flow, and a real restaurant accepting it. Testing the full loop, not just the screens, is what found the problems worth fixing: unclear order states, slow menu loads, and steps that made sense to the builder but not to the user.

The store release was its own job: listing, screenshots, privacy details, and review. An app that is live on Google Play has passed a review that a demo never faces, and that is part of the proof when someone asks whether the work is real.

FoodMate is still growing, and the next improvements come from real usage: what customers order, where orders get stuck, and what restaurants ask for. That is the normal life of a shipped app — launch one useful version, watch how people use it, and improve the parts they actually touch.

If you are building a delivery, ordering, or booking app, the lesson is the same: build all four sides of the job, keep each one simple, test the full loop with real users, and ship. A beautiful customer screen means nothing if the rider cannot see the job or the restaurant cannot accept the order.

From website to mobile app: when Flutter is worth it, and when it is not

Israr Kundi — Fri, 30 Oct 2026 10:39:36 +0000

If you already have a website, turning it into a mobile app sounds obvious — but it is not always the right move. Here is how to decide, and why Flutter is often the tool for it when the answer is yes.

Start with your users, not the technology. Do they visit once from a Google search, or do they come back every week? Do they need notifications, an account, offline access, or the camera and location? Repeat use plus phone features is the strongest case for an app. One-off visits are usually better served by improving the website.

An app is worth it when customers order, book, or check something repeatedly; when reminders bring them back; when the experience needs offline access or device features; or when you want a presence on the home screen. Food ordering, bookings, fitness tracking, and community apps usually qualify.

It is not worth it when your content changes rarely and is found through search — search engines do not index app screens the way they index web pages. It is also not worth it when the site is basically a brochure, or when you cannot support another product. An app needs updates, store listings, and support, on top of the website.

If you do build, Flutter is a practical choice: one codebase for Android and iOS, and your existing backend and APIs can usually be reused. The website's database, login, and payments do not have to be rebuilt — the app talks to the same backend through the same APIs. What changes is the interface, rebuilt for thumbs, small screens, and offline moments.

Reusing the backend also keeps the cost down, but it does not make the project free. The number of native features — notifications, offline mode, camera, maps, payments — is what drives the remaining work. A simple catalogue app and a full ordering app with live tracking are very different projects, even on the same backend.

A common mistake is wrapping the website in an app shell and calling it an app. Users notice immediately: it feels slow, it does not work offline, and it cannot use notifications or the camera properly. A real app rebuilds the key journeys natively — browsing, checkout, booking — even if the backend stays the same.

Plan the release like a launch, not a copy-paste: store accounts, listings, screenshots, privacy policy, and a plan for the first reviews. And plan for two products afterwards. The website and the app both need updates, and they should not drift apart — prices, content, and accounts should stay in sync.

Build an app when your users will open it again and again. Keep the website for discovery and first visits. Used together — website for finding you, app for staying with you — they cover both jobs instead of competing.

Flutter app development in Peshawar: what small businesses should expect

Israr Kundi — Fri, 30 Oct 2026 10:33:27 +0000

If you run a business in Peshawar — a restaurant, a shop, a clinic, a coaching centre — you have probably been told you need an app. Sometimes that is true. This note explains what building a Flutter app actually involves, so you can judge quotes and timelines with confidence.

Why Flutter comes up so often: one codebase produces both Android and iOS apps. For a small business that matters, because building twice doubles the cost and doubles the maintenance. Flutter is a good fit for most business apps: catalogues, ordering, bookings, dashboards, and customer accounts.

A normal project runs in stages. First, the idea is pinned down: who uses the app, what they do in it, and what it must not do in version one. Then design, then building in working versions you can test on a real phone, then store release, then fixes after real users arrive. If a developer cannot show you a working build in the first few weeks, ask why.

What changes the time and cost: the number of screens, whether there is a backend (login, orders, payments, an admin panel), whether designs are ready, and whether content is ready. Content delays kill more timelines than coding does — have your menu, photos, and prices ready before development starts, or the project will wait on you, not the developer.

Local realities matter. Most customers in Pakistan are on Android, often on low-end phones with patchy internet, so the app must be fast and usable on a weak connection. Cash on delivery is still common, and many customers prefer Urdu alongside English. A good developer plans for all three instead of building for a flagship phone on fast Wi-Fi.

The store release is real work, not a button press: Play Store listing, screenshots, privacy policy, and account setup, plus the same for the App Store if you want iOS. Budget time for review. Rejections happen, usually over small policy details, and fixing them is normal — it is not a sign the project failed.

After launch, the app is not finished. Expect updates for new phone versions, small fixes, and improvements from user feedback. Ask for a simple maintenance plan before launch, and make sure you own the store accounts and the source code. If only the developer can update the app, you do not really own it.

When should you not build an app? If customers find you through Google search and visit once, a good website may serve you better. An app earns its place when customers return often — ordering food, booking appointments, tracking orders, or checking in daily.

Start small, launch one useful version, and grow from real usage. A simple app that customers actually use beats a big app that never ships.

How to hire a Flutter developer in Pakistan (without getting burned)

Israr Kundi — Fri, 30 Oct 2026 10:32:23 +0000

Hiring a Flutter developer in Pakistan gives you access to strong mobile talent at rates that make sense for startups and small businesses — but the market is mixed, and a good portfolio page is not enough proof. Here is what to check before you commit.

Start with shipped apps, not screenshots. Ask for links on Google Play and the App Store, then actually install them. An app that is live has survived store review, real devices, and real users. A screenshot has survived nothing. Check whether the app still works, how it looks on a small low-end phone, and whether it has recent updates.

Ask who did what. Many developers show team projects, which is normal — but ask directly: which screens did you build, what did you own end to end, and what broke after launch? A developer who can explain a real bug and how they fixed it is worth more than one who only lists technologies.

Check the full journey, not just the interface. A finished app needs state management (Bloc, Provider, or GetX), API integration, Firebase or another backend, push notifications, and the store release itself — signing, store listings, privacy details, and review rejections. Ask how they handled a rejection or a crash report, because both will happen on a real project.

If you can, look at code. A public repository tells you a lot: readable structure, consistent state management, and no passwords or API keys left in the code. You do not need to read every line — you need to see that the work is organised and that someone else could pick it up.

Test communication early. Most Pakistan-based developers work remotely with clients in other time zones, so agree on working hours, how often you get updates, and where work is tracked before money moves. A short paid trial task — one real screen with real data — tells you more than a week of interviews.

Watch for red flags: no live app to show, only interface mockups; promises of a complete app in a week; no questions about your users, your backend, or your budget; and pressure to pay everything upfront. Good developers ask hard questions before they quote, because they know the answers change the work.

Agree on milestones, not just a total. A common shape is a small payment to start, payments as working builds arrive, and a final payment after the store release and a short bug-fix window. Put the source code handover and store account ownership in writing — your app should not live only on someone else's account.

Plan for after launch. Apps need updates: new Android and iOS versions, store policy changes, and user feedback. Ask who handles maintenance and what it costs. The cheapest developer is expensive if the app is abandoned a month after launch.

Pakistan has developers who have shipped real products — food delivery, fintech, and AI tools among them. Hire the one whose apps you can download today, whose process you understand, and who treats your launch as the start, not the finish.