Planning
Every custom app development conversation eventually gets to cost and timeline, and the honest answer is always "it depends" — but it depends on a specific, knowable set of variables, not on vague complexity. Understanding those variables is more useful to a founder than any single number, because it tells you which decisions actually move your budget and which don't.
Number of platforms (one vs. two vs. web-plus-mobile) multiplies engineering surface area directly. Backend complexity — a simple CRUD API versus real-time features, complex business logic, or heavy data processing — is often a bigger cost driver than the UI itself. Third-party integrations (payments, maps, video calling, AI features) each bring their own setup time, ongoing cost, and edge cases. How much design work exists before engineering starts matters enormously: a team building from finished, detailed designs moves far faster than one figuring out layout and interaction decisions mid-build. And regulatory requirements — healthcare data, financial services, anything with a compliance framework attached — add real, non-optional scope.
These are general ranges, not guarantees for any specific project: a simple, single-platform MVP with a managed backend typically runs six to ten weeks from a finished design to a submittable build. A two-platform app with real backend logic and a couple of integrations more typically runs ten to sixteen weeks. A complex product — multiple integrations, custom AI features, non-trivial compliance requirements — commonly runs four to six months or more. Every one of these bands assumes design is largely settled before engineering starts; unresolved design decisions mid-build are one of the most reliable ways to blow past any of these ranges.
It's also worth separating the cost of the initial build from the cost of validating the idea. A founder who needs to know whether people want the product at all is often better served by a narrower, cheaper first version than by a fully-realized one — spending toward the top of a timeline band before there's any real usage data is a bet, and it's worth being deliberate about how large a bet you're making before real users have told you anything.
A fixed-bid engagement gives budget certainty but only works when scope is genuinely well-defined up front — any ambiguity gets priced as risk by whoever's quoting it, which usually means a higher number than the work would cost under clearer scope. Time-and-materials is more flexible as the product evolves but requires more active budget management from the client. A short, paid discovery or scoping phase before committing to either structure reduces risk on both sides: it turns vague requirements into a real spec before real money is committed to a build.
The sequence that tends to hold budgets closest to their estimate: a short discovery and scoping phase to nail down the actual MVP feature set, a design phase that resolves the UI before code is written against it, engineering delivered in vertical slices (a complete, testable feature at a time, not "all the backend, then all the frontend"), an internal beta before public release, and a submission buffer that assumes at least one round of App Review feedback rather than a same-day approval.
The cost conversation often stops at launch, but OS updates, store policy changes, and third-party SDK updates are a recurring maintenance surface, not a one-time expense. Apple and Google both ship annual OS updates that periodically require code changes to stay compliant (a new minimum SDK requirement, a deprecated permission model, a new privacy disclosure). Budgeting a modest ongoing maintenance allocation — even a few hours a month for a simple app — avoids the common trap of a product that worked perfectly at launch quietly breaking a year later when nobody's watched it.
A vague estimate isn't dishonesty — it's often the most honest answer available before scope, design, and integrations are actually locked. Getting those three things nailed down early is what turns a range into a number you can actually plan around.
More from the journal
App Store
Apple rejects a meaningful share of first-time submissions, and it's rarely the exotic reasons founders worry about. Here's what actually trips people up, and how to submit clean.
Launch
Launch day is the easy part. The work that determines whether it goes well happens weeks earlier — here's the sequence we actually follow.
Engineering
Cross-platform frameworks have closed most of the historical gap with native — but not all of it. Here's the actual decision framework, not a philosophy war.