What custom software costs in El Salvador

You asked three vendors to quote the same system and the numbers came back nowhere near each other. Not ten percent apart: multiples apart. All three heard the same description of the problem, and none of them showed you how they got to their figure.

It is rarely bad faith. Most of the time they were quoting three different projects, because "a system to manage my orders" describes three weeks of work and also six months of it, and the difference lives in things that never come up in a first conversation.

This piece is about what actually moves the price, what tends to be missing from the cheap quote, and what you keep paying after delivery. There is no price table in it, because a price table for custom software is fiction: it describes a project that is not yours.

What actually moves the price

Five variables explain most of the gap between one quote and another. None of them is "how many screens".

How much it has to integrate with. A system that lives alone is cheap. One that has to talk to electronic invoicing, to WhatsApp, to a barcode scanner, to a payment gateway or to the ERP your accounting team already runs is a different job. Every integration is an agreement with a system you do not control, with its own documentation, its own failure modes and its own release calendar. An integration is not finished when it works the first time. It is finished when it still works the day the other system changes.

Migrating your historical data. Almost every business with a few years behind it arrives with data somewhere: a spreadsheet with fifteen thousand rows, a database from a previous system, paper. Moving it is real work and it is almost always dirty work, because old data is never clean. There are duplicate customers spelled three ways, dates in two formats, fields somebody quietly repurposed for something other than their name. Deciding what to do with each case is a business conversation, not a technical task, and it is underestimated every single time.

How many roles and permissions. A system with one kind of user is an application. A system where the cashier sees one thing, the supervisor another, the accountant only their own, and the owner everything, with rules about who can void what and who authorizes whom, is a different build. Every role multiplies the paths you have to construct, and above all the paths you have to test.

Native mobile apps. A site that looks right on a phone and an app you install from a store are not the same project. A native app adds two platforms, two release processes, two review cycles and a maintenance obligation that never ends. It earns its cost when you genuinely need the camera, background location, scanning or offline operation. If you need none of those, it is usually just spend.

Regulatory requirements. If your system has to issue Salvadoran electronic tax documents, known locally as DTE, that is not a module you bolt on at the end. It is a constraint that shapes how a sale is modelled from day one, and anyone treating it as an accessory will be redoing work. The same is true of personal data handling or any sector-specific requirement. We wrote about what the current version changes in DTE 2.0 and the December 1 deadline, and it is the clearest example of a requirement that moves the price up front and punishes whoever postpones it, and one of the reasons a local build and an offshore one are not interchangeable.

Why the cheap quote is not the same quote

When one proposal costs a third of another, it almost always includes less. The trouble is that what is missing is not listed anywhere, so you are comparing two documents that describe different work.

What tends to be absent: scope written in enough detail that you can tell what falls outside it. Migration of the data you have today. Training for your team. Documentation. Any support at all after handover day. And ownership of the code, which is the one that costs the most to discover late.

There is also a more honest and more dangerous version. Sometimes the cheap quote is cheap because that vendor understood less of the problem. Nobody is cutting anything deliberately. They simply did not see the three integrations or the four roles, and they will find them halfway through, after you have signed. That is where the change-order conversation appears, and that is where projects come apart.

The signal to watch is not the price. It is how many questions each vendor asked before naming a number, and whether those questions were about your operation or about your budget.

What a proposal you can actually compare should contain

A serious proposal is a document you can lay next to another one and read line by line. At minimum it should tell you:

• The written scope, with what is in and what is out. The second half matters more than the first.
• Who owns the code and the assets at delivery. The correct answer is that you do. If the proposal does not say so, ask in writing.
• What documentation you receive, and in what format. A system without documentation is a system with exactly one possible vendor.
• Handoff training, because a system your team cannot operate has not been delivered.
• What happens the day after. How many days of support are included, what they cover, and what the response commitment is. We work with thirty days of post-delivery support and a three business hour response time, and both are written into the proposal rather than said on a call.
• The revision policy, with the number of rounds included. Improvising this is the single most common source of friction at the end of a project.

That list is deliberately short. The longer version, with the answer that should worry you in each case, is in twelve questions to ask before hiring an agency.

A vendor who has already put something similar into production can show you rather than describe it: you can see the systems we have delivered and apply that same test to any proposal on your desk. If you want a second read on one you already received, that fits in a thirty minute call and does not require hiring us.

The cost that starts on delivery day

The project price is not the cost of the system. Three line items keep running afterwards, and they are worth budgeting from the start, because they are small next to the build and very loud when nobody planned for them.

Hosting and infrastructure. Server, database, file storage, domain, certificates, backups. For an operational system at a mid-sized company this is usually a modest monthly bill, but it is a monthly bill, and it needs an owner with access to a card.

Maintenance. The dependencies your system uses get updated, some of them for security reasons. Browsers change. The systems you integrated with change their APIs. A system nobody touches for two years does not stay where you left it: it degrades, and the work of catching it up grows faster than the work of keeping it current.

Evolution. This is the good one. If the system works, your team will start asking for things, and those requests are the sign that it is being used. Decide up front whether that runs on a retainer, by project or against a block of hours, rather than negotiating it from scratch every time.

When custom software is the wrong answer

Better said here than on the call. There are three cases where you should not build.

The first is a standard process with no local integrations. If what you need is to invoice, track inventory and nothing else, and the way you work has nothing unusual in it, there is off-the-shelf product that does it better and cheaper than anyone will build it for you. Paying for custom software to reproduce what already exists is paying twice.

The second is a process that does not yet work on paper. Automating a broken process does not fix it. It breaks it faster and in front of more people. If the real problem is that nobody owns a decision, no system will resolve that.

The third is budget, and it is honest. Our entry point for custom software projects is $2.5K USD, and the typical range for a full operational system, with DTE compliance, a customer portal and support, runs from $8K to $25K USD. The ranges and what each one includes are on the custom systems page. If your budget sits below that floor, we would rather tell you and point you somewhere better suited than stretch a scope until it serves nobody.

Before you ask for the first quote

Write one page describing what your team does by hand today, which systems the software would have to talk to, and who makes the call when a call has to be made. That page is worth more than any requirements template, and it makes every quote you receive comparable, ours or anyone else's.

If you want, we can put it together with you. The discovery call runs thirty minutes, it is free and carries no obligation, and its only job is to work out whether there is a problem here worth solving with software. You can book it here.