Three things decide which enterprise software company you should work with: verifiable references at a similar scale, a contract stating that the source code and the data belong to you, and a written maintenance and support commitment (SLA) for after the project ends. Price comes fourth — because in enterprise projects the real cost is not the first quote but the maintenance, change requests and handover fees paid over three years. Below are the criteria to work through while collecting bids, the pricing models in the market, and the red flags that should stop you from signing.
Enterprise software company, agency or freelancer?
The three supplier types do not do the same job. A freelancer is the fastest and cheapest option when scope is clear and the timeline short; the risk is dependence on one person. Digital agencies are strong on design- and marketing-led web work but struggle with ERP integration, role-based authorisation or systems with heavy transaction volume. An enterprise software company runs business analysis, architecture, testing and deployment as a team — that is the expensive part, and it is exactly what you are buying. The distinction surfaces with one question: “what happens if the person who built this leaves?” If the answer does not include a clear handover plan, you are talking to the wrong scale of supplier. If you are not sure which type of solution you need, our guide to enterprise software solutions is a good place to start.
Eight criteria to evaluate
- Verifiable references: completed work at a comparable scale, ideally in your sector. Do not settle for reading the list — fifteen minutes on the phone with one of their clients tells you more than the whole pitch deck. The question to ask: “what happened after delivery?”
- Source code and data ownership: who owns the repository, is it transferred to you on delivery, can you export the database? If those three are not in the contract, there is no point discussing price.
- Team structure and continuity: who will actually work on this, how many people, for how long? Is the senior team in the sales meeting the team assigned to the project? What happens if a key person leaves?
- Integration capability: most enterprise projects are less about new software than about connecting to what already exists — ERP, e-invoicing, payment gateways, SSO/Active Directory, accounting. Ask for concrete examples of each integration you need.
- Process and transparency: what is the sprint rhythm, how often are demos, where are bugs tracked? A project where you cannot see working software weekly is a project at risk of being unacceptable at the end.
- Testing and quality: are there automated tests, is there a separate staging environment, how does go-live work? “We test it” is not an answer — ask how.
- Security and data protection: where the data lives, backup frequency, access logs, the data processing agreement. In public sector and healthcare work this line is the procurement criterion.
- Maintenance and SLA: what happens after the project ends? Response time, critical incident response, the annual maintenance fee and exactly what it covers, all in writing.
If only one clause makes it into the contract, make it source code ownership. When the code stays with the supplier, changing vendors means rewriting from scratch in practice, and your negotiating power drops to zero. For critical systems the next step up is a source code escrow agreement: if the supplier ceases trading, the code passes to you automatically.
Pricing models: which one fits when
Enterprise software is priced one of three ways, and picking the wrong model costs as much as picking the wrong supplier:
- Fixed price: the right model when scope is clear and unlikely to move. The supplier carries the risk, so a margin for uncertainty is built into the number, and anything out of scope needs a change order. Use it where you have a real specification.
- Time and materials (day rate): the most honest model when scope firms up as you go. Work with a monthly cap and regular demos; without both, budget control disappears.
- Hybrid: fixed price for discovery and analysis, day rate for development. This is what works most often on enterprise projects — analysis produces a realistic budget, and neither side commits blind.
When comparing bids, calculate three-year total cost of ownership: project fee + annual maintenance + expected change requests + infrastructure (servers, licences, certificates). The lowest project fee frequently hides the highest three-year cost.
Red flags
- A quote with no specification and no questions asked: a number given without understanding scope gets corrected later through change orders.
- The “we do everything” position: claiming expertise in web, mobile, ERP, AI and hardware usually signals depth in none of them.
- Refusing to provide references, or sharing only a list of logos. Confidentiality can be a legitimate reason — but if not a single conversation can be arranged, take note.
- Avoiding a clear contractual statement on source code and data transfer.
- Deferring the maintenance fee to “we’ll discuss it later”: that conversation then happens at the exact moment your leverage is lowest.
- An implausibly short timeline: a bid promising half the duration of the others has either misunderstood the scope or left out testing and deployment.
What to send when you ask for a quote
The quality of the bids you receive is proportional to the quality of the brief you send. At minimum, write down: the business problem you want solved (not a feature list), who runs the process today and how, the existing systems it must connect to, expected user count and transaction volume, mandatory compliance requirements, your target date and a budget range. Hiding the budget does not get you a better price — it gets you bids that cannot be compared. Our software project brief article has a template you can use. For choosing a software company more generally — beyond enterprise scale — see how to choose a software company.
Conclusion
Choosing an enterprise software company is not a price comparison; it is a three-year partnership decision. The right order of questions is: have they done comparable work, who owns the code and the data, who maintains it after go-live — and only then, what does it cost. Companies that invert that order are usually the ones rewriting the system in year two. If you are looking for a solution that connects to your existing systems and ships with the source code in your hands, see our corporate solutions page; for something built around your own process, see custom software, or tell us what you need and get a free quote.