Skip to content

How long does it take to build a mobile app? A four-week release, week by week

A landlord app went from an empty project to a public release in about a month. What each week held, why it fit, and what that month left out.

By Karan MaliCo-founder, Engineering & architecture

Published 4 min readShareHow long does it take to build a mobile app? A four-week release, week by weekLinkedInXWhatsAppEmail

A phone app built on top of a backend that already existed.
In this article5 sections
  1. What the four weeks contained
  2. Why it fit in a month
  3. The bug a fast schedule can hide
  4. What the month did not include
  5. How to estimate your own app

On 2 March 2026, the landlord app was an empty Expo project. By 26 March it could sign landlords in, list their properties and units, create leases in steps, issue and track invoices, invite team members with roles, show its labels in English and Arabic, and produce signed release builds from CI. About a month after that first log entry, it was public.

I was one of four developers at a property-management startup that began in Kuwait. That month is a useful answer to the question in the title, mostly because of what it leaves out.

What the four weeks contained#

The team kept a dated development log. Here is what each stretch of it covers.

  1. 2 Mar
    FoundationsExpo 54 and React Native 0.81, sign-in with token refresh, routing, properties and units, reusable forms.
  2. 3 to 5 Mar
    Leases, invoices and teamsLists, details, create and edit; mark paid, archive and remind; stepped lease creation; members, invitations, roles and property access; English and Arabic labels.
  3. 8 to 12 Mar
    The details that carry moneyContact and phone fields, payment forms, receipts, invoice dates and delegation, validation and commercial variations.
  4. 14 to 18 Mar
    Parity with the web appScreen-by-screen comparison, unit and profile editing, full-page invitations and a tracked list of remaining gaps.
  5. 22 to 26 Mar
    Release engineeringSigning, separate development and production apps, account-scoped requests, cache clearing, Fastlane builds packaged by GitHub Actions.

On 26 March the log still listed store upload and environment tasks. The public release followed.

Why it fit in a month#

The backend already existed#

The app called the same APIs as the web product. Leases, invoices, permissions and payment rules already lived on the server, and landlords were already using them on the web. The phone didn't need a second backend, so the month went into the interface and the release.

If you remember one thing from this article, make it this: an estimate depends more on what exists behind the screens than on the number of screens.

The screens were adapted for a phone#

Dense web tables became invoice rows that expand when tapped. Lease creation became a form in steps, and the server calculates the invoices a lease generates. The phone never re-implements the money rules, so web and mobile calculate a lease's invoices the same way.

Arabic arrived in the first week#

English and Arabic labels went in between 3 and 5 March, alongside leases and invoices. Arabic reads right to left, which changes layout as well as text. Adding it in week one meant every later screen was built for both languages from the start.

Release work got its own week#

Signing keys, separate development and production apps, Fastlane builds and CI packaging took most of the last week. The team also prepared a written explanation for Apple's review describing the app as a companion for businesses already under contract with the company. None of this shows up in a demo, and all of it has to exist before anyone can download the app.

The bug a fast schedule can hide#

A landlord can belong to more than one account. When they switch, the app has to clear two caches: the one in memory and the one saved on the device. Miss either, and the next account's screens can show data from the previous one.

The app sends the active account ID with every request and clears both caches on account switch, logout and expired sign-in. The server's permission checks still decide what anyone can see.

This kind of bug never appears in a demo with one test account. If you are commissioning an app where one person can hold several accounts or roles, ask how the estimate handles it.

What the month did not include#

The work kept going after release. By June and July the app had gained:

  • unread counts per participant in maintenance conversations;
  • reply permission separated from management permission;
  • bills and expenses matching the web app, with expense payments and bill payments kept apart;
  • an audit trail.

A month bought a first release that landlords could use. Budget for the months after launch as well as the month before it.

How to estimate your own app#

Bring answers to these questions to any estimate, ours included:

  1. Does a backend with your business rules already exist, or will the app be the first place those rules live?
  2. How many kinds of user are there, and can one person hold more than one account or role?
  3. Which languages do you need at launch, and does any of them read right to left?
  4. Does money move inside the app, such as payments, deposits, refunds or invoices?
  5. Do you already have store accounts, signing keys and a clear explanation for app review?
  6. Who decides scope when a web screen doesn't fit on a phone?

Each "not yet" adds time, because that work has to happen somewhere. For the budget side of the same questions, see app development cost in India.

Saumya and I now run The Useful Company, a two-person product studio. If you have a web product and want the app, or an idea and want to know what a first month could include, send us the details. We'll tell you what we'd build first and what we'd leave for later.