How to Choose a Software Development Supplier

What choosing the right supplier actually means#

Choosing a software development supplier means deciding who takes responsibility for a system that touches several departments at once - IT, finance, production, HR or procurement. Projects rarely run in isolation from existing systems; they connect to an ERP, a CRM, a document system and reporting tools, which makes the decision organizational as well as technical. The customer needs to know who will be on the supplier's team, how communication will work, where data will be stored, and who is responsible for the system once it launches.

It matters whether a supplier takes on an entire project - from requirements analysis and architecture through development to launch and support - or only a specific segment, such as an integration or a single feature set. Both approaches are valid; the difference lies in who is responsible for connecting the pieces and for full testing before anything goes into production. Decide in advance whether you are looking for one accountable supplier or several specialized partners for different parts of the project.

The choice of supplier also affects the employees who will use the system every day. A supplier unfamiliar with production, HR or procurement workflows tends to produce a system that needs frequent fixes after launch. It is worth checking whether the supplier has experience in your industry and whether the project includes business analysts who translate domain requirements into technical specifications the development team can act on.

Which competencies and team composition to check#

Before choosing a supplier, find out who will actually work on the project. Larger projects that touch several systems at once require a broad set of roles, not just developers - solution architects, technical leads, DevOps and cloud engineers, cybersecurity specialists and QA engineers. A supplier should be able to explain which roles it will assign to your project and why, based on the scope and complexity of the system being built or upgraded.

Within Epix and its specialist partner network, project teams can be assembled with relevant education and experience - from graduates in computer science, software engineering and information systems to professionals with more than ten, fifteen or twenty years in the field. The network also gives access to staff holding certifications in cloud, security and project management, while standards such as ISO 9001, ISO 20000/20001, ISO 27001 and ISO 27701 are part of the network's delivery structure, not a claim about any single person.

Also check whether the supplier has experience in your industry. The specialist partner network Epix works with covers experience in, among others, the public sector, banking, insurance, healthcare, telecommunications, energy, logistics, manufacturing and education. Industry experience shortens the time needed to understand your processes and reduces the risk of a solution that is technically correct but not actually usable by your teams.

• Senior engineers
• Solution architects
• Technical leads
• Full-stack developers
• DevOps and cloud engineers
• Cybersecurity specialists
• QA and test automation engineers

What to check in references and past projects#

References reveal more than a pitch meeting because they show how a supplier behaved in real circumstances. For the Kwizmo project, for example, Epix developed an AI software solution for applying artificial intelligence to internal data, documentation and business processes, including AI agents, a RAG system, document processing, integrations and automation. A project like this shows whether a supplier can connect AI to a customer's real internal data, not just a demo scenario.

In the public sector, a relevant reference is the Zdravo Jem project for the Municipality of Sevnica, where Epix developed a software solution and interactive content for a public space on a 55-inch touchscreen, including kiosk environment configuration, hardware and software integration, on-site installation, documentation and support. In public-sector work, it matters whether a supplier understands accessibility, documentation and long-term support requirements, not only application development itself.

When reviewing references, pay attention to scope - whether the supplier owned the project end to end, from analysis to support, or delivered only one segment. Ask how handover worked: who received access credentials, documentation and passwords, and how it was ensured that source code and data remained the customer's property. These details say more about a supplier's reliability than general claims of experience.

• Whether it was a new build or a takeover of an existing system
• Whether the project involved integration with other systems
• Whether the project was in a regulated industry or the public sector
• Who was responsible for documentation and post-launch support
• How extensive testing was before go-live

How a supplier handles existing systems and data#

Most projects at companies with more than a million euros in annual revenue don't start from a blank slate; they require connecting to an existing ERP, CRM, document system (DMS/ECM) or production system. A supplier must also be able to take over an existing or unfinished system, which means reviewing the source code, architecture, infrastructure and data before proposing next steps. Without that review, any estimate of scope or risk is just guesswork.

For integration with existing systems, Epix and its partner network build and connect ERP, CRM, DMS and ECM systems through APIs tailored to each environment. We deliberately do not name specific system vendors until an integration has actually been confirmed on a concrete project - and as a customer you should expect the same: ask a supplier to show how it plans to connect your existing systems, not just claim it can in principle.

It also matters how a supplier separates environments. Development, test and production environments must be kept separate, and real personal data must not be used in the test environment. Changes go through review and testing before reaching production. Source code and data remain the customer's property, while documentation, access and passwords are part of the handover - whether the project is new or a takeover of an existing system.

Data security and risk management#

Data security is one of the key criteria for choosing a supplier on projects that connect several business systems. The question isn't whether a supplier understands the concept of security, but who within its team or partner network actually covers each area - from security architecture and penetration testing to vulnerability management, identity and access management (IAM), and incident response.

Within the specialist partner network Epix works with, staff hold certifications in security and cloud, and standards built into the delivery structure include ISO 27001 and ISO 27701, which address information security management and data privacy. These standards are not attributed to Epix Group d.o.o. directly but to the network, which can be brought into a project depending on its complexity and industry - for example in the public sector or regulated activities.

The practical side of security shows up in everyday work: separate development, test and production environments, no real personal data in test environments, and clear rules on who can access production data. Ask a supplier to describe these rules concretely for your project rather than in general terms - that is where the difference shows between a supplier that treats security as an ongoing process and one that treats it as an afterthought.

• Security architecture
• Penetration testing
• Vulnerability management
• Identity and access management (IAM)
• Infrastructure hardening
• Incident response
• Cloud security

Testing and quality before go-live#

Software quality doesn't show up in a demo; it shows up in daily use after launch, which is why testing practice is worth checking in advance. A supplier should be able to describe the test scenarios it uses, the balance between manual and automated testing, and how it tests individual components (API testing) and the system as a whole after every change (regression testing).

Automated testing typically relies on tools such as Playwright and Cypress, run within a CI/CD pipeline so tests execute on every code change, not only before major releases. Before taking ownership of a system, the customer performs acceptance testing against criteria agreed in advance, so it is clear when a given segment is complete and ready for production use.

For more demanding or regulated projects, it is worth asking whether independent QA, separate from the development team, is available. Independent testing reduces the risk that defects go unnoticed, because someone who didn't write the code reviews the system from an end-user perspective. This matters especially for systems that employees across several departments will use daily.

• Test scenarios
• Manual testing
• Automated testing (Playwright, Cypress)
• API testing
• Regression testing
• Testing within CI/CD
• Acceptance testing

Project management, accountability and communication#

On projects that run for a longer period and involve several of the customer's departments, organizing the work matters as much as technical skill. On larger projects, Epix assigns a project manager, defines each team's responsibilities, sets deadlines, and agrees on how communication and reporting to the customer will work, so it is clear at any point who is responsible for which part of the system.

Agree in advance how often you will receive progress reports, who your point of contact is on the supplier's side, and how scope changes during the project are handled - these are normally treated as requests that must be estimated and scheduled, not assumed to be included in the original agreement. A clear division of responsibility between the customer's departments and the supplier's team reduces delays caused by uncertainty over who must approve a given decision.

At the end of a project or a segment, handover follows: source code and data belong to the customer, and documentation, access and passwords are part of the formal handover. Insist that handover terms are defined in the contract itself, not agreed informally afterward, since this is where ownership and access disputes most often surface.

Support and maintenance after go-live (SLA)#

Choosing a supplier isn't only about who builds the system, but also who keeps it running afterward. After go-live, a supplier can take over monitoring, bug fixing, technical and security updates, and continued development. The scope of support is defined per project, so it's worth asking upfront exactly what support includes and what remains the customer's responsibility.

Support issues are typically classified by business impact. Class 1 is an outage, where the system or a critical part isn't working and handling gets top priority with a response time agreed in the support contract. Class 2 is a disruption, where the system runs but a specific function doesn't. Class 3 is a minor defect with no business impact, scheduled into the next release, and Class 4 is a change request, where scope is assessed and a timeline agreed.

We don't publish universal response times in hours or days, because they depend on the system's criticality and the agreement with the customer - a system supporting production or a public service typically warrants a different response time than an internal reporting tool. Ask a supplier to write the response time for each class into the support contract, rather than accepting a general promise of fast response.

• Class 1 - outage: system or critical part down, handled with top priority
• Class 2 - disruption: system runs but a function doesn't
• Class 3 - defect: minor issue with no business impact, scheduled into next release
• Class 4 - request: change or upgrade, scope and timeline agreed separately

How project scope and price are determined#

The price of software development isn't a fixed figure that can be quoted before requirements are reviewed; it is determined after reviewing the scope, functionality and technical complexity of the project. Rather than general price ranges, it's more useful to understand what actually drives the price, since that helps a customer prepare a more realistic request and compare proposals on the same basis.

Several factors influence scope, and with it price, at the same time, so it is worth reviewing them before preparing a request for proposal. These are the questions a supplier will typically ask at a first meeting, and only on that basis can it estimate project complexity. If a customer hasn't thought through these answers in advance, the initial phase of collaboration stretches out and the scope estimate stays less precise.

Before pricing, it makes sense to run a short analysis that breaks the project into segments, so each one can be estimated and delivered separately. This lets a customer decide which segments are needed immediately and which can follow in a later phase, while giving the supplier a more accurate estimate without guessing at scope.

• Scope of functionality and number of user roles
• How many existing systems need to be connected and what their APIs look like
• Whether it's a new system or a takeover and upgrade of an existing one
• Volume and condition of data that needs to be migrated
• Security, audit-trail and compliance requirements
• Scope of AI work and required accuracy
• Level of post-launch support and agreed response times

Steps for choosing a supplier#

Put together, these criteria turn supplier selection into a process rather than a one-off decision based on a proposal. Start by defining whether you need a supplier for the entire project or for a single segment, then check who will actually make up the project team and what experience they have with similar systems or your industry.

Next, check how the supplier handles existing systems and data, what its security and testing practices look like, and how post-launch support is structured, including defect classes and response times. Finally, check how handover of source code, data, documentation and access is defined, since this part of the contract often determines how independent you will be once the project ends.

For an organization running several systems at once, this kind of systematic review matters more than comparing prices between vendors, since choosing the wrong supplier usually costs more than time - it risks data, processes and the employees who will use the system every day. Criteria defined clearly before the choice reduce the chance of disputes during and after delivery.

• Define scope - entire project or a single segment
• Check project team composition and industry experience
• Check how existing systems and data are handled
• Check security and testing practices
• Agree on defect classes and post-launch support
• Define code, data and documentation handover in the contract