It is almost always the first question. The honest answer is that it depends, but that helps nobody if the conversation stops there. Below are the factors that move a budget the most, as they show up in delivered work.

The boundaries of the scope, not its name

Two projects with the same name can cost very differently. A store with thirty products, cash on delivery, and no link to another system is predictable work. A store with a catalogue structured by vehicle type, search, seasonal variants, and a basket in local currency, like the tyre store in Sighetu Marmatiei, requires a different amount of work.

That is why the first conversation looks for a boundary rather than a price. How many flows exist, how many exceptions must be handled, and above all what stays outside the first version.

Integrations with existing systems

Every external system brings its own rules. A payment provider, an invoicing system, a stock system, or an ERP are not boxes you tick. They are technical contracts with their own errors, access limits, and behaviour that has to be tested separately.

In the ELIA Water store, instalment financing and booking a demonstration are not extra pages. They are flows that must stay correct even when the other system answers incorrectly or does not answer at all.

How much the interface computes

A page that displays text costs less than one that computes. The difference is not visual but one of responsibility, because a wrong result has consequences off the screen.

The Laguna configurator suite places kitchen units, detects collisions, recalculates the price in real time, and exports the configuration as a PDF. That is no longer a website. It is a product that has to give the same result every time.

The same applies to the material and transport calculators in the Sebi Marc portal. There are few screens, but every figure has to hold up in front of a client.

The rules that govern the data

Ordinary data requires care. Regulated data requires architecture. A telemedicine platform like Dr. Stress works with medical information, so consent, access, retention, and deletion are not features added at the end. They are design decisions taken at the start.

The cost here is not in the code. It is in the design that makes the code verifiable later.

Content and languages

A second language is not a button. It means content written twice, separate addresses for each version, and reciprocal links between them, so search engines understand which page serves whom.

Cabanele din Valea Ursului works in Romanian and English because a foreign visitor searches differently from a local one. It is a business decision, with a cost to match.

What lowers the cost without spoiling the result

A short discovery stage before development. It looks like an extra cost and it almost always pays for itself, because it moves the hard questions ahead of any code built on a wrong answer.

Staged delivery. A narrow first version that genuinely works says more than a long specification, and it lets the next decisions rest on real use.

Dropping what nobody uses. Many features requested at the start are never used, and each one carries a cost to build, to test, and to maintain, year after year.

Frequently asked questions about budget

Why do I not get a fixed price in the first conversation?

A fixed price given before the integrations and the data rules are understood is either inflated to cover the unknown or too low and corrected along the way. After an initial conversation you receive an estimate or a proposal for a discovery stage.

Can I start with a smaller budget?

Yes, if we narrow the scope rather than the quality. A first version with fewer flows, built properly, can grow later. A version built in a hurry gets rewritten, and that costs twice.

What happens if the requirements change along the way?

They almost always change. That is why we work in stages and discuss the effect of each change on time and budget before implementing it.

A realistic budget does not come from a price list. It comes from a conversation about what the product must do and what it must not. If you have a project in mind, tell us what it needs to solve.