You have a shortlist of vendors and a draft job spec open in two tabs. Someone suggested you also look at bringing in a consultant rather than a full-time hire. And somewhere in the back of your mind is a third option: do nothing yet, and revisit in six months.
This article is a frame for that decision, not a pitch for any one answer. Three paths exist and each one is the right answer for a specific set of conditions. The goal here is to give you the lens to find your conditions, not to steer you toward a particular path.
The audience is a founder or COO who already has a real AI use case on the table, at least one vendor demo behind them, and a decision to make. The frame is honest about all three options, including the one where the answer is not yet.
The three paths
In-house AI engineer. You hire someone with the technical skills to build and run AI systems. They join the team, learn the product, and own the AI layer from the inside. The capability becomes part of your organization.
Consultant or contractor. You bring in someone for a defined scope. They build a working system, document it, hand it off, and leave. You own the output. The capability is transferred rather than embedded.
Wait. You defer the decision until the signal is clearer. This is not a passive option. It is an active decision to spend the next period validating the use case before committing to building against it. For some companies right now, this is the right call, and the frame below makes clear which conditions point there.
All three paths get equal weight in what follows.
When in-house is the right answer
Four signals that point toward hiring an AI engineer:
The AI workload is ongoing, not scoped. You do not have one thing to build; you have a stream of AI work that will continue as long as the product exists. New models to evaluate, prompts to maintain, integrations to extend, edge cases to handle in production. That kind of continuous workload needs someone inside the organization, not someone available by arrangement.
AI is in the core value proposition. If your product is, in meaningful part, what the AI does, the people who understand that AI should be on your team. Consulting engagements are scoped; product AI is perpetual. A consultant who ships the first version is not the right owner of the fifth iteration.
Your team has the capacity to absorb technical decisions over time. Every system accumulates choices that looked right initially and need revisiting later: model upgrades, prompt rework, dependency changes, edge cases that surface six months after launch. An in-house engineer carries that continuity. A handoff document cannot.
Your runway supports carrying an FTE through the ramp period. An in-house hire takes time to reach full productivity. The return on that investment comes after they have learned the system, the codebase, and the users. If your runway does not comfortably support a senior technical salary through the period before you see meaningful contribution, the timing may not yet be right.
The post on hire an LLM engineer at a small company goes deeper on what to look for in a candidate and which questions to use in the process.
One dimension of the in-house path that is easy to underestimate is the evaluation challenge. Assessing a senior AI engineer when neither the founder nor the COO has a deep technical background means relying on prior work samples, references, and how candidates explain what they have built. The linked post is structured around exactly that constraint: signal questions that work even when the interviewer cannot independently verify the technical claims.
There is also key-person risk worth naming directly. If you hire one AI engineer and that person leaves after six months, you have a production system and nobody left who understands it at the level of detail needed to change it safely. In-house does not eliminate that risk; it concentrates it. The answer is documentation and redundancy, both of which require deliberate investment from the start. The decision is still often the right one, and it is worth making with that constraint in view.
When a consultant is the right answer
Four signals that point toward a consulting engagement:
The task is defined and scoped. You have one specific thing to build: one integration, one automation pipeline, one AI layer on a specific product feature. It is describable. It has a clear output. When the output exists, the work is done.
You need a working system faster than a hire can produce one. A new technical hire takes weeks to onboard before writing production code. A consultant with relevant experience can start building in the first week. If timing is a factor in your decision, that difference matters.
You are not ready to commit to full-time cost before validating the ROI. A scoped engagement lets you test whether the AI use case works in production before adding to your permanent headcount. If the validation fails, the cost is bounded. If it succeeds, you have a system and evidence to hire against.
You need an external perspective on an existing system. An audit or architecture review is also consulting work. If you have a system that was built by someone else and your team is uncertain about it, a structured review is a legitimate starting point.
For a more detailed map of what early-stage AI consulting actually produces and how to find the right person, the piece on AI consulting for early-stage startups covers the three consultant types you will encounter and the questions to ask before signing anything.
The quality of a consulting engagement comes down to what you have at the end. The gap between a consultant who produces a black box and one who produces something your team can own is mostly visible in how the handoff is planned. A well-structured handoff includes architecture decision records alongside the code, not as a later addition. These are written notes on why significant technical choices were made: which model or vendor was selected and why, what alternatives were considered and rejected, which components are most likely to need revisiting as the underlying technology changes. Without them, the team inheriting the system has code they can run but cannot reason about confidently when something needs to change. Test coverage is the other component that separates a transferable system from one that requires the original author to modify safely. A mid-level generalist engineer who was not part of the build should be able to run the test suite and understand what each test is verifying. If they cannot, the handoff has a gap that will surface at the worst possible time.
When wait is the right answer
Wait is not the same as deciding not to decide. It is a decision to gather a specific piece of information before committing, with a date by which you will revisit. Three signals that point there:
The use case is not yet confirmed by actual demand. If you do not have real users doing a real thing that an AI feature would improve, building now produces a system that solves a hypothetical. The right next move is more user discovery, not a faster path to a system that was never actually needed.
The team cannot absorb a new system right now. Back-office automation with AI looks straightforward until it needs maintenance and nobody has capacity to own it. A working system handed to a team at full capacity becomes a liability, not an asset. If your team cannot take on something new right now, waiting until they can is the correct decision.
The problem is solvable without custom AI this week. If an existing tool handles the task with configuration, a custom build is overhead without return. The right filter: can you describe the specific output in one sentence, and is that output something an off-the-shelf product cannot already produce? If the answer to the second question is no, defer.
Active waiting looks different from passive delay. It means running a manual version of the process you eventually want to automate, doing the work by hand on real data to test whether the outcome is actually useful to the people who would use it. It means trying one or two existing tools against your specific use case before commissioning a custom build. And it means setting a concrete calendar date to revisit the question with a defined checklist: is the use case now confirmed by real demand, does the team have capacity to receive and own the output, and is the problem still not solvable by configuration? If yes on all three at that date, the decision is ready to make. If not, the waiting continues with a clearer picture of what still needs to resolve.
What changes six months later for each path
If you hired in-house: you have a person with AI competence on the team and production code in your own repository. You also have that salary in your monthly burn regardless of whether the AI feature is running at capacity or sitting idle. Beyond the fixed cost, the in-house path means someone on your team is responsible for tracking model updates, API version changes, and deprecations as they happen. When a language model provider retires a version your system depends on, your engineer handles that migration. When a new approach emerges that could reduce inference cost or improve latency, your engineer evaluates it. That ongoing maintenance ownership is what in-house actually buys over time. The capability is yours; the technical evolution is your team's responsibility to manage.
If you engaged a consultant: you have a working system, architecture documentation, and a maintenance plan. The custom LLM integration in practice post describes what a complete handoff contains: a running system, documented architecture decisions, and a model dependency map the next person can read. That documentation tells your team how to run what exists, but it does not produce new features on its own. Adding something new requires either a new engagement or an internal engineer to extend the work. A documented system your team owns is what a good engagement produces. The maintenance plan is the document that determines whether the handoff holds over time: a good one names the categories most likely to need attention after the engagement closes, whether model provider changes, prompt behavior drift after model updates, or infrastructure dependency changes, and who on your team handles each category.
If you waited: you have the same questions you had six months ago. The market has continued to move. Vendor pricing has changed. Candidates with the right skills are in higher demand. The window to validate your use case before a competitor does is shorter. Waiting is a valid choice; waiting without naming a specific trigger to revisit it is a different thing. The paths are not closed: a company that waited and used that time to confirm demand and name an internal owner is now better positioned to act than the one that rushed into a build without those answers.
Decision matrix
The rows below are the signals that most reliably separate the three paths.
| Signal | In-house | Consultant | Wait |
|---|---|---|---|
| AI workload is continuous and ongoing | Fit | Partial fit | Not fit |
| AI workload is a single bounded delivery | Not fit | Fit | Partial fit |
| Team capacity to own and maintain | Fit | Fit | Not fit |
| Time to working system is critical | Partial fit | Fit | Not fit |
| Use case demand is confirmed | Fit | Fit | Not fit |
If your rows mostly land in "wait," wait. If they split between in-house and consultant, the first two rows decide it: continuous work points to in-house; a single bounded delivery points to consultant. The other rows add weight in one direction or the other but rarely override the workload shape.
Three questions before you decide
Can you describe the specific output in one sentence? If yes, a consulting engagement is likely the right format. If not, you are still defining the problem, not ready to build a solution to it. A consultant cannot scope work that the client cannot describe.
Who on your team will own this system six months from now? Name a person, not a role that does not yet exist. If you cannot name someone, you are not ready to receive a handoff, which means the consultant path requires you to first answer the hiring question anyway.
What is the cost of being wrong on each path? If you hire and the use case does not warrant a full-time person, you carry a salary while you work out what else that person should own. If you bring in a consultant and the scope expands, you have a working system that needs extending sooner than planned. If you wait and a competitor ships first, you pay for the delay. None of these outcomes is a catastrophe; all of them are real and worth naming before you decide.
The paths are not permanent choices. A company that correctly chose wait six months ago may now have a confirmed use case and a team with capacity. A company that correctly chose consultant may now have enough ongoing work to justify an in-house hire. What you are reading in the frame above is the current state of your conditions, not a label for the business.
If the consultant path fits, that is what klim.expert is for. If not, that is also fine, this piece is a frame not a pitch.
