DFIELDSOLUTIONS

Buyer's guide

LabWhat custom software actually costs

The honest answer is a range with a driver behind it. Small automations land in the low thousands; a product with payments, roles and a mobile surface is a different order of magnitude. What moves the number is never the page count.

What custom software actually costs

Buyer's guide3 sections · 2 min readBy Dezső Mező · Published .mdPricingBuying softwareProcess

Nobody publishes real numbers because every brief differs, which conveniently lets everyone quote low. Useful ranges, the kind a budget discussion actually needs: an automation that removes a weekly spreadsheet job lands around a few thousand euros. A customer-facing tool with accounts, a workflow and payments sits in the mid four-to-five figures. A platform you plan to run a company on for years is an ongoing budget line, not a project with a sticker price.

The number moves on four things, and page count is none of them. Integrations: every external system adds a real cost in edge cases, not in the happy path. Data migration: the price of the last decade of Excel being right. Users and roles: one audience is cheap, five kinds of permission are not. And the unknowns you cannot describe in the brief — which is why a fixed quote on a fuzzy brief is a bet, not a price.

01What drives the price

Integrations, data migration, and role complexity — in that order. A 'simple site' that must talk to a warehouse API and import fifteen years of order history is not simple. Ask for the driver, not the number: a quote that cannot name what it is paying for cannot defend itself when scope changes.

02What the cheap quote omits

The proposal that is a third of the others is not a third of the work — it is the same work with parts unsaid: no migration, no responsive pass, no error states, no time for 'what happens when the API is down'. The honest way to compare quotes is to ask each what it assumes, then count the assumptions.

03How to buy it without gambling

Pay for the thinking first: a small paid discovery or a working prototype prices the unknowns before the big contract prices the knowns. Milestone payments tied to working software, not to calendar dates, keep both sides honest — and an exit that leaves you owning what exists so far means the risk is bounded either way.

What to take away

  • Automations: low thousands. Customer tools: mid four-to-five figures. Platforms: an ongoing budget.
  • Integrations, migration and roles move the number — page count does not.
  • A cheap quote is the same work with parts unsaid; count the assumptions.
  • Pay for a prototype or discovery before the big contract — it prices the unknowns.

Questions this answers

Is a fixed quote or hourly billing safer?

Fixed only works when the scope is written down in enough detail that 'done' is testable — otherwise the fixed number is padded for the unknowns. Hourly with milestones and a progress page is usually cheaper for genuinely uncertain work, because you stop paying the day the value stops.

Why do quotes for the same brief differ by 10x?

Because they are pricing different assumptions: senior versus junior, migration included or not, who owns the unknowns. Ask each bidder what their number assumes and the gap explains itself.

Can I start small and expand?

Yes, and it is usually the right shape: a paid discovery or a small first build prices the unknowns and tests the working relationship before either side commits to the big number.

Terms used in this piece

We build this for clientsFull-stack

More from the lab

Browse all entries

Want this looked at on your own system?Start a conversation

5.0
“New shop, more orders in the first week.”Müller Márk · GeekCornerManaging Director · Hungary