In-house or technical partnership: who keeps it running?

The developer who built your customer portal and integrations has handed in their notice. During the handover weeks it becomes clear how much lives only in their head, such as how a release goes live and where the backups are. That is when choosing in-house or a technical partnership suddenly becomes very concrete.

At many companies the technology grows without anyone planning it. The website got a customer portal, systems had to exchange data and staff got internal tools. Somewhere along the way that technology became a condition for generating revenue and helping customers, and the question of who is responsible grew with it.

In-house or technical partnership: count the tasks

Doing it in-house sounds like filling one vacancy. You hire a developer and the knowledge is in-house. Now set that against the work a running application involves:

• architecture
• security
• testing
• releases
• cloud or server management
• monitoring
• incidents
• documentation

A good developer covers part of that. Someone who builds well is not automatically a system administrator, DevOps specialist or security expert.

Write a name next to every task. If the same name appears next to half of them, you know what those handover weeks will look like.

Look past the salary in your business case. Recruitment, onboarding, knowledge transfer, tooling and cover for sick leave all cost money, and so do the hours of maintenance work that never show up on the roadmap.

Build internally when software is your product

We mainly recommend your own team when software is your primary product and you are continuously developing new functionality. A SaaS company with a clear roadmap, sufficient funding and room for several specialised roles benefits from short lines of communication between the business and the people who build. For fast product decisions that can be a real advantage.

Highly company-specific processes are a second, weaker argument. An external party can build up that knowledge perfectly well. For quick product choices it helps to have someone close to those processes every day.

What we would skip is the small team that also handle hosting, security updates, performance and out-of-hours support on the side. Your entire digital operation then depends on a few people, and you only notice when one of them is away.

Builder and host under one roof

For companies whose digital systems are business-critical but who do not want to become a full tech company, a partner is the more obvious route. An e-commerce business wants orders to keep flowing. A publisher wants capacity during traffic peaks. An agency wants to deliver projects without managing a separate supplier for every specialism, and a platform wants to keep growing while its infrastructure grows with it.

You see the difference the moment something stops working. The builder points at the host, the host points back, and meanwhile the problem persists. A party that knows the application and the integrations as well as the infrastructure looks for the cause in one place and knows the problem is theirs.

That is why at LJPc we build and host under one roof in Assen. Every application or integration we deliver comes with the question of how it stays stable afterwards and who keeps an eye on it as you grow.

You stay in control. A good partner shows you what is running and which risks are in play. For proper control you need to know which agreements apply, how incidents are handled and who decides.

Give your partner the context of your business

A partnership stalls when you keep technology at arm's length and only call when something is broken. Your partner then becomes a ticket factory that fixes what you report without knowing what it means for your business.

If you ask for an API integration, also explain which process stops when the integration fails, which data has to be error-free and when the pressure is highest. With that context a partner can tune the monitoring and the fallback to your busiest moments.

In return you can expect a partner to be open about dependencies and maintenance. A quick fix that is hard to maintain six months from now can end up costing more than a slightly better technical foundation today.

Four questions that decide it

Doing everything in-house or outsourcing everything are the two extremes. Go through these four questions first, ideally with the people who deal with outages now.

1. How critical is downtime? If an outage directly hits your revenue, your service or your reputation, you need more than ad hoc development capacity. Then monitoring, reachability, backups and clear escalation count just as much.
2. How predictable is the work? A steady stream of product development can justify an internal team. Varying projects or specialist problems are often handled more efficiently through a partner.
3. Which knowledge really has to stay in-house? Process knowledge, product strategy and decision-making authority usually belong in-house. In-depth knowledge of hosting or complex integrations does not always need to be.
4. Who fixes it when it breaks on a Friday afternoon? It means whoever fixes the outage then, even if someone else formally owns it. If you cannot fill in a name here, your technical organisation is not set up properly yet.

We give that last question the most weight, because the first three are about how you organise things and this one shows whether that organisation works.

Keep control in-house, outsource the operations

If we had to recommend one model for a company whose product is not software, we would choose a mix. Keep a product owner or digital lead in-house, possibly with some development capacity of your own, and work alongside a long-term technical partner. Business knowledge stays close, and for specialist knowledge and continuity you have someone who already knows your systems.

We are such a partner ourselves, so feel free to read this advice with that in mind. We think the task list at the top of this article points this way for many companies.

The trade-off is distance. A partner does not sit in on your meetings every day, so someone in-house has to make the product decisions and guard the priorities. This model only works when the roles are agreed in advance. You decide what comes first and which result is needed. The partner advises on feasibility, builds, manages and flags risks. You plan larger changes together, well before anything goes wrong.

Your own people also fight fewer fires this way. Routine maintenance and releases sit with the partner, and your team has time left for product development and improving the business.

Agree on what happens during an outage

Compare quotes on more than rates and development hours, and look at what they say about response times, points of contact, maintenance windows, ownership of code and infrastructure, documentation and the way changes go live. Those are the agreements you reach for on a bad day.

During the selection, ask a technical question as well. Do you get someone on the line who understands what is going on, or does your question disappear into layers of account management and tickets? How that conversation goes says a lot about how they will handle an outage.

Also pay attention to the moments when a partner says no. A reliable party points it out when a request creates risks, when an existing solution needs cleaning up first or when investing in stability is wiser right now than adding new functionality.

Go through the list of eight tasks from the beginning of this article with your team this week and put names next to them, including the name of the person you call on a Friday afternoon. Where a name is missing or the same name keeps coming back, you can see what you want to build internally and what you hand to a partner.