What custom software actually costs, and what moves the number

A well-built marketing site starts around USD 3,000. A platform with integrations, roles and data migration clears USD 100,000 without trying. Most of the projects we quote land between USD 8,000 and USD 40,000, and a working MVP usually takes 4 to 10 weeks.

Those numbers are enough to start budgeting, which is more than most vendors will put in writing before a call. But the number is not the interesting part. What matters is what moves a project inside that range, and what throws it outside the range halfway through. That is what decides whether the quote you sign is the amount you end up paying.

Why "it depends" is an honest answer and still a useless oneLink to this section#

A software quote is an estimate of work, and the work depends on five things that are rarely on the table in the first conversation:

• Real scope, measured in flows rather than features. "An admin panel" can mean a filterable table, or role-based permissions with an audit trail and exports. The distance between those two sentences is a month of work.
• Integrations with somebody else's system. Talking to an ageing ERP, an undocumented API, or a service that only exchanges files over SFTP costs more than building the equivalent feature yourself. Not because it is technically hard, but because of how many surprises only show up once you touch it for real.
• Data migration. Existing data never matches its description: duplicates, one field used for two purposes, dates in three formats, a parallel spreadsheet that turns out to be the actual source of truth. Bad migration is the single most common reason a new system gets abandoned three months after launch.
• Compliance and security. SOC 2, HIPAA, PCI, GDPR, accessibility requirements in a public-sector contract. Each of these adds work a user never sees and that cannot be skipped.
• Design. Designing from scratch — research, a component system, several rounds of review — can be 20% to 30% of a project. Starting from an existing design system cuts that to a fraction.

What does each type of project cost?Link to this section#

These are the ranges we work with, organised by project shape rather than by industry. They are orientation ranges: enough to tell you whether the order of magnitude in your head is the right one.

A project lands at the bottom of its range when the scope is written down, one person makes decisions, there is nothing to migrate, and the integrations have documentation and a sandbox. It lands at the top when the opposite is true — and especially when the design is only decided once people see it running.

Hourly, one fixed price, or a fixed budget per phase?Link to this section#

All three models are legitimate. They distribute risk very differently, though, and it is worth knowing which side of it each one puts you on.

Hourly. The vendor carries none of it: if something takes three times as long, you pay for it anyway. This works when the work is genuinely exploratory, or when there is trust from previous projects. With a new vendor it is a blank cheque that also rewards being slow.

One fixed price for the whole project. It sounds like maximum protection and it is the opposite. To commit to a number for something that is not yet defined, a vendor has to price in an uncertainty buffer, and you pay for that buffer whether or not it is needed. Worse: from the moment you sign, every conversation becomes a scope negotiation. "That wasn't in the contract" kills more projects than any technical problem.

A fixed budget per phase. This is how we quote: phases of two to four weeks, each with a fixed price and a deliverable that actually runs. The advantage is yours, not ours:

• You are only committed to the current phase. If something is not working out, you walk away at the end of it with working software and with the source code, which is yours from the start anyway.
• Uncertainty gets priced once it is no longer uncertain. Phase three is quoted knowing what phases one and two taught us, so there is no fear premium in it.
• Changing your mind stops being a conflict. What you learn from seeing the previous phase running feeds the plan for the next one, which is the entire point of shipping often.

What makes a budget blow up mid-project?Link to this section#

Almost always the same things, roughly in this order:

1. Scope was written as a feature list. "Reporting" is not a deliverable. "A sales report by month and by rep, exportable to Excel, for three roles" is.
2. An integration with no sandbox. If the system you have to connect to offers no test environment, the integration gets tested in production, and that is paid for in time.
3. The real data arrives late. When migration is first looked at in week eight of a ten-week project, the problem is no longer technical, it is a calendar problem.
4. Decisions have no owner. A project approved by committee stalls between meetings, and stalled time is billed time.
5. "While we're in there." The small change that looks trivial and quietly reopens an architecture decision made three weeks earlier.

Concretely, how to protect yourself: ask for scope as verifiable deliverables rather than features. Give access to the data and the integrations before the price is agreed, not after. Name one person who decides. And make sure the contract says what happens when something changes — how it gets priced, when it lands — instead of trying to forbid it. Changes will happen anyway, and a contract that denies them only guarantees an argument.

Why does the cheapest quote usually turn out to be the most expensive?Link to this section#

If three serious vendors quote the same brief at USD 22,000, USD 19,000 and USD 6,000, the third one did not find a more efficient way to build it. They understood something different, and almost always something smaller: no migration, no permissions, no edge cases, no tests, no error states — none of what shows up once the system is actually used.

The full cost of a cheap build that fails is not the price you paid. It is that price, plus the months your team spent working around it, plus rebuilding it. Rebuilding always costs more than building, because now the data created in the meantime has to be migrated too.

Why can an Argentine team charge less for the same engineering?Link to this section#

This is the part a buyer in the US or Europe is entitled to be suspicious about, so it is worth being explicit.

The price difference is geography and macroeconomics, not seniority. An engineering salary that is competitive in Argentina — good enough to keep strong people on the team — is still a fraction of the equivalent salary in San Francisco, London or Berlin. On top of that our structure is small: no management layers, no account executives, nobody between the client and the person writing the code. That gap is real, and it is sustainable.

What does not explain it: more junior people, looser process, fewer tests. When a vendor is cheap for those reasons, the price is not an advantage, it is a warning — and that is equally true in Argentina, in India, or in Ohio.

Since no adjective proves this, verify it by asking. Four things worth asking on a first call, of us or of anyone:

• To talk to the person who will write the code, not only to whoever sells.
• To see real code: a repository, a snippet, something they built.
• To have them explain one technical decision and why they rejected the alternative. Anyone who cannot name the alternative did not evaluate it.
• To hear what they would not build in your case. A vendor who says yes to everything is quoting what you want to hear.

What distance does change, and you should know it going in: Argentina is on UTC−3 all year, with no daylight saving. That overlaps a full working day on the US east coast, about half a day on the west coast, and the European afternoon — but essentially nothing in Asia-Pacific. And we will not be physically in your office. If your project genuinely needs someone in the room every day, no remote team is the right answer, at any price.

What to ask for in any quoteLink to this section#

Whoever you end up hiring:

1. Scope as a list of deliverables, with a definition of "done" for each one.
2. The price broken into phases, with what ships at the end of each.
3. What is explicitly out of scope, in writing.
4. What happens to the code, the accounts and the infrastructure if the relationship ends. The right answer is that they are already yours.
5. What maintenance costs after launch. A live system has a monthly cost; a quote that never mentions it is hiding it, not avoiding it.

If the quote in front of you does not answer those five, the problem is not the number. It is that there is not yet enough information for the number to mean anything.

That phased approach is how we work, and it is spelled out in our process. If you want a range for a specific case, tell us what you need to solve: you get back a range and the questions still missing to tighten it, not an invitation to a discovery call.