Technology choices — questions we get asked
These come from founders who have been asked to pick a framework, a backend or an AI feature before anyone asked what the business needs. Behind them is a fear of choosing wrong and paying to rebuild. We choose technology by what it means for you: what it costs, how fast it ships, and whether another team can maintain it.
9 questions · answered by Taimoor Sikander, founder
What do you build with?
Flutter for the mobile apps, which means one codebase for iOS and Android instead of two. That keeps the build and every later change cheaper, because a fix is written once, not twice. The other parts are chosen for your platform and for a team that can be hired after us, and we explain those choices, and why, during scope.
Native or cross-platform?
Cross-platform for almost every marketplace; native only where hardware or performance demands it. We explain the trade-off for your case. Native means a separate app for iOS and another for Android, each built and changed twice. Cross-platform means one codebase for both, which for a marketplace of forms, maps, bookings and payments is the better use of your budget.
Do we need an iOS app and an Android app?
It depends on three things: which phones your customers use, which phones your providers use, and whether one side can work on the web instead. With Flutter, both apps come from one codebase, so the second app is far less work than the first. Where your market is mostly one kind of phone, launching there first is an option.
Do we need a separate app for providers?
Usually yes. Customers and providers do different jobs: one books and pays, the other accepts work, updates the job and gets paid. Putting both in one app makes each side harder to use. Some marketplaces start providers on a simpler web app and add a full provider app later; we tell you in scope which fits yours.
Do we need a website as well as apps?
A public site helps discovery and trust; the admin console is web regardless. We tell you if you can skip it in phase one. Providers and partners often look for a website before signing up, and search engines cannot see inside an app. If customers should be able to book on the web, that is its own piece of the build.
Should we use a marketplace template instead of a custom build?
Use a template if it covers your model, and a custom build if it does not. Templates are quick to start and hard to bend, especially around payouts, local payment rails and provider rules. If one fits your marketplace, we will say so, even though it means we do not build it. If your model depends on how money moves in your market, custom is usually worth it.
Will the apps work on slow connections?
It depends on three things: which actions must work with a weak signal, how old your users' phones are, and how often the data changes. Viewing a booking can work on a poor connection; taking a payment always needs one. We ask about connections in your market during scope, because a platform tested on office wifi can fail on a rider's phone.
Do you use AI in the build?
As a tool, not as the product. We do not sell AI as the reason to hire us. Engineers use it the way they use any other tool, and the engineer building your platform is still responsible for every part of it. What you are paying for is judgement: what to build, what to leave out, and what will break.
Can you add AI features to the platform?
Yes, where they earn their place: matching, support triage, fraud signals. Priced as scope. Matching suggests the right provider for a job. Support triage sorts incoming messages so urgent ones are seen first. Fraud signals flag unusual payments or accounts for your team to review. If a feature would not change a number you care about, we will tell you to leave it out.
Plan your build in two minutes.
No call. A few guided questions, then a tailored quote — usually within one business day.
Or send us the idea in three sentences on WhatsApp, or email support@codingwitht.com.