The vacancy is open, but the market is empty
Anyone looking for an experienced AI engineer or fullstack developer today is competing with tech companies, banks and consultancies for the same small pool of people. Good engineers choose their employer, not the other way around. They want an environment with strong colleagues, modern tooling and work that matters technically. A recruitment process that takes months is not the exception, and after that it only begins: onboarding, learning the domain, the first useful delivery. For a company where software is not the core business, that means a long run-up before anything is running in the operation. That is not a reason to never hire anyone, but it is a reason to first determine whether you can still give that person forty hours of meaningful work per week two years from now.
When hiring your own people is the right choice
Hiring your own developers pays off when software is a structural part of your business model or your operation. Think of a company that develops its own platform, or an operation that needs new integrations, reports and process changes every week. But do not fool yourself with a single vacancy. One developer is a single point of failure: nobody to review their code, nobody to take over when they leave or fall ill, nobody to challenge architecture decisions. Serious in-house development means a team, with everything that comes with it: technical leadership, code review, replaceability. If you can sustain and use that, an internal team is the strongest option in the long run. If you cannot, one hire mostly buys you risk.
When a standard package or SaaS is simply enough
For generic processes you do not need to hire anyone or have anything built. Accounting, HR, standard CRM: mature packages exist for those and they do the job fine. The rule of thumb is simple. If your process is not fundamentally different from that of a thousand other companies, and the process is not part of why customers choose you, then buy a standard solution and adapt your way of working to it. And do not let a vendor talk you into custom work in that case. The question only becomes interesting once the standard package structurally pinches: exceptions that do not fit, manual work around it, exports to Excel to do the real work. That friction is the signal that your process is more domain-specific than the package can handle.
The gap in between: domain-specific work without a permanent team
Most companies that call us sit exactly in that gap. The process is too specific for a standard package, but the work is not structural enough to sustain an in-house development team. The external route exists for that situation, and it pays to look closely at what kind of party you bring in. A staffing agency delivers capacity and you remain responsible for the result. A project agency delivers and leaves. An operating partner takes responsibility for the result in production: building until it runs, milestones with go/no-go moments, and ownership of code and data that sits with you, not with the vendor. That last part also enables a hybrid model that works well in practice: an external partner builds the system, and one of your own employees grows into the functional owner who carries the system afterwards. That is a far more achievable vacancy than a senior AI engineer.
How to make the choice concrete
Ask yourself three questions, in this order. One: is software a structural stream of work in my company, or a catch-up effort of one to two years? Structural work justifies a team, a catch-up effort does not. Two: can I sustain a team, with at least several developers and technical leadership? If not, do not hire a single developer hoping it will work out. Three: is the process distinctive enough for custom software, or does the standard package mainly pinch because we do not want to change how we work? Be honest about that. And whichever route you choose: put in writing who owns the code and the data. An external party that stays vague about that is building its own lock-in, not your system.