Ask ten Romanian software firms what a custom internal system costs and nine will say "it depends on requirements". Which is true, and useless, and mostly a way of avoiding the conversation until you are far enough in to be committed.
So: our floors are 900 EUR for a marketing site, 3.000 EUR for a web-based management system, 4.000 EUR for a Windows desktop application, and automation work is quoted per scope. All excluding VAT. Most first-generation internal systems land between 3.000 and 12.000 EUR.
Now the useful part, which is not the floors. It is what moves a project from the bottom of that range to the top.
The four things that actually set the price
How many different roles use it. This is the big one and almost nobody expects it. A system where everyone sees everything is dramatically cheaper than one where operations, finance, management and the customer each see a different slice. Every role is a set of screens, a set of permissions, and a set of decisions about what that person must not see. Four roles is not four times one role, but it is not close to one either.
How many systems it has to touch. Each integration brings field mapping, error handling, and testing against somebody else's real data. A system with a documented API is roughly a week. A twenty year old program that exports a fixed-width text file at 3am is three, and the third week is entirely about what happens when the file is late or half written.
How complicated your pricing is. Per-customer prices, volume discounts, per-batch margins, commission calculations. These rules are almost always undocumented, live in one person's head, and have exceptions that only surface when you show them a screen that gets an answer wrong. Discovering them is the most consistently underestimated part of any estimate we have ever made.
How clean your current data is. Migrating from a well-kept spreadsheet is a day. Migrating from files where the same client appears as "SC Popescu SRL", "Popescu S.R.L.", "popescu srl" and "Popescu" is a week, and it still has to happen, because the new system will treat those as four customers unless somebody decides they are one.
Notice that three of the four are about your business, not about software. That is not us dodging. It is the actual distribution of the work.
What the number is not
It is not per screen. Estimating by counting screens is how you get a quote that is precisely wrong: two screens can differ by a factor of twenty depending on what has to be true when you press save.
It is not per developer-day multiplied by a guess. Or rather, internally it is, but if the risk of that guess sits with you rather than with us, you are buying an option, not a system. Which brings up the thing worth being blunt about.
Fixed price, and who carries the estimate
We quote a fixed price for the scope, and the number does not move mid-project even when we have estimated badly. That is not generosity. It is where the risk belongs: we are the ones who can judge how long the work takes, so we should be the ones exposed if we judge it wrong.
The trade is that scope has to be written down before we start, and changes you ask for later get quoted separately, also fixed, also before they are built. People sometimes hear that as rigidity. In practice it is the opposite: it makes changing your mind a priced decision rather than an argument.
Time and materials is the honest alternative when the work genuinely cannot be scoped, which is mostly true for ongoing modifications to a system that already exists. For a new build it usually means the estimate risk has been handed to the buyer, quietly.
Money that is not the invoice
Three costs get left out of comparisons and all three are real.
Hosting. For most internal systems, tens of euros a month. Pay the provider directly, on your own account. If a supplier insists on hosting it for you at a markup, ask what happens to the system on the day you stop paying them.
Ongoing changes. Budget something. A system that never changes is a system nobody uses. This does not have to be a retainer, but it should not be a surprise either.
The cost of not doing it, which is the one nobody puts in the spreadsheet. If two people spend an hour a day re-typing between systems, that is roughly 500 working hours a year. Put your own number on the hour and compare it to a one-off 6.000 EUR. The comparison is usually not close, and it is the only comparison that matters.
What we charge in, and when
Prices in euro, invoiced in lei at the BNR rate on the invoice date, VAT where it applies. Payment in instalments tied to deliveries rather than to dates: something at kickoff, the rest against stages you have seen working. The final instalment at acceptance, and that is also when the code and the intellectual property transfer to you.
That last detail is worth checking with anyone you are considering. Ask directly: on the day I make the final payment, what do I own? If the answer involves a licence rather than ownership, you are renting.
Why we publish this at all
Because the alternative is worse for both sides. Without numbers, small companies assume custom software is out of reach and keep paying the spreadsheet tax for another three years. And we spend first calls on projects that were never going to fit a budget nobody had said out loud.
A price floor on a page is not a quote. It is the thing that lets you decide, in thirty seconds, whether the conversation is worth having. If 3.000 EUR is impossible for you this year, you have learned something useful and it cost you nothing. If it is obviously affordable, the rest of the discussion is about scope, which is a much better argument to be having.