Power BI Consultant vs In-House Hire
Should you hire a Power BI consultant or build the capability in-house? The decision framework, the costs nobody budgets for, and how to combine both.
Every organisation serious about Power BI reaches the same fork: hire someone, or bring someone in. It usually gets decided by whichever budget line has room, which is the worst possible basis for it.
Here is the framework we would actually use, with no numbers in it - because the right answer rarely turns on rate comparison, and a rate comparison is the most misleading way to look at it.
The question underneath the question
"Consultant or hire?" is really three questions wearing a coat:
- Is this work finite or continuous?
- Do we need depth we do not have, or capacity we do not have?
- How expensive is being wrong?
Answer those honestly and the staffing decision usually answers itself.
Where an in-house hire wins
The work is continuous. Reports need owners. Semantic models need someone who notices when a measure starts behaving oddly. Access requests, refresh failures, onboarding new analysts - this is operational work that never finishes, and paying an external rate for it indefinitely is poor value.
Context compounds. An internal person learns your business, your data's peculiarities and which stakeholders say "revenue" when they mean something else. That knowledge is hard to transfer and it accrues. It is the single strongest argument for hiring.
You want the capability to stay. If the goal is for your organisation to be good at analytics, someone has to be accountable for that internally. No external arrangement substitutes for ownership.
Volume justifies a full workload. A full-time person is good value when there is full-time work. The in-house failure mode is not cost - it is a skilled hire spending half their week on things that did not need them.
Where a consultant wins
The work is finite and specialist. A capacity migration, a semantic model refactor, a governance framework, a performance crisis. These are projects with ends. Hiring for a project means either carrying the person afterwards or managing an exit, both of which cost more than they appear to.
You need depth you cannot justify employing. Most organisations do not need a full-time VertiPaq specialist, or someone who has designed RLS for a regulated environment a dozen times. They need that person for three weeks. This is the clearest case of all.
You do not yet know what you need. This is underrated. If you cannot write the job description, you are not ready to hire - and writing a wrong job description is expensive, because you then hire against it. An assessment engagement is a cheaper way to find out what the role should be.
Being wrong is expensive. Architecture decisions made early and badly - the wrong capacity, the wrong model grain, security bolted on afterwards - get more expensive to unwind every month they survive. Where the cost of a wrong decision is high and your team has not made that decision before, buying experience is rational.
You need it now. Hiring takes months. Some problems do not wait.
The costs nobody budgets for
On the hiring side, the salary is the visible part. Also real: recruitment, the vacancy period while you search, ramp-up before they are productive, management overhead, training to keep skills current, and the cost of carrying the role through quiet periods. And the risk that one person holds all the knowledge and then leaves.
On the consulting side, the engagement fee is the visible part. Also real: your team's time briefing and reviewing, the risk that knowledge leaves with the engagement if handover is not explicitly scoped, and dependency if you keep buying the same capability instead of building it.
Neither list is an argument against the other option. Both are an argument for counting properly.
The honest answer for most organisations: both
The common pattern, and the one that tends to work:
- Hire for ownership and operations. Someone internal who owns the platform, knows the business and is accountable for it day to day.
- Buy for spikes and specialism. Bring in depth for the migration, the architecture, the performance crisis, the governance build - with knowledge transfer written into the scope rather than hoped for.
That gives you continuity where you need continuity and depth where you need depth, without paying for either when you do not.
A test that settles most cases
If you still cannot decide, ask: what happens to this work in twelve months?
- Still there, every week, at similar volume → hire
- Finished, or reduced to maintenance someone else can absorb → engage
- Genuinely unknown → engage first, and let the engagement tell you what role to hire for
That last branch is the one people skip, and it is usually the right answer when the real problem is that nobody is sure what good looks like yet.
One thing to insist on either way
Whichever route you take, insist that the outcome is documented and transferable. An in-house hire who is the only person who understands the semantic model is a risk, not an asset. A consulting engagement that ends without handover has rented you a result rather than built you a capability.
The staffing model matters less than whether the knowledge survives the person.
*This is a decision framework drawn from engagement experience, not a research study - there are no survey figures here because we have not run one. Weigh it against your own context.*
Frequently Asked Questions
Should I hire a Power BI developer or use a consultant?
It depends on whether the work is finite or continuous. Continuous work - report ownership, semantic model care, access requests, refresh failures, onboarding analysts - favours an in-house hire, because context compounds and paying an external rate indefinitely is poor value. Finite specialist work such as a capacity migration, a model refactor or a governance build favours an engagement.
What costs do people forget when hiring a Power BI person in-house?
The salary is the visible part. Also real: recruitment, the vacancy period while you search, ramp-up before productivity, management overhead, ongoing training to keep skills current, carrying the role through quiet periods, and the key-person risk of one person holding all the knowledge.
What if I do not know what role I need yet?
Then you are not ready to hire, because you cannot write the job description - and writing a wrong one is expensive, since you then hire against it. A scoped assessment engagement is a cheaper way to find out what the role should be, and it produces a job description grounded in your actual estate.
Can I do both?
That is the pattern that usually works. Hire for ownership and operations, so someone internal is accountable day to day and accumulates business context. Buy for spikes and specialism - migrations, architecture, performance crises, governance builds - with knowledge transfer written into the scope rather than hoped for.
How do I decide quickly?
Ask what happens to this work in twelve months. Still there every week at similar volume, hire. Finished or reduced to maintenance someone else absorbs, engage. Genuinely unknown, engage first and let the engagement tell you what role to hire for.