Software Development for SMEs: How to Place an Order the Right Way?

Most SMEs don’t end up with expensive, protracted development projects because they choose a “bad developer,” but because they don’t specify the work clearly enough. Software development isn’t a product you can just pick off the shelf: if the goal, scope, acceptance criteria, and operations aren’t clearly defined, even the best team will be left guessing.

In this article, you’ll find a guide to SME-friendly procurement: what to prepare before you start looking for a supplier, how to request quotes in a way that allows for comparison, and what minimum requirements you should include in your contract and at the start of the project.

1) Start with a business goal, not a list of features

Saying “we need an app/CRM/portal” is typically a bad place to start. A good project is built around a business problem, and only then does it translate that into specific features.

Describe it in 5–10 sentences:

• What is the goal (for example, reducing lead time, lowering the error rate, streamlining the sales pipeline, or reducing the workload on customer service)?

• Where can it be measured (in which process, in which system is the baseline)?

• Who is feeling the pain right now (which team, what costs or loss of revenue)?

• When do you consider it a success (1–3 KPIs, target values, time frame)?

If you're looking for a quick guide to help you decide whether to buy off-the-shelf software or commission a custom development project, you should take a look at this article: Custom Software Development vs. Off-the-Shelf Software: When to Choose Which?

2) A "good brief" isn't long—it's testable

A common mistake made by SMEs is falling into two extremes:

• or there are only 1 or 2 sentences (“we need a system”),

• or a 40-page document full of assumptions and premature conclusions.

The purpose of a good brief is to ensure that the supplier understands exactly what you mean and that there is an objective basis for acceptance at the end.

Minimum brief content (don’t request a quote without this)

1. Context and Objective
A brief description of the company, the process, and the business objective.

2. Users and Key User Journeys
Who will use it (sales, finance, customers, admin), and what are the key processes.

3. Scope boundaries and non-scope items
List at least five items each for what is definitely included and what is definitely excluded (this reduces scope creep).

4. Integrations and Data
Which systems need to be integrated (ERP/CRM/invoicing/warehouse), in which direction does data flow, and who is responsible for the system?

5. Non-functional requirements (NFR)
Performance, availability, logging, access control, data retention. The ISO/IEC 25010 quality model serves as a useful reference here, as it helps break down quality into “categories.”

6. Acceptance Criteria and Measurement
What makes a feature “ready,” and what tests and data are used to verify this?

A simple, SME-friendly template (printable)

• Goal: (for example) reduce the time required to submit a bid from 2 days to 4 hours, and lower the rate of incorrect bids to below 3%.

• Users: Sales (10 people), Back Office (4 people), Administration (2 people).

• Key processes: lead capture, generating quotes from templates, approval, and customer notification.

• Integrations: CRM (currently X), invoicing (Y), email (M365).

• NFR: SSO preferred, MFA for administrators, audit logs required, access based on roles.

• Exclusions: The mobile app is not part of the MVP, and the BI dashboard is not part of the first phase.

3) Don’t order development right away; start with discovery

If there is a lot of uncertainty in the brief, the best investment is often a short discovery phase (1–3 weeks), the purpose of which is not to write code, but to prepare for decision-making and mitigate risks.

Typical outcomes of a well-conducted discovery:

• Clarification of objectives and KPIs, method for baseline measurement

• Map of processes and pain points

• Integration map and data inventory (at least at a high level)

• MVP scope, release plan (staggered rollout)

• Risk list and dependencies

• Estimation range and scheduling options

This logic is reflected in several Syneo articles, such as the one on predictable delivery: Project Management in IT: How to Ensure Predictable Delivery

4) Request for quotes: you can only compare them if you ask for the same thing

A "send me a quote" request usually yields three completely different quotes, and not because someone is playing tricks, but because everyone interpreted the task differently.

A good request for proposals should include:

• the brief (above)

• requested phases (such as discovery, MVP, and then optional scaling)

• required deliverables (specifications, design, tests, documentation, operating instructions)

• Expected communication schedule (weekly demo, status update, steering meeting)

• minimum security requirements (at least access control, logging, backup, and confidentiality)

If you need to conduct a more formal procurement process, this template can serve as a starting point: RFP template for the procurement of ERP, CRM, and custom development

Evaluation criteria (not just price)

In addition to pricing, ask about these as well:

• Who will actually make up the team (names, roles, resources), not just the “company”?

• How are change requests handled, and what constitutes the scope?

• How are they tested, and what is the acceptance process?

• What you receive upon delivery (source code access, documentation, and instructions for running the program).

• Do they have a DevOps and operations approach (monitoring, logging, release process)?

5) Pricing models: the key isn’t what’s cheaper, but what’s more manageable

As an SME, the typical goal is to operate with predictable risks. Choosing a pricing model is a strategic decision in this regard.

6) Contractual minimums (which will prevent the project from becoming a “legal battleground”)

This isn't legal advice, but from the client's perspective, there are certain key points that, if overlooked, can easily lead to delays and disputes during development.

Things worth noting

Scope and Acceptance
The acceptance criteria, and what constitutes a defect versus a change.

Change Management (CR)
Who decides when and how to modify price, schedule, and scope?

Ownership and Access
Source code, repository access, build pipeline access, and handover of documentation. (If the vendor “keeps everything in-house,” that poses a serious risk.)

Data protection and security
Minimum requirements: role-based access control (RBAC), logging, confidentiality, backups, incident management. The OWASP Top 10 is a good sanity check because it helps avoid basic mistakes.

Warranty and Support: What constitutes a warranty repair, what constitutes a modification, and is there a HyperCare period after go-live?

7) Project Launch: Predictability Depends on Governance

Ordering software development doesn’t end with the signing of the contract. Most SME projects fall apart because there is no designated decision-maker, no rhythm, and the backlog ends up being “a little bit of everything.”

Minimum roles (can be combined, but must have a name)

• business owner (who is responsible for the KPIs)

• a product owner-type role (sets priorities, makes decisions)

• Tech Lead (technical decisions, quality)

• Operations Manager (if you don't have one, you'll regret it later)

Minimum rhythm

• weekly demo (working prototypes, not slides)

• Weekly Status (Risks, Dependencies, Decisions)

• Biweekly or monthly steering meetings (scope, costs, schedule, go/no-go)

If the team works with DevOps, the rhythm and measurability are much more stable; this is supported, for example, by : DevOps Fundamentals: The Path from Zero to Production in 2026

8) Handover and operation: make sure to arrange this right from the start

As an SME, it’s common to find out at the end of a development project that there’s no monitoring, no backup policy, no incident response process, and that “someone will handle it.” This is the most expensive option.

Make this clear in your request for proposals:

• where it runs (cloud/on-prem), who is the service owner

• What logs and metrics will be available, and who will have access to them?

• What are the backup and restore requirements?

• How does the release process work (who approves it, when, and with what rollback options)?

9) Red flags worth paying attention to

You don't need to be alarmed by everything, but these are typically signs of a problem:

• “We’ll do this for a fixed price,” even though there’s no scope or NFR yet.

• There's no mention of integration or data—just the UI.

• There is no testing or acceptance plan; it’s just “we’ll test it later.”

• The supplier is unable to name a person responsible for operations and safety.

• Everything is unique; nothing is reusable; nothing is standard.

Quick Checklist: How to Successfully Commission Software Development as an SME

• Have 1–3 KPIs and a baseline in place before you start discussing features.

• Include at least a brief (scope, non-scope, integrations, NFR, acceptance).

• Start with discovery when there’s a lot you don’t know.

• Request a comparative quote (deliverables, timeline, team, CR process).

• Choose a pricing model that accounts for uncertainty (the phased approach is often the best choice).

• Specify the acceptance, change management, and source code access in the contract.

• Make sure to order the minimum operational requirements as well, not just the development.

Frequently asked questions (FAQ)

How much information do I need to request a quote? At a minimum, a 1–2-page brief: objectives and KPIs, key processes, scope and non-scope, integrations, basic NFRs, and acceptance criteria. If you don’t have this, it’s better to request a discovery phase.

As an SME, should I choose a fixed price or T&M? If the scope is stable and well-defined, a fixed price can work. If there is a lot of uncertainty (processes, data, integrations), T&M or capped T&M, combined with a phased approach, generally involves less risk.

What is discovery, and why should I pay for it? It’s a brief exploratory phase aimed at clarifying the project’s goals, scope, integrations, risks, and estimates. It’s worth the investment because it reduces delays and costs that can arise from misunderstandings later on.

What makes software "ready for acceptance"? Acceptance requires predefined acceptance criteria (functional and non-functional), test evidence, and a handover package (documentation, access rights, and operational instructions).

When should you use a mini-RFP? If you want to compare multiple suppliers in a structured way, or if you need to provide a transparent evaluation to internal decision-makers. Useful as a starting point: RFP template for procuring ERP, CRM, and custom development

Next step: Reduce your risk with a quick assessment

If you’re an SME planning to develop software, the quickest way to improve quality is usually not by adding “more features,” but by refining the client’s requirements, clarifying the scope, and ensuring a smooth handover.

The Syneo team provides digital and IT consulting, custom development, and implementation support to assist you throughout the entire process, from discovery to go-live. To get started, check out our articles or contact us via our website: syneo.hu