# Procure Software & Services Selecting software and service providers for the implementation of a digital public service is not limited to verifying technical qualifications and comparing prices. It requires a holistic assessment of: * Provider capacity * The quality of service * Alignment with government technical and security standards * And the ability to deliver long-term value, interoperability, and sustainability of digital public services. It is important to apply clear, transparent and objective selection criteria when picking a provider. Governments can use international procurement frameworks to orient themselves with well-established principles of procurement when selecting software and digital service providers. Frameworks such as the [EU Public Procurement Directive (2014/24/EU)](https://eur-lex.europa.eu/eli/dir/2014/24/oj/eng), the [UNCITRAL Model Law on Public Procurement](https://uncitral.un.org/en/texts/procurement/modellaw/public_procurement) and the [World Bank Procurement Framework](https://www.worldbank.org/ext/en/what-we-do/project-procurement/framework) provide guidance on the underlying principles for fair, transparent and competitive procurement of providers. Countries may utilise these frameworks as inspiration when shaping or strengthening their own procurement rules. This will enable governments to promote procedures that safeguard public interests and ensure high‑quality and sustainable digital service delivery. The EU Public Procurement Directive (2014/24/EU), the UNCITRAL Model Law on Public Procurement and the World Bank Procurement Framework suggest similar core principles of provider procurement. They encourage fair and transparent selection processes, equal treatment of bidders, and promote non-discriminatory evaluation based on clear, fit for purpose selection criteria. The frameworks emphasize that contracts must be awarded on the basis of the best price‑quality ratio, and must be supported by evidence of technical capability, value for money, and sustainable delivery. Moreover, they provide mechanisms to prevent abuse and manage risk, including strong transparency obligations, and governance processes that ensure accountable decision‑making. Overall, these frameworks enable governments to identify reliable providers and design procurement processes that are competitive and are aligned with long‑term public interest.

Source: World Bank Procurement Framework, figure representing the core procurement principles of the World Bank Procurement Framework.

The World Bank’s Procurement Framework advises to translate “value for money” into clear, testable technical requirements and encourages governments/ procurement agencies to engage in early market feedback mechanisms. This helps in validating feasibility of the proposed requirements of an intended solution and the delivery approach before the Request for Proposal is issued. In digital projects, this can be operationalized using GovStack Specifications ([GovSpecs](https://govstack.global/our-offerings/govspecs/)). These Specifications help translate technical capabilities into vendor‑neutral, evidence‑based requirements that can be used in procurement. Moreover, the GovStack framework helps to translate high‑level procurement obligations, like transparency, value for money, interoperability, and competition, into a step‑by‑step process. The following section introduces the **GovStack‑Aligned Procurement Process**, which shows how governments can move from high‑level planning to clear, testable, and locally adapted requirements. ### **The GovStack‑Aligned Procurement Process** Applying the GovStack approach in practice follows a logical sequence that ensures that the technical requirements are clear before engaging with the market and before procurement begins. This methodology defines the procurement journey into five clear steps:
{% stepper %} {% step %} ### **Design Service** Teams begin by defining user needs, objectives, and the desired service outcomes. In this step, teams identify and formulate the problem to be solved and clarify the service journey. The [*Design Service*](https://specs.govstack.global/implementation-playbook/implementation/design-service) chapter of the GovStack Implementation Playbook can be consulted for further guidance. {% endstep %} {% step %} ### **Design Architecture** Based on the service design, architects identify the relevant Building Blocks, cross‑cutting requirements, data flows, and system integrations that are required to deliver the service. The [*Design Architecture*](https://specs.govstack.global/implementation-playbook/implementation/design-architecture) chapter of the GovStack Implementation Playbook provides further guidance on structuring the underlying technical landscape. {% endstep %} {% step %} ### **Adapt GovSpecs to local needs** GovSpecs are used as a technical capability reference and must be tailored to reflect national policies, and existing systems. Adaptation involves: * Mapping GovSpecs to local workflows, data models, and regulatory constraints * Defining where local APIs differ and specifying adaptors where needed * Adjusting functional and non‑functional requirements to fit the national context * Documenting any justified deviations for architectural governance This step produces a Software Requirements Specification (SRS) document that can be used as a procurement annex, making sure that requirements are testable and vendor‑neutral. {% endstep %} {% step %} ## **Collect Market Insights** Once the adapted SRS is drafted, governments can deploy early market engagement to validate feasibility, costs, interoperability claims, and maturity of the solution. This step helps refine requirements and ensures tenders reflect what the market can realistically deliver. After early market engagement, governments can use GovMarket, a platform that acts as a matchmaking tool to help institutions discover GovStack‑aligned software solutions and connect with potential service providers. Next, the section on differentiating between software and service provider research helps institutions distinguish between evaluating a product (software) and evaluating the service delivery capability of the provider. Additionally, procurement links and guidance resources are provided in this chapter. These resources provide the regulatory context needed to move from market research into formal procurement. Together, these elements complement early market engagement and feed directly into the next step of the GovStack‑aligned process: the procurement of software and service providers. {% endstep %} {% step %} ### **Evaluate Software & Service Providers** Governments can run a procurement process based on transparent, objective criteria, after receiving feedback from the market on the Specifications. The SRS becomes the primary reference for evaluation, and the providers must demonstrate how their proposals meet each requirement. {% endstep %} {% endstepper %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://specs.govstack.global/implementation-playbook/implementation/procure-and-launch-services/procure-software-and-services.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.