How long does a business app take to build? Nine published timelines, and where the weeks go.

Ask nine UK studios how long a business app takes and you will get answers that span a factor of fifteen, and all of them will be honest. The spread comes from what each studio means by "app": a single-process internal tool for a trades firm, a multi-user platform with integrations, or a consumer product going through two app stores with payments. It also comes from what each counts as the start and the finish. Some clocks begin at the first call; some at signed scope; some stop at the first usable version and some at store approval.

So we read every UK agency page that publishes timelines in 2026, recorded each figure with what it describes, and lined them up by app type. Then we took the two sources that publish where the time goes phase by phase and used them to build a week-by-week plan for a four to six week build, so you can see what has to be true for a short timeline to be real rather than a sales claim.

One number to hold on to: on a typical build, the studios that show their working put engineering at only 30 to 40 per cent of the calendar. The rest is scoping, waiting on other people’s systems, testing and launch. That is where a timeline is won or lost, and it is also the part a buyer controls more than the supplier does, which is why the last sections of this guide are about what you can do rather than what we can. Every figure below is from a named page with a date; we have not estimated anything ourselves.

Read on 14 September 2026. Where a page gives one figure for a tier and a different figure elsewhere in the same article, both are recorded, because the inconsistency is itself informative: it usually means the shorter figure describes the engineering and the longer one describes the whole project including the client’s decisions. Clutch is the only non-UK source and the only one drawn from a survey of many projects rather than a studio’s own work, so it is included as a ceiling rather than a benchmark.

Clutch’s figures describe projects reviewed on its directory worldwide, mostly larger than a UK SME build. The rest are UK studios describing their own work or the UK market.

Once the labels are lined up, the market agrees on three bands. The bottom band is a single process with one or two roles and one integration: one to ten weeks, with most UK studios inside three to eight. The middle band is a full business application with several user types and integrations: four weeks to six months, and here the spread is real, because SWF and Jabu are describing small teams building against a fixed scope while Red Eagle and Graphene are describing larger builds with a longer discovery. The top band is anything consumer-facing, store-published or regulated: three months to a year and beyond.

The outlier is Make IT Simple, whose "small" system takes three to six months. Its page is explicit that everything is built from scratch with no framework at the core, which is a legitimate choice and a slow one. The other outlier is Clutch’s eleven-month average, which describes the projects on its directory, and the average project there costs over $90,000. Neither is wrong; neither describes a UK SME buying its first internal tool.

What actually moves a project between bands is not lines of code. It is the number of parties whose approval or systems the project waits on. A single-process tool waits on one decision maker. A business application waits on the owner of every system it integrates with. A store-published app also waits on Apple and Google. Each extra party adds calendar time that no amount of engineering effort removes.

Red Eagle publishes phase durations for a standard app and Tappable publishes the share of the calendar each phase takes on a three to four month build. They describe the same shape from two angles, and it is the most useful data in this guide because it tells you which phases compress and which do not. Building compresses with a smaller scope and better tooling. Discovery compresses only if the client has done the writing down. Integrations and store review compress hardly at all, because their clock belongs to somebody outside the project.

Studio Graphene’s figures for a larger build: discovery three to eight weeks (40 to 80 hours of work), design three to four weeks, development three to six months, testing two to four weeks, deployment one to two weeks. App Store review two to seven days, Google Play three to six days.

Apply Tappable’s shares to a thirty-working-day calendar and the arithmetic is unforgiving. Scoping and design at 15 to 20 per cent is four to six days. Core build at 30 to 40 per cent is nine to twelve days. Integrations at 15 to 25 per cent is five to eight days. Testing and content at 15 to 20 per cent is four to six days. Launch at under 5 per cent is a day or two. It adds up, but only if nothing waits. Here is what the six weeks look like when they work, for an application with three user types and one integration.

Tappable’s summary is the one worth memorising: decisions, integrations and approvals set the date, not the engineering. The published phase data explains why. Engineering is 30 to 40 per cent of the calendar and the only phase entirely inside the supplier’s control. The other 60 to 70 per cent waits on somebody: the client for decisions, a vendor for API access, Apple for a review, a department for test data.

Discovery is the first place a timeline is lost. Studio Graphene puts it at three to eight weeks and 40 to 80 hours of work; Red Eagle at two to four weeks. That time is spent finding out what the process actually is, which is cheap if it is written down before the first call and expensive if it is discovered during the build. Integrations are the second. Red Eagle prices an integration alone at £5,000 to £50,000, and the range is that wide because the other system’s API quality decides it, not your supplier. Store review is the third for mobile products: short when the app is complete, and a loop of resubmissions when it is not.

Adding people rarely helps. Small projects get slower when the team grows, because coordination cost rises faster than capacity, and a project that is waiting on an API key does not wait any less with a second developer watching. Removing decision latency on your side is almost always the bigger lever, and it costs nothing. The scope is the other lever. Tappable’s note on MVPs applies to every build: six to twelve weeks if the scope is genuinely minimal, and the word doing the work is minimal. Every feature added after the scope is signed is added to the calendar as well as the price.

The shortest timelines in the table are from the pages written most recently, and that is not a coincidence. SWF states that projects which previously took three months now take three to four weeks, and attributes it to AI-assisted development reducing delivery time by around 80 per cent. That is the firm’s own claim about its own work; we have no independent measurement of it, and the honest way to read it is that the engineering share of the calendar has shrunk for small, well-scoped builds, while discovery, integration and approvals have not.

That gives you a test for any short timeline. Ask the studio which phases it has compressed and which it has not. A credible answer names engineering and testing as faster and names integrations, third-party access and your own decisions as the parts still on the old clock. A studio that claims the whole calendar has shrunk by 80 per cent, including the parts it does not control, is quoting the demo rather than the Tuesday.

Everything in the published data says the same thing from different angles: the supplier controls a third of the calendar and the buyer controls most of the rest. That is good news, because the buyer’s part is cheap. None of the steps below costs money and each removes days or weeks from the phases the studios describe as client-gated. Do them before the first call rather than after the scope is signed, because week zero is the only week that does not appear on any invoice.

Since we are a row in the table: a single process in one to two weeks, a business application in two to four, a platform with mobile apps in four to six, each phase at a fixed price against a written scope with an explicit list of exclusions. Every phase is two to six weeks by design, because anything longer than that has stopped being a phase and started being a programme, and programmes are where timelines go to die. The short figures assume week zero has happened: a named decision maker, a written process and access requests already sent. When it has not, we say so in the quote and the timeline says so too.

Progress is shown as working software at the end of every week rather than as a status report, because a demo cannot hide a slipped phase and a report can. Acceptance criteria are written before the build starts, so finished is a fact rather than an opinion, and the last week of every phase is handover: documentation, credentials, a runbook and a recorded walkthrough, so another developer could pick the system up without calling us.

We searched Google UK for the question and its variants on 13 and 14 September 2026 and read every UK studio page on the first pages that publishes timelines, plus Clutch’s directory data. Each figure was recorded with what it describes and its date; where a page gave two figures for the same tier, both are shown. Bands are the overlap of the majority of sources, with outliers explained rather than dropped. The worked plan applies Tappable’s published phase shares to a thirty-working-day calendar; it is an illustration, not a client schedule. App Store review figures are as quoted by Tappable and Studio Graphene. The date at the top of this page is the date of the last check.