How to Estimate a Digital Project in 2027? It’s not the code that breaks the budget

When a digital project goes sideways, people often blame the technology: "it was more complicated than expected." Almost never. What costs more than expected are the things that weren't in the estimate.

In an estimate, you find screens, features, and a number of development days. You much less frequently find the time spent making decisions, waiting for approval, migrating content, or handling what happens after launch.

Here is how I read an estimate, and the four items I look for first.

1. 1. Decision-making time: The invisible item

An engineer estimates what they know how to build. They do a poor job of estimating how long your teams will take to make a final call.

Every screen raises questions: What happens if the customer doesn't have an account? Who approves this text? What rule applies to this specific edge case? Until someone answers, the project is on hold. The provider still bills for their team, or reassigns them elsewhere and comes back later.

A project delivered quickly is almost always one where the scope was already decided. Angela, in Réunion, had a no-code prototype to migrate to a real React Native codebase. The decisions were already made because the prototype contained them. Delivered in 19 days, complete source code and full Git history handed over.

For Tom, who had no technical team and started from a blank page, a complete iOS and Android application took 4 months. That is not slow. For this scope, the French market typically ranges between €40,000 and €100,000. But those 4 months contain hundreds of small decisions that had to be made together.

So, ask your provider to list the decisions they expect from you, with a deadline for each one. If the list is empty, that's a bad sign.

2. 2. What depends on a third party

Your project almost always touches a system that neither you nor your provider controls: an app store, a payment gateway, an ERP, an email delivery service.

Makan had a mobile application blocked by a complication during submission to Apple's App Store. Apple stubbornly insisted on classifying the project as sports betting when it was simply a friendly game with no money involved, even going so far as to demand official authorization from FIFA. With no other way forward with the store, the team persevered by adjusting and resubmitting the file until it was approved. This event led us to revise our contracts to formalize responsibility for delays caused by third parties. In an honest estimate, this type of risk appears as a standalone line item, not as a mere technical detail.

Starting today, for every external dependency, ask: "If this third party refuses, delays, or changes its rules, what do we do, and who pays?"

3. 3. Content, data, and user acceptance testing (UAT)

An empty website or application is useless. You have to put texts, images, products, and customer accounts from the old system into it. This work is almost always assumed to be "at the client's expense," only to creep back into the invoice or schedule later.

There is also the testing phase: testing, correcting, retesting, and validating legal and technical compliance (such as drafting Terms of Service to govern user data processing, keeping GDPR in mind, which remains the primary question for a European buyer). It is rarely accounted for at its true scale because it produces nothing visible.

Therefore, demand that the estimate separates three distinct lines: construction, content/data migration, and acceptance testing. If they are lumped into a single line, you cannot evaluate or arbitrate.

4. 4. The post-launch phase

This is the most underestimated item, and the one that decides whether a project lives or dies.

A live product requires hosting, security updates, bug fixes, and adjustments after the first real users arrive. Antony, from Limescribe, needed fixes post-launch (file validation, cleaning up a scheduled task). This is not a failure: it is the normal life of a product. But if this item is not budgeted for, it arrives at the worst possible moment—in the form of an emergency.

Relationships that last prove this. Urbidesk has worked with us for several years, long after the initial delivery of their platform. A project is not a single event; it is a beginning.

In practice, ask for the cost of Year 2 before signing Year 1.

5. How to build an estimate that holds up?

Rather than a single figure, ask for three scenarios: low, probable, and high. The gap between them is valuable data: the wider it is, the fuzzier the scope, and that is where risk hides. A provider who gives you a single, highly precise number on a vague scope is not protecting you; they are hiding the uncertainty.

Next, break the project down into short deliverable batches with a demonstration at the end of each batch. You can see progress on something concrete, and you can redirect before mistakes become costly.

To compare two quotes, bring them to the same scope. On the labor side, a developer generally costs between €350 and €800 per day in France. Our public rate ranges from €150 (junior) to €300 (senior), working remotely with a time zone offset of one to two hours from France depending on the season. The price gap is real, but it doesn't replace the four questions above. A cheaper quote that forgets the four items ends up costing more in the end.

Finally, look at what protects your timeline. With us, every working day of delay automatically reduces the price by 5%, and we offer a 100% refund if a project interruption originates on our end. Additionally, revisions are unlimited until compliance with the validated brief is achieved. No matter how you choose your provider, demand a written commitment on these two points.

6. What changes in 2027

AI coding assistants continue to progress, and it is tempting to assume everything should cost much less. Caution: these tools mostly help write code, and code was never the part that caused projects to drift. Deciding, depending on third parties, migrating, testing, maintaining: none of these disappear with a tool. We do not yet have documented benchmarks that allow us to quantify a cost reduction, so we do not promise price drops on this basis. Beware of anyone promising one without being able to show a real project.

In short, before signing, check that your estimate contains: decisions expected on your end, external dependencies, content/data migration, acceptance testing, and the cost of Year 2. If any of these four are missing, the estimate isn't just wrong—it's incomplete, and you will pay the difference later.

If you have a project currently being estimated and have doubts about any of these points, send me a direct message. I'll tell you honestly what I see.