When a single IT consultant is enough, when you need a whole team, and what really separates one consultancy from another.
In short
Hire a single IT consultant when your team works but lacks one specific skill. Buy a development team when the work needs several roles that collaborate every day. Choose project delivery when you can describe the result and how it will be accepted, and want the supplier to own the route. Compare the work left with you, not day rates.
An IT consultant is the right purchase when you already run a functioning team and are missing one clearly defined capability. A development team fits when the work needs designers, developers and testers who depend on each other. A project delivery fits when the outcome and its acceptance can be written down before work starts.
The models often overlap. A team can work inside your product organisation or deliver a bounded project. The label on a proposal therefore says less than the answers to three questions: who prioritises the work, who makes the technical decisions, and who runs the result once the supplier has moved on? This guide is written by Devies, a Gothenburg-based product and engineering consultancy, for CTOs, product leaders and procurement teams in Sweden and the Nordics who buy software development (systemutveckling) from outside.
Three ways to buy software development
There are three common ways to buy software development from outside: a single consultant, a development team or a bounded project.
A single IT consultant (staff augmentation)
Staff augmentation is the practice of adding an external person to a team you already lead. You own the backlog, set the priorities and remain responsible for the whole. The consultant brings a skill you lack, for example a backend developer, a data engineer or a UX designer.
A development team
A development team is a group that already works together, often combining developers, testing and design in one unit. The team takes more responsibility for how work is planned and carried out, but you still need a product owner who decides what matters most. The Scrum Guide describes that role as accountable for maximising the value of the product and for managing the backlog, and that accountability rarely transfers well to a supplier.
Project delivery
Project delivery is a purchase of a defined outcome, such as a migration or an integration with a named system. The supplier is responsible for reaching the agreed result within the limits of the contract. That only works when scope, exclusions and acceptance are clear from the start.
Cost and risk: what you are really paying for
The total cost of buying development depends far more on how much work stays inside your organisation than on the hourly rate.
A cheaper IT consultant can become expensive if your own leaders have to cover architecture decisions, testing, coordination and code review. A team with a higher monthly cost can work out cheaper if it absorbs coordination that would otherwise consume the time of your internal managers.
Risk is also distributed differently:
- Single consultant: you carry the delivery risk. If the person leaves, knowledge can disappear, especially if they became the only one who understands part of the system.
- Team: risk is spread across several people, but coordination between your team and the supplier's team becomes a new risk if nobody owns it.
- Project: the supplier carries more of the delivery risk, while you carry the risk of having specified the wrong thing. A fixed scope written too early can turn every new insight into a contract discussion.
Short-term speed also hides long-term cost. Work delivered fast without tests, documentation or handover often returns later as maintenance effort. If that pattern sounds familiar, our planned guide on when technical debt justifies modernisation covers how to measure it.
When an IT consultant, a team or a project fits
Each model fits a different combination of internal capability, uncertainty and ownership, and the table below shows where the lines usually fall.
Use the table as a basis for the conversation with a supplier. The exact split of responsibility must always be agreed for each engagement.
Question
Single IT consultant
Development team
Project delivery
Who prioritises the work?
Single IT consultant
Your existing lead
Development team
Agreed product owner, usually from your side
Project delivery
Agreed project or product owner
What are you buying?
Single IT consultant
A defined capability
Development team
Coordinated delivery capacity
Project delivery
An agreed outcome within limits
Who covers missing roles?
Single IT consultant
Usually you
Development team
Must be stated in the team scope
Project delivery
Must be stated in the project scope
How is "done" judged?
Single IT consultant
The role's contribution and agreed tasks
Development team
Accepted increments and team goals
Project delivery
Agreed acceptance criteria
What happens after delivery?
Single IT consultant
Knowledge transfer plan
Development team
Continuity plan
Project delivery
Explicit operations and support agreement
Best when
Single IT consultant
The need is narrow and your team works
Development team
The work needs several dependent disciplines
Project delivery
The goal and acceptance can be described upfront
Signs that you picked the wrong model:
- The consultant often waits for decisions or access. You are missing leadership or product ownership, not capacity.
- The team delivers, but nobody on your side can explain what was built. Knowledge transfer is missing.
- The project has become a stream of change requests. The problem was too uncertain for a fixed scope, and a discovery phase or staged delivery would have suited it better.
A hypothetical example
Picture a marketing department that wants to publish on its own, needs a new web interface and wants to measure the effect. The company has an internal product owner but no web team. A frontend consultant is enough if backend, CMS and testing capability exist elsewhere. If those dependencies are missing, a coordinated team fits better. Once content, integrations and acceptance criteria are investigated, the migration itself can be bought as a bounded project.
How to evaluate an IT consultancy
The real difference between two IT consulting companies shows in how they work and what they take responsibility for, not in their list of technologies. Ask these questions before you compare prices:
- Which responsibilities do you take, and which do you leave with us? Ask for the answer in writing, role by role.
- What did a similar engagement look like? Ask for a concrete client case with technology, team size and timeline, not just a logo.
- How does the team plan and review its work? Several people from the same company are not automatically a team.
- Which roles are not included? A "complete team" may still assume your product owner, security expertise or operations staff.
- How is continuity secured? What happens if a key person leaves, and how is work documented as it goes?
- How are uncertainty and change handled? Delivery model and pricing model are separate decisions. A project does not automatically mean a fixed price.
- What does handover look like? Who can release new versions and restore the system after the supplier has moved on?
- How will we see progress? Agree on a few delivery measures early. As of October 2026, DORA's software delivery metrics cover change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.
Include your own contribution in the assessment. A supplier needs to know whether someone on your side can answer questions every week, who grants system access and who approves delivered work. Without those answers, every estimate of time and cost is uncertain, whichever IT consultancy you choose.
Devies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
Should we hire an IT consultant or a development team?
Hire a single IT consultant when your team already works well and lacks one specific skill, such as backend or data engineering. Choose a development team when the work needs several roles that depend on each other every day, such as design, frontend, backend and testing in the same release. If you lack product ownership, neither model fixes that on its own.
What is staff augmentation?
Staff augmentation is a way of buying development where an external consultant joins a team you already lead. You keep the backlog, the priorities and the responsibility for the result, while the consultant fills a defined skill gap. It works best when your organisation can give the person clear tasks, quick decisions and access, and plans knowledge transfer from day one.
Is project delivery always fixed price?
No. Delivery model and pricing model are separate decisions. A project can be priced at a fixed sum, on time and materials, or in stages. Ask the supplier what is included, which exclusions apply, how uncertainty is handled and at what point changes affect cost. A fixed price set before the problem is understood often leads to repeated change requests.
How do we compare quotes from IT consulting companies that propose different models?
Compare the work that stays with you, not only the supplier's price. For each quote, list which roles, decisions, testing and operations tasks it assumes you will cover, and estimate that time. A lower day rate that leaves coordination, architecture and handover with your team can cost more overall than a higher rate that includes them.
