Why App Projects Slip: How to Write the Schedule and Penalty Clauses

Ask ten companies that have commissioned software and eight will report an app development delay. Schedule slippage is the most common complaint in custom development, and it is rarely one party's fault. Review real projects and you find delays usually come from five causes stacking up. At least three of those five can be dismantled at contract-signing time.

This article works on two levels: first, where delays actually come from; second, how to write the schedule clause so that when a delay happens both sides have something to point at instead of recriminations.

1. Five real causes of an app development delay

Ordered by how often they appear in our project reviews:

• Requirements change mid-build. The most frequent cause. Changing one field looks like ten minutes of work; in practice it touches the API definition, the UI screens, the test cases and the regression run. A change without a written change order will almost always push the schedule back.
• Slow client decision chains. Design approval, copy review, company seals on qualification documents — every wait consumes schedule time, yet contracts usually classify these as "client-caused" and the vendor carries no responsibility.
• Third-party lead times. Payment channel onboarding, SMS signature filing, map and identity verification reviews, software copyright registration, app store review. These run on external calendars. Overtime at the vendor does not move them.
• Optimistic estimates. Many quotes are built on the assumption that everything goes smoothly, with no buffer for integration, defect fixes and regression. A schedule with no buffer makes delay an outcome, not an accident.
• Key people leaving. When a vendor's project team changes mid-flight, the replacement has to read the code and relearn the business. That period produces almost nothing.

Of the five, the first two are process problems that contracts and mechanisms can control. The third can only be planned around, never compressed. The fourth and fifth test the vendor's professionalism.

2. Four things the schedule clause must pin down

Many contracts contain a single line: "construction period: 90 days." That is close to no agreement at all. A workable clause pins down at least four items.

Start date. State exactly when the clock starts. A common formulation is "whichever is later of the date both parties sign the requirements confirmation and the date the first payment arrives." Without this, the vendor may count from contract signing and the client from the date materials were handed over — a gap of a month.

Working days or calendar days. Mixing these two terms is the single most common source of dispute. Ninety calendar days contain weekends and public holidays, leaving roughly 60 working days — a third less work. Standardise on working days and state explicitly whether statutory holidays extend the period.

Milestones and staged delivery. Break the total period into four to six milestones, each with a verifiable deliverable and a payment point. The value is not only payment control: a slip shows up at the first milestone instead of in the final week.

Penalties and extension rules. Treat vendor-caused delay and client-caused delay separately. The first carries a per-day penalty; the second extends the schedule after written confirmation. Common market practice for the penalty is 0.03-0.1 percent of contract value per day, capped at 5-10 percent of the total. Treat those figures as a reference point to negotiate, not a template to copy.

3. Three problematic clause patterns

"All delays caused by the client shall extend the schedule accordingly." The principle is fine; "all" is too broad. List the extendable situations one by one — requirement changes, late materials, overdue confirmations, third-party review delays — and require a signed written record for each extension.

Acceptance with no deadline. The contract names a delivery date but never says how many working days the client has to accept. The client then stalls, the vendor cannot collect the final payment and cannot prove on-time delivery. Specify: "the client shall respond within 10 working days of receiving the deliverable; no response within that period is deemed acceptance."

Defect fixing counted against the schedule. Problems found in testing should be fixed by the vendor, but the fixing time should not be folded into the delivery period without limit. Separate "functional defects" from "new requirements": the vendor fixes the former within an agreed window, the latter goes through the change process with its own quote and extension.

4. When a delay has already happened

Once a project is late, sequence matters more than blame:

• Re-list the remaining work, split it into "must ship" and "phase two", and cut scope to the smallest set that can be delivered.
• Confirm the new delivery date in writing with both signatures. A chat message saying "next week" is not a commitment.
• Check whether paid amounts match completed milestones, so payment does not continue at the original rhythm while progress lags.
• Demand verifiable weekly output — a runnable build, a testable package — not a percentage.

"Eighty percent done" means nothing in a software project. The only question that answers progress is whether a given feature runs today.

5. Reading the signs four to six weeks early

An app development delay is rarely sudden. It usually signals four to six weeks ahead. Any two of these signs should trigger intervention:

• Two consecutive iterations produce no runnable build, only documents or screenshots.
• Integration keeps being pushed back and the APIs are always "ready next week".
• Third-party filings, registrations and reviews have never been started.
• The project team's core members change and the newcomers cannot answer basic business questions.

None of these needs technical judgement. All four are visible from deliverables and a few questions. Weekly checking of exactly these signals is most of what project management consists of.