Outsourcing Software Development: Comparing Providers

Software may need to be built from scratch, replaced or extended, but for many clients, choosing the right provider is unfamiliar territory and comes with a degree of uncertainty. That is exactly where this article comes in: it helps you compare software providers, agencies and freelance developers in a structured way, without favouring any one type of provider across the board. You will get practical criteria for assessing providers and proposals, useful questions for the initial conversation, and pointers to common warning signs.

This article is aimed at managing directors, IT managers, business departments and project leads in small and medium-sized businesses, public-sector organisations and agencies in German-speaking countries. The perspective remains neutral and focused on decision-making; technical terms are explained only briefly. If you would like some initial guidance beforehand, an initial cost estimate, a project outline for your enquiry or a no-obligation initial consultation can also help.

What you should clarify internally before looking for a provider

Proposals only become meaningfully comparable once your project has been described internally in enough detail. This does not mean technical specifics, but rather a shared understanding of what is to be achieved: the purpose of the software, user groups, key processes, existing systems and the intended day-to-day benefits.

It is helpful to distinguish early on between must-have requirements and later development stages. That way, providers can assess the scope more realistically, and you avoid wishes from a later phase slipping into the initial enquiry.

You should also clarify the starting point:

• Is this a completely new build?
• Is an existing solution to be replaced?
• Or is current software being extended?

This distinction affects the effort involved, the risks and the questions a provider will ask.

Also gather the surrounding conditions that are often missing from enquiries: internal contacts, the preferred way of working together, any existing documentation, and known interfaces to third-party systems. A requirements specification describes, from the client’s perspective, what the software is meant to do without anticipating the technical implementation.

A practical step before requesting proposals is to create a project outline based on your description or requirements specification. This helps reveal follow-up questions, gaps and an initial assessment of the project. If you are looking for support with that, it is worth reading what should be included in an enquiry or tender. The guide on how to approach this in a structured way can also make preparation easier.

Which criteria you can use to compare providers

One key criterion is experience with similar projects. What matters here is not whether a provider comes from exactly your industry. More important is whether they have already delivered comparable requirements, such as portals, apps, databases or interfaces between existing systems. To assess this, review comparable project types and examples of work.

Technology expertise is equally important, but from a decision-maker’s perspective. The technologies used should fit the project’s goals, your existing IT landscape and future operations. .NET is a development framework for web applications, apps and interfaces. Azure is Microsoft’s cloud platform for hosting and extending solutions. SQL databases store structured business data. A provider should not simply mention these building blocks, but be able to explain clearly how they fit together. You can use the overview of typical service areas around bespoke software as a useful point of reference.

For business software, identity and access often matter as well. If existing user accounts need to be integrated, Microsoft 365 and Entra ID may be relevant. So ask how the provider takes logins, roles and access rights into account within the project.

If AI functions are planned, it is worth looking at this area separately. This might mean searching company knowledge, assistants or extracting information from documents, for example. Azure OpenAI is a service for AI functions within the Microsoft environment. Here, the key issue is less the buzzword and more whether the provider can clearly explain limitations, data sources and the practical benefit.

Examples from similar types of project can be useful, even without the same specialist context. This might be a web platform for managing sewer networks, a CRM system for an insurance broker, or an extension linking Azure DevOps with planning software.

Give technology and collaboration equal weight. Clarify, among other things:

• Who will be your fixed points of contact?
• How are decisions documented?
• How often are review meetings held?
• How are changes recorded, prioritised and assessed?

A transparent project process also helps with assessment: getting to know each other, concept and design, development with regular reviews, quality assurance and go-live, followed by support and further development. For individual aspects, changes during the course of the project, early prototypes, technical debt, documentation and the role of software testing can also be informative. Open questions are often best clarified in a short initial meeting.

How to read proposals correctly and compare them fairly

Do not compare proposals solely on the basis of the quoted cost range. More meaningful is the basis on which a proposal was prepared: what assumptions were made, what scope of work is included, what is explicitly excluded, and which points are still open?

Major differences between two proposals do not automatically mean that one is more suitable. Often, the deviation simply comes from providers working from different understandings of the project. That is why it is worth comparing the underlying substance before setting figures side by side.

Pay particular attention to which deliverables are described. It should be clear:

• what exactly will be delivered,
• what belongs to the concept phase,
• what is part of development,
• and what is included in commissioning.

Also check whether important topics have already been taken into account or may be added later. These include, for example, design, interfaces, data migration, testing effort and support with the go-live.

It is also sensible to allow for changes during the course of the project. In many projects, requirements evolve over time. A change request is an agreed adjustment to scope, priority or implementation. The crucial point is whether the proposal clearly explains how such changes will be handled.

Transparency in collaboration is just as important. Ask: What review meetings are planned? Who signs off interim results? How are priorities set and documented?

Documentation and source code handover should be clearly regulated in the contract. This is not legal advice; contractual matters should be reviewed by a lawyer. The same applies to data protection, accessibility and other regulatory requirements: raise these topics early and clarify them with your legal department, data protection officer or specialist advisers.

Warning signs with providers and proposals

Caution is advisable if a provider produces a seemingly precise proposal very quickly, even though requirements, goals and existing systems have barely been discussed. With bespoke software, a reliable picture usually only emerges after follow-up questions.

A lack of follow-up questions is therefore often a warning sign in itself. Complex projects can rarely be understood without clarification. If a provider hardly asks about users, processes, data sources or existing applications, it remains unclear what their assessment is actually based on.

Also watch out for unclear responsibilities in key areas:

• Who is responsible for quality assurance?
• Who prepares the documentation?
• Who looks after operations and support after go-live?
• Who is actually doing the development, and who coordinates concept, design and implementation?

Another signal is an overly narrow focus on functions alone. Good conversations are not only about what the software should be able to do, but also about how people will work with it and which systems need to be integrated.

For AI projects, you should also listen carefully. If only benefits are promised, but limitations, data sources and organisational requirements are barely mentioned, caution is sensible. Also check whether a provider’s examples and way of working are presented in a way you can follow.