The most expensive sentence in IT? “We will do it later”
In many projects, the largest costs begin with postponed decisions, not bad technology. An innocent “we will do it later” can turn a straightforward project into expensive chaos.
The full article is available below. Enable JavaScript to use quizzes and simulations.
The most expensive sentence in IT? “We will do it later”
In meetings about new websites, stores, systems and applications, one sentence appears more often than it should: “We will do it later.”
It comes up around contact forms, blogs, SEO, user roles, security, integrations and administration panels. It almost always sounds reasonable: you cannot do everything at once.
That is true. You cannot.
The problem begins when “later” is not a deliberate decision but a way to avoid a difficult conversation now.
The project does not become simpler. It merely defers the bill.
Why this sentence is so dangerous
It creates an illusion of progress. The team moves on, screens take shape, initial views work and a demo is ready. Everyone feels the project is advancing.
But some decisions do not disappear. They wait. When they return, the system is larger, dependencies are more numerous and costs are higher.
It is like renovating a house. If you do not plan the wiring at the start, you are not “adding one little cable” later. You are breaking open walls.
Digital projects work the same way.
What “we will do it later” really means
Usually one of five things:
- We have not agreed on the goal yet.
- We do not know who will use it.
- We do not want to make an architectural decision now.
- We hope the problem will resolve itself along the way.
- We want to deliver a screen sooner, even if we pay twice later.
None of these reasons necessarily spells disaster. But each needs to be understood. The difference between a sensible MVP and future chaos is not whether you postpone something. It is whether you know from the start what can wait and what must not be built as a stopgap.
Where “later” hurts most
1. Content structure and navigation
Many companies say, “Let's build the site first and sort out the content later.” It sounds harmless. In practice, it produces an attractive interface without clear communication.
A visitor still does not know:
- what exactly you do,
- who your offer is for,
- why they should trust you,
- what to do next.
The problem is not the design. The site looks good but does not guide its users.
2. Administration panels and independent management
“We will add content manually for now and build the panel later” is one of the most expensive sentences in business websites, blogs and portals.
While there is little content, it works. Then someone needs to:
- add a post,
- edit a page section,
- change photographs,
- update SEO,
- publish another language version.
Suddenly, every small change needs a developer. That is not just a cost; it slows the whole business.
3. Integrations and data flow
The same applies to forms, CRM, payments, automation, booking systems and analytics.
At first, people say, “Let's not connect it to anything yet; we'll see later.” By later, data already lives in several places, processes are manual and errors have become hard to see.
You are no longer building an integration from scratch. You are undoing habits and temporary processes that have become everyday practice.
4. Permissions, security and roles
The classic line is: “We don't need detailed roles at the start. Everyone can have access.”
Until they cannot.
Until someone accidentally deletes content, sends something to the wrong place, sees data they should not or uses the system in a way nobody anticipated.
Security rarely harms a project on the day it is postponed. The consequences arrive later, when it truly matters.
5. Performance, SEO and scaling
Many sites and applications work well while traffic is low. Users do not judge a system's potential, though. They judge what they see now.
If pages load slowly, mobile works poorly, a form freezes on a phone or content is badly structured for search, the first impression is already lost.
Rebuilding that impression later can cost much more than planning a few things at the beginning.
The key distinction: not everything must happen now, but not everything can wait
That is the point.
A good project does not do everything at once; that would be inefficient. It distinguishes two things from the outset:
what can wait,
and
what needs a sound foundation today.
MVP does not mean “anything will do, as long as it is fast”.
An MVP is the smallest coherent product version that makes business and technical sense.
You can postpone extra animations, elaborate sections, advanced reports and less important integrations.
But you should not postpone:
- the logic of the site or product structure,
- how content will be managed,
- basic security principles,
- the data model,
- the flow of key user actions,
- how the system will evolve in a month, six months and a year.
These are the places where either future stability or future chaos begins.
How to make better decisions at the start
Before a project begins, ask a few simple questions:
1. What should this system actually do for the business?
Be specific. Generate leads? Sell? Organize customer service? Automate work?
2. Who will use it?
The owner, sales team, editors, administrator or end customer? Each has different needs.
3. What will change most often?
If the answer is content, images, posts, offer sections or SEO, the administration panel is a foundation, not an extra.
4. Which process must not fall apart?
Contact? Booking? Payment? Leads? Publishing? That process deserves the strongest design.
5. What happens if the project grows?
Can new pages, roles, languages and integrations be added without dismantling everything?
These questions do not slow the project down. They save months of rework.
The most expensive part of a project is chaos, not code
Code can be improved. Servers can change. Designs can be refreshed. Sometimes even the technology can be replaced.
The greatest cost is the chaos that grows when nobody clearly states:
- why this is being built,
- how it should work,
- who will manage it,
- what truly matters,
- and what is merely an extra.
The project starts to resemble a beautiful building whose doors, cables and utilities were never planned.
It looks good outside. Inside, people work around problems every day.
Good technology starts with decisions
With a decision.
With a good question.
With the right priority.
With the courage to avoid saying “later” where a decision is needed today.
In many projects, the final result is not destroyed by a lack of budget, people or tools.
It is undermined by a series of small postponed decisions that grow into one large problem.
That is why the best projects rest on sound foundations rather than random patches.
If you are planning a website, store, portal or application, begin with a different question from “how much will it cost?”: which decisions must we make now to avoid paying twice in six months?