In this article (14 sections)
If you searched for this, it already happened to you: you asked for a quote, they answered "it depends", and you hung up knowing exactly what you knew before. It's an irritating answer and, at the same time, it's true. The problem isn't that it's false: it's that almost nobody bothers to explain what it depends on.
This piece is that work. You'll find concrete ranges, the factors that move the number inside those ranges, what's almost never included, and the signs that tell you a quote is badly put together before you sign it.
One honesty note before we start: every number here is a reference range for building with a nearshore team in mid-2026, not a quote. Two projects with the same title can cost three times apart for reasons that only show up once someone sits down and looks at your operation.
Why nobody gives you a price up front
When you ask for a software quote, you're asking something close to "how much does a house cost". The honest answer needs to know whether it's a studio or a three-story house with a pool, whether the lot is flat or needs retaining walls, and whether you already have the plans or somebody has to draw them.
In software there's an extra problem: the person asking doesn't always know what they're asking for. Not out of ignorance, but because the problem is known from inside the business and not from inside the system. "I need to control stock" can mean a spreadsheet with permissions, or it can mean lot traceability with expiry dates, an integration with your accounting system and an app for the warehouse. Both are the same sentence.
That's why serious teams quote after a discovery call and not before. It isn't a sales tactic: it's the only way the number means anything.
What you're actually buying
It's tempting to think of the cost as hours of typing. It isn't. In a custom build, most of the value sits in three things you never see on screen:
- The architecture decisions. How the data is stored, what happens when two people edit the same thing, what the warehouse does when the internet drops. These decisions are made once and paid for over years.
- The discovery. Turning "we track stock in a notebook" into a data model that holds up under the real operation, including the exceptions nobody mentions in the first meeting and that are 40% of the work.
- The guarantee that it works. Tests, error handling, permissions, backups. It's the first thing cut when the budget gets tight and the first thing you miss once the system is in production.
A cheap quote is almost always cheap because it cut one of those three, not because the team types faster.
The five factors that move the number
1. How many user roles
A system with one kind of user is a system. A system with an admin, a supervisor, an operator and an end customer is four interfaces, four sets of permissions and four flows to think through, build and test. Each new role doesn't add: it multiplies.
2. Integrations with systems you don't control
Connecting to your accounting system, to an existing ERP, to a payment gateway, to a carrier's tracking service or to your supplier's software is where projects stretch. The reason is simple: you don't control the other end. Outdated documentation, test environments that don't behave like production, responses that change without notice. A simple integration is days; an integration with an old, badly documented system can be weeks.
3. Whether there's a mobile app
A mobile app isn't "the website, smaller". It's another development cycle, another publishing process across two stores with their reviews, and another set of problems: working without signal, battery, camera and location permissions, old Android versions still alive on the phones of people who work out on the road.
4. Volume and concurrency
A system for 20 internal users and one for 20,000 end users don't share an architecture. The second needs infrastructure, caching and database decisions the first doesn't justify. Paying for scale you'll never use is throwing money away; not paying for it when you need it means rebuilding the system.
5. How well defined the scope is
This is the factor that moves the price most and gets discussed least. A project with the scope written, reviewed and signed gets quoted lower than the same project with the scope in somebody's head. The difference isn't a whim: it's risk. Anyone quoting without a defined scope has to add padding, and you pay for that padding.
Reference ranges for 2026
With all of the above in hand, these are the orders of magnitude for custom development with a nearshore team in Latin America. They're in dollars because it's the only way a published range still means something six months later.
- Small project — USD 3,000 to 8,000, three to six weeks. A system with one clear, contained purpose: scheduling, an admin panel over data you already have, a CRUD with reports, a simple customer portal. One or two user roles, no complex integrations.
- Mid-size project — USD 8,000 to 25,000, two to four months. Several user roles, one or two integrations, probably a contained mobile app or a web app with real business logic. This is where most of the business systems a small company asks for land.
- Large project — USD 25,000 and up, four months or more. Multi-company platform, high volume, multiple integrations, audit or compliance requirements. In this range the price stops being a function of the software and becomes a function of the risk.
As a cross-check, an hour of a senior developer on a nearshore team runs between USD 30 and 55. If you divide the quote you got by that number, you get an idea of how many hours you're being sold. If the answer is 40 hours for a complete business system, the problem isn't the price: it's that they didn't understand you.
What's almost never included
This is the part that produces the awkward conversations in month four. Ask explicitly about every one of these before you sign:
- Hosting and infrastructure. The software lives somewhere and that somewhere bills monthly. For a small or mid-size system, budget USD 20 to 200 a month depending on volume.
- Third-party licenses. Transactional email, maps, e-signature, payment gateways, data APIs. Each with its own recurring cost.
- The initial data load. Migrating ten years of information out of spreadsheets with inconsistent formats is a project of its own, and it's very common for it not to be in the quote.
- Training. The system working doesn't mean your team uses it. Add hours of hand-holding for the first few weeks.
- Maintenance. As an industry reference, 15% to 20% of the development cost per year, for fixes, security updates and adjustments.
How to read a quote: four red flags
A single number, no breakdown. "Business system: USD 12,000". You don't know what you're buying or what happens if you drop a feature. A serious quote can be taken apart.
It doesn't say what's out of scope. A good scope document spends as much space on what isn't being built as on what is. If yours only lists features, the argument about what was missing is going to happen anyway, just later and with the system half built.
The timeline is a round number with no stages. "Four months" with no intermediate deliveries means four months without being able to verify anything. Ask for a schedule with milestones where you can see something working.
It's noticeably cheaper than the rest. If three quotes land around USD 15,000 and one says USD 4,000, the fourth didn't discover a more efficient way to work. They understood something else, they'll cut what you can't see, or they'll come back asking for more money in month two.
Fixed price or hourly
Both models exist because they solve different problems.
Fixed price gives you predictability and moves the risk of the estimate onto whoever is building. It's the right model when the scope can be defined precisely before starting. Its cost is rigidity: any change gets quoted separately, which forces you to think things through up front.
Time and materials gives you flexibility and moves the risk onto you. It makes sense when the product is being discovered as you go, or when you're adding people to a team you already run. Its cost is that nobody has a financial reason to finish fast.
Neither is good or bad. One fits your situation. What is a bad sign is being offered only one of them without a single question about your project.
How to lower the cost without ruining the result
There's exactly one lever that works: shrink the scope of the first delivery. All the others —lower the quality, rush the timeline, drop the tests— get paid back later with interest.
In practice, the first scope a company asks for is usually quite a bit bigger than the minimum it needs to start operating. Taking out what isn't essential for month one, putting it in a second stage and funding that stage with what the system already saved you is the healthiest way to make a project cheaper. You're not buying less: you're buying later.
In short
Custom software in 2026 starts around USD 3,000 for something contained, lands between USD 8,000 and 25,000 for most business systems in a small company, and goes past USD 25,000 once scale, multiple integrations or compliance requirements come in.
The exact number inside those ranges is set by the user roles, the integrations, whether there's a mobile app, the expected volume and —above all— how well defined the scope is before anyone starts.
If you're about to ask for quotes, do one thing first: write down on one page what the system has to be able to do on its first day in production. Not what you'd like it to do in two years. That document will make the quotes you get look like each other, and only then will you be able to compare them.