How much does it cost to develop an idea? The question almost everyone answers incorrectly

Not long ago, I spoke with the CEO of a pre-seed proptech startup. He was not one of those business-school entrepreneurs, former Big Four consultants without a single battle scar to show, nor someone who had always had the wind at his back. He was self-made, with an enviable history of fighting his way forward... He had spent many years working in real estate and knew exactly where the industry was losing time, money and opportunities. He had identified a real problem, spoken with customers, analysed the competition and built a fairly convincing prototype. In other words, he had done almost everything expected of a good founder... There was only one question left to answer. Curiously, even for someone who was an expert in his own business, it was almost impossible to answer:

—Rafael, how much will it cost to develop this?

“This”, his project, was a platform capable of connecting the different players in the real-estate market, centralising information, automating processes, generating documents and incorporating artificial intelligence. These days, it almost seems embarrassing to develop software that does not include AI. A startup without artificial intelligence somehow feels incomplete or, even worse, “old-fashioned”... even when it adds no real value for the user and merely makes the solution more expensive.

Before speaking with me, he had already requested several proposals, while also following a condition imposed by his future investors: the team had to work exclusively for him, allowing direct hiring, AOR or other models that fully respected his direction and management. One company claimed it could build the platform with two developers in a few months using a traditional methodology. Another submitted a considerably higher proposal involving a multidisciplinary team working under Scrum and led by its own technical lead. A third company refused even to commit to a figure before completing an initial phase of analysis, product definition and architecture. The curious part was that all three had received exactly the same PowerPoint presentation, the same starting conditions and the same explanation of the project... and yet their estimates ranged from €150,000 to €500,000, while the delivery times varied between four and twelve months.

His conclusion was immediate:

—Someone is trying to take advantage of me.

My answer was slightly less reassuring:

—Probably not. The problem is that each provider is imagining a different product.

And that is where the real problem with software estimation begins.

When you buy software, you still do not know exactly what you are buying

Since this CEO came from the real-estate industry, I tried to explain the situation using an example he understood well.

When you buy a property, you can visit it, measure it, study its location, inspect its condition and compare it with similar assets in the area.

When you construct a building, there are plans, measurements, materials, regulations and relatively well-known processes. Before construction begins, an architect has defined what is going to be built.

In software, when someone requests the first estimate, none of that usually exists.

We have an idea. Some features. A few screens. A document. And, with luck, a Figma prototype in which everything works perfectly...

Because it does not actually do anything yet.

There is no definitive architecture. We do not know all the integrations. No decision has been made about how the data will be managed. We do not know what level of security will be required. Nor do we know the actual number of users, the expected performance, the availability requirements or the problems that will emerge when the product comes into contact with real customers.

And they will emerge...

An initial estimate does not calculate the price of a fully defined product. It attempts to anticipate the cost of hundreds of decisions that have not yet been made.

The mistake is expecting it to have the same precision as a quotation for renovating a property.

We can produce a rigorous estimate. We can analyse risks. We can calculate a reasonable range. But we cannot predict the future...

Two applications that do the same thing... but do not cost the same

Imagine two proptech platforms.

Both allow users to register properties, manage owners, store documents and review transactions. From the outside, they look practically identical.

The first is designed to validate the business model with ten estate agencies in Madrid. It can initially rely on some manual processes, use external services and accept certain technical compromises to reach the market sooner.

The second must operate in five countries, integrate with different CRMs and ERPs, manage sensitive information, meet regulatory requirements, support thousands of transactions and remain available twenty-four hours a day.

Both have a login screen. Both manage users. Both store documents. Both display properties. But they are not the same product.

One is a tool for learning. The other is the infrastructure on which a company will operate.

Software does not cost money only because of what it does. Its cost depends on the conditions under which it must operate, how long it must last, how it will need to evolve and the consequences if it stops working. And this information rarely appears in the client’s PowerPoint presentation or feature list...

The market has an answer for every taste

When a founder tries to determine how much a product will cost, the market offers several possible answers.

All of them can be valid. And all of them can cause a disaster when used without understanding their limitations.

1. The fixed-price proposal

This is the preferred alternative for many clients, especially those with a financial background or working in procurement departments.

A document containing the requirements is delivered, the provider responds with a figure and both parties sign a contract. The client believes the uncertainty has been eliminated. The provider believes it has understood the scope. It is a good way to summon Murphy... the one from the law... not Charles Bronson.

For a few weeks, everyone sleeps peacefully... Then the project begins.

Needs emerge that nobody had anticipated. Some features are more complex than expected. The integrations do not work as promised in the documentation. Users express their opinions. The market changes. And the founder discovers that what they requested four months ago still does not exist and, even worse, some things are no longer the way they originally defined them.

That is when the real development begins... The development of the contract.

Was that included? Is it a change in scope? Who pays for the modification? Was a mobile application included, or did someone merely say that the platform should be usable from a phone?

A fixed-price proposal can work when the scope is well defined and unlikely to change. But a pre-seed startup is in precisely the opposite situation. It is still learning what product it needs to build.

As we explain in our guide to the squad methodology, fixed models may offer a degree of budget predictability, but they struggle to absorb the inevitable changes involved in building a digital product.

Defining too early what we do not yet understand is a highly effective way of purchasing peace of mind for the first few months...

And problems for the months that follow.

2. Time & Material: traditional outsourcing

The second alternative is the Time & Material model, commonly used in traditional outsourcing.

The client pays for the time consumed by the team: hours, working days, sprints or months.

It is more flexible than a fixed-price model because it allows priorities to change and the scope to adapt. It also has a few minor disadvantages, which we have already discussed on our blog in the article “AOR vs. Outsourcing for Remote Technical Talent”. The main one is that too many companies have discovered that selling hours is far more profitable than solving problems...

The client watches the invoices. The provider watches the backlog. And the backlog always seems to have room for one more feature...

The problem with traditional outsourcing is not only that clients are billed for time. It is also the separation that often emerges between the people managing the business and those managing the team.

In a properly structured outsourcing engagement, the provider should organise its professionals, direct the team and take responsibility for the service or outcome. The client defines the objectives, priorities and acceptance criteria.

When the provider merely “places” developers and the client ends up organising their daily work, we get the worst of both models...

Intermediation, limited transparency and unclear responsibilities can end badly.

Paying for 2,000 hours does not guarantee receiving 2,000 hours of value...

EOR and AOR: better alternatives for many startups

A startup does not always need to hand control of its product over to a consultancy.

In many cases, it needs access to specialised talent, the ability to retain management control and a properly structured relationship with remote professionals.

An EOR, or Employer of Record, allows a company to hire a professional as an employee in a country where the startup does not have its own legal entity. It is an appropriate solution when there is a genuine employment relationship: stable dedication, dependency, continuity and integration into the organisation.

It may be the right solution...

But it is not always the simplest option for a startup.

An AOR, or Agent of Record, is designed to manage relationships with independent professionals, whether international or local. The startup retains control over the product and the team. The professional retains their autonomy. And the AOR provides the necessary contractual and administrative framework.

For a startup that needs to incorporate international technology talent flexibly, an AOR is often simpler and more effective than traditional outsourcing or an unnecessarily complex EOR arrangement.

However, no commercial label changes the true nature of a relationship...

The choice should depend on how the working relationship will operate in practice, not on which box appears cheaper.

3. The “brave” solution: hiring one or two developers

This is often the preferred solution for a startup with a limited budget:

—Let’s begin with one or two programmers and then... then we’ll grow.

It is a curious way of thinking.

When someone builds a house, they understand perfectly well that they need an architect, a builder, bricklayers, electricians and plumbers. Nobody questions it. Least of all the person who will eventually live in or purchase the property.

Nobody says to the bricklayer:

—Since you are very good at laying bricks, could you also design the structure, install the pipes, prepare the electrical panel and calculate the building’s energy efficiency?

In software, we do exactly that.

We hire one or two developers and expect them to define the product, design the user experience, select the architecture, programme the frontend and backend, configure the infrastructure, automate deployments, guarantee security, test the application and participate in strategic business decisions.

“And while we’re at it... make sure they’re cheap.”

The problem is not starting with a small team. The problem is starting with an incomplete team and expecting the missing responsibilities to disappear by themselves...

As we explain in “How to Build a Development Team in 2026: The Playbook for Startups”, a startup should not merely select people. It must structure responsibilities: product, architecture, development, user experience, quality, infrastructure and security.

Not every responsibility requires a dedicated full-time person. But every responsibility exists...

Even when it does not appear in the initial budget.

4. The online calculator

Another alternative is to use an online calculator.

We select “mobile application”. We enter the number of screens. We tick boxes for payments, notifications, geolocation and artificial intelligence. We press a button...

And receive a quotation. Fast. Clean. No meetings required.

It is the technological equivalent of estimating the cost of a building by asking only how many rooms it will contain.

Some calculators assign an average number of hours to each feature. Others compare the project with previously developed applications. And some use more sophisticated methods, such as function points.

Function Point Analysis is a recognised technique for measuring the functional size of an application based on what the system provides to the user. It analyses inputs, outputs, queries, internal data and external interfaces.

It is a far more serious method than counting screens. It allows organisations to compare projects, analyse productivity and build historical models.

But it also has limitations.

Two systems with a similar functional size may require radically different architectures and engineering standards.

Function points help measure what the system must do. But they do not always fully reflect how it must do it, the environment in which it will operate, the level of security it requires, how much it must scale or the technical risks involved.

And that is where a substantial part of the budget is often hiding...

The most common mistake: calculating resources before understanding the product

Our proptech CEO had attempted to calculate how many developers he needed before understanding what product he was going to build.

Two developers for four months. Two people multiplied by four months and by a monthly cost.

The calculation was simple... The product was not.

Before calculating resources, we need to understand the scope, integrations, quality expectations, constraints, timeline and the client’s ability to make decisions.

We also need to discuss architecture.

Because building a system with Java is not the same as developing an interface using React. In fact, Java and React do not even solve the same type of problem...

We need to decide how the system will be divided, which parts will exist in the frontend, which services will operate in the backend, how the data will be stored, which components will be proprietary, which third-party services will be used, how the system will be deployed, how it will be tested, how it will be protected and how it will grow.

The languages, frameworks, libraries and platforms selected affect performance, maintenance, security, deployment and the professionals we will need to hire.

They also affect the budget.

An architecture that is too simple may force us to rebuild the product. An architecture that is excessively sophisticated may result in an MVP requiring the technical team of an international bank...

Choosing correctly can make an enormous difference in terms of time, cost, maintenance and frustration.

And frustration should probably be included in estimates too...

Our proposal

When we began working on the Squadmakers estimator, we did not want to build yet another calculator based on screens, features and hours.

We wanted to transfer into a tool the questions that an experienced CTO, software architect or product leader would ask before committing an investment.

The model needed to analyse the type of product, its stage, its scope, integrations, engineering requirements, time constraints and the client’s ability to participate in decisions.

It also needed to propose a team composition.

Not merely how many people were required...

But which responsibilities had to be covered and when each role needed to become involved.

Because the correct unit for thinking about a project is not always the individual developer. In many cases, it is the squad: a small, multidisciplinary and autonomous team focused on a specific mission.

In our complete guide to the squad methodology, we explain why composition, autonomy and responsibility for results are more important than simply gathering technical profiles.

The client does not necessarily need more people.

They need the right combination.

First, we understand the complexity

Our model begins by trying to understand what makes the project complex: the type of product, the stage of the business, the functional scope, the integrations, the engineering requirements, the time constraints and the client’s knowledge and availability.

A seemingly simple screen may involve validations, permissions, communications, payments, auditing and integrations with several systems.

What the user sees almost never represents all the work involved.

And the phrase “they have an API” does not necessarily mean the API is well designed, properly documented or even available...

When the client does not have an experienced CTO or Product Manager, someone must fulfil that role.

Leaving it out of the budget does not make it disappear...

It simply means it will appear later in the form of delays, mistakes and scope changes.

This is also where the Enabling Team becomes important: senior specialists in architecture, DevOps, QA, cybersecurity, product or user experience who support the squad when specific expertise is needed, without forcing the project to include every one of those profiles on a full-time basis.

It is not about filling the project with managers...

It is about ensuring that important decisions are made by people who know how to make them.

The artificial intelligence we have applied

We could have connected a generative model, asked the client to describe the idea and returned a figure with two decimal places.

It would have looked very intelligent...

But nobody would have been able to explain why the result was €180,000 rather than €120,000.

For a decision that could determine whether a startup survives, “the AI said so” does not seem like a sufficient explanation.

That is why our solution is based on decision trees supervised by experts.

Each answer changes the path of the analysis. The type of product creates certain requirements. Integrations increase complexity. Security requirements modify the effort involved. Urgency may change the composition of the team. The client’s maturity determines how much support will be required.

The result does not appear out of nowhere.

We can reconstruct the reasoning that leads to the estimate. We can explain which factors increase the cost, which decisions extend the timeline, which risks require specialist profiles and which changes could reduce the investment.

AI should not merely provide answers.

It should help us understand them...

A solution based on 29 years of experience

The knowledge that powers our model does not come exclusively from projects developed by Squadmakers.

It is also based on my participation in hundreds of projects over 29 years of professional experience.

I have worked as an engineer, head of development, CTO, technology director, entrepreneur, mentor and startup adviser.

This has allowed me to observe projects from very different perspectives: that of the developer receiving a set of requirements, the architect making technical decisions, the manager coordinating the team, the CEO controlling the budget and the entrepreneur discovering that runway has no sympathy for delays...

This experience is complemented by our work with incubators and entrepreneurial ecosystems, as well as the personal projects I regularly mentor.

Every project contributes new data: which integration proved more complex, which feature required less effort, which profiles were genuinely necessary, where bottlenecks appeared, which decisions reduced delivery time and which initial assumptions were wrong.

Experts then review the differences between the estimate and the final outcome, analyse their causes and decide which lessons can be incorporated into the model.

Previous projects help us identify patterns. Human experience helps us interpret them.

And the system learns from that combination...

Why we provide a range

Many clients would like to receive an exact answer:

The project will cost €127,450 and will be completed on 14 March at 11:35 a.m.

That would be fantastic. It would also be a lie.

At the beginning of a project, many decisions remain unresolved. As the product is defined, the architecture selected, the integrations studied and the scope clarified, uncertainty decreases. That is why we provide a range.

It is not a way of avoiding commitment. It is an honest representation of what we know and what we still do not know.

An estimate does not eliminate uncertainty. It makes it visible...

And what is visible can be managed.

The most common response from our clients

When we show clients the estimator’s result, their most common response is not:

—That is exactly what I calculated.

What we normally hear is:

—I thought it would cost considerably less.

And almost immediately:

—I also thought it could be done with fewer people.

It is a completely logical reaction.

From the outside, the product appears to be a list of features: registration, a dashboard, a search engine, a payment system, an integration and an artificial-intelligence module.

But the invisible effort does not appear on that list.

The architecture. The infrastructure. Permissions. Testing. Security. Deployments. Observability. Documentation. Code review. Coordination. Product management. The translation of business requirements into technical decisions.

And everything that nobody has thought about yet...

When the client understands all these elements, the conversation changes.

We are not telling them: “This is what you are required to spend.”

We are telling them: “This is the product you have described. These are its main sources of complexity. These are the decisions driving the cost. And these are the alternatives available to reduce it.”

That is when the genuinely useful conversation begins.

Estimation also helps us build less

A good estimate should not merely tell us how much an idea will cost.

It should help make the idea viable.

We may discover that an integration planned for the first version can be handled manually for a few months. That we do not need native applications from day one. That a feature will only provide value once the platform has a critical mass of users. That expansion into ten countries can wait. That a fully automated process can begin as an assisted one. That a proposed artificial-intelligence feature could initially be replaced by a well-designed business rule...

In a startup, building less does not always mean giving something up. Very often, it means prioritising.

Removing features at random makes a project cheaper. Reducing scope intelligently makes the project better.

They are not the same thing...

The outcome of our proptech story

Let us return to the CEO we began with.

The figure he had in mind was lower than our estimated range. He also believed he could begin with fewer resources.

He was not wrong because he did not understand his business. He understood the real-estate sector perfectly.

What he did not yet understand was the technical structure required to transform his experience into a digital product.

The solution was not to convince him to spend more.

It was to help him build less.

We reduced the initial scope. We postponed some integrations. We converted certain automated processes into assisted operations. We defined which hypotheses needed to be validated first. And we reorganised the team around those priorities.

The budget stopped being a number...

And became a map of decisions.

The question was never how much it costs

After 29 years of participating in technology projects, creating companies, managing teams and advising startups, I have learned that when a CEO asks how much it costs to develop an idea, they are rarely looking for a number alone.

They are trying to answer more important questions:

Can I afford it? Am I trying to build too much? What risks am I failing to see? What team do I need? What architecture makes sense? What can I postpone? Where is it worth investing? Can this idea genuinely become a product?

A calculator can return a figure. A provider can submit a proposal. A developer can estimate their hours.

But a good estimate must do something more. It must transform uncertainty into decisions.

Because the cost of developing an idea does not depend solely on its features. It depends on the problem it solves, how it must operate, the architecture we select, the team that builds it and how much we are willing to learn before making a mistake.

Software has never been merely a question of lines of code. It has always been a question of decisions...

And the most expensive decisions are usually the ones we make too early, while we still believe we have all the answers.

An estimator is therefore useful not because its final figure is perfectly accurate, but because of the mental process it encourages: analysing the project through a methodology that can provide an order of magnitude, help us understand how a product is created and support decisions that directly affect the project’s viability.

We invite you to try it. It is available free of charge on our website:

https://challenge.squadmakers.com/estimador

We only ask you to provide your details if you would like us to review the results with you. And because it is powered by AI, your feedback will also help us continue improving the results.

‍