Flutter + web product development
Most products in this region need a web presence for search and trust, and a mobile app because that is where people actually transact. Building those as separate projects doubles the cost and guarantees they drift apart. I build them as one product with one API.
Built for these situations
- Founders who need iOS, Android and web from one budget
- Businesses whose website and app already disagree about prices, stock or status
- Teams with several user roles who each need their own app surface
- Products where SEO and app-store presence both matter commercially
Not a fit if
- Products that genuinely need platform-specific hardware depth on day one
- Anyone who wants an app only because competitors have one
- Projects with no plan for app-store accounts, review or release management
What usually goes wrong
Two codebases, two truths
When web and mobile are built separately, business rules get implemented twice and diverge quietly. Customers find the difference before you do.
Every feature costs three times
A change to checkout means iOS work, Android work and web work, coordinated across teams. Roadmaps slow to a crawl for structural reasons, not effort ones.
The web app cannot be found
Client-rendered web apps look modern and rank poorly. For products that depend on organic discovery, that is a revenue problem disguised as a tech choice.
Roles crammed into one app
Customers, suppliers and drivers need different apps, not one app with hidden menus. Mixing them produces confusing UX and awkward store listings.
What Makhloof Studio actually delivers
One API, many clients
A single backend owns auth, business rules, payments and notifications. Every client — web, iOS, Android, admin — consumes the same contract, so behaviour cannot drift.
Flutter apps for iOS and Android
One Dart codebase, two native builds, near-identical behaviour — including RTL Arabic layout, push notifications and release automation. Ajza ships three role-separated apps this way.
Server-rendered web for search
Next.js pages that render on the server, so category, product and content pages are indexable and fast — the foundation of Qooty's documented crawl and indexing gains.
Shared design language
One visual system across web and mobile so the product feels like one company, with RTL and LTR both treated as first-class rather than mirrored late.
Shipped, not theorised
Every claim on this page maps to a case study you can read in full.
Typical modules
A realistic scope for this kind of build. Yours will be a subset — the first call is where we cut it down.
Mobile
- Flutter apps for iOS and Android
- Role-separated app builds
- Push notifications and deep links
- Offline caching and retry-safe requests
- In-app updates and release automation
- Store listing, review and rollout support
Web
- Server-rendered Next.js application
- SEO-ready routing, metadata and sitemaps
- Bilingual Arabic/English with full RTL
- Admin and operations dashboards
- Core Web Vitals performance budget
- Analytics and conversion tracking
Shared backend
- One API contract for every client
- Authentication, roles and permissions
- Payments, wallets and notifications
- Media storage and image pipeline
- Background jobs and scheduling
- Dockerised deploy with CI/CD
How this gets built
- 01
API contract first
The shared contract is agreed before client work starts, so web and mobile can progress in parallel without blocking each other.
- 02
Web first, then apps
The web surface usually ships first — it is faster to iterate on, it starts earning search traffic immediately, and it validates the API before store review enters the picture.
- 03
Store release as a workstream
Apple and Google review timelines, signing, versioning and staged rollout are planned rather than discovered a week before launch.
- 04
One release rhythm
Web and mobile ship on a coordinated cadence against the same API version, so customers never see two versions of the truth.
Typical stack
Worth knowing before you write.
A short, honest filter. It saves both of us a call that was never going to work.
A good fit if
- You have a real business or a funded idea, and a decision-maker in the room
- The product has to handle money, roles, or operations correctly — not just look good
- You want one senior engineer accountable end to end, not a rotating team
- Arabic and English both matter to your market
- You can give a few hours a week to reviews and decisions
Not a fit if
- You need a team of ten starting Monday — that is an agency's job, not mine
- The budget is fixed before the scope exists and cannot move
- You are looking for the cheapest possible quote rather than the right build
- Nobody on your side can answer product questions within a few days
- You want equity-only work or an unpaid prototype
What you get in the first call
Fifteen minutes, free, no deck.- A straight answer on whether this is buildable the way you imagine it
- The two or three decisions that will drive most of your cost
- A rough shape: phases, surfaces, and where the risk sits
- An honest ballpark range — or a referral if I am not the right fit
What to prepare
None of it has to be polished.- One sentence on what the business does today
- The workflow that hurts most, described in plain language
- Who needs to log in, and what each of them does
- Any deadline that is real, and why it is real
- A budget range you are comfortable discussing openly
Answered straight
- Flutter or native Swift/Kotlin?
- For most startup and business products, Flutter wins: one codebase, two platforms, one release rhythm, and no perceptible difference to users. Native earns its extra cost when you need deep platform hardware work — advanced camera pipelines, background location at scale, or platform-exclusive APIs. That answer is given per product, not as a rule.
- Can the web app and the mobile app share business logic?
- They share it where it belongs — on the server. Pricing, permissions, order state and payment rules live in the API, so clients render decisions rather than make them. That is what keeps the two surfaces honest with each other.
- Do you handle app store publishing?
- Yes — build signing, store listings, review responses and staged rollout, published under your own developer accounts so the apps remain yours.
- Is Arabic RTL fully supported in the apps?
- Yes, and it is designed in rather than mirrored at the end — layout direction, typography, numerals, dates, icon direction and text input all get treated as first-class in both languages.
Written for buyers, not for engineers.
Need a product on every device?
Tell me which surfaces you actually need at launch. Often it is fewer than you think — and that is the cheapest advice on this page.