Four requirements for a technical partner who steps up when things break

Your campaign is live, visitors are pouring in and the webshop gets slower by the minute. Or the integration with your stock system stops while orders keep arriving. You call the developer, who points at the hosting. The hosting company sees nothing odd on its side. That is the moment you find out which requirements for a technical partner actually matter. The portfolio and the sharp quote that won you over do very little for you now.

In many companies the technology has ended up spread over several parties over the years: a developer, a hosting provider, an agency and another specialist for the integrations. As long as everything runs, you barely notice. When something fails, the discussion about who fixes it begins.

Below are the four requirements I would judge a partner on, in the order I would test them. Scalability is last on purpose. You are free to disagree.

An untested backup does not count

Plenty of parties can build. The question is who makes sure it keeps working. Continuity lives in hosting, monitoring, backups, updates, security, documentation and recovery after an incident. Nobody looks at any of it while everything runs. On the day it stops running, this is exactly what decides how long you are down.

Ask about the details. Are outages detected automatically? Does your partner have insight into performance, disk space, error messages and security risks? How often are backups made and where are they stored?

The question that tells you the most: when was a backup of your environment last restored to check that recovery works? A backup that has never been tested is mostly an assumption. If the answer stays vague, you know enough.

Also check whether your partner looks ahead. Outdated software versions, expired certificates and servers reaching their limits rarely come as a surprise to a party that manages actively. My rule of thumb: if a customer tells you your certificate has expired before your partner does, nobody is managing actively.

Ownership starts when nobody knows the cause

With separate suppliers, the cause of an outage quickly becomes a matter of debate. The hosting company points at the application, the developer at an API and the supplier of that API at the configuration. Meanwhile your organisation waits.

A partner who manages development and infrastructure together can establish faster where things go wrong. That partner cannot remove every external cause either. What you do get is someone who coordinates the analysis, brings in the right parties and keeps track of progress. If your business runs on those systems every day, that difference is big.

Ownership is hard to spot in a quote. You see it in the collaboration. Questions get asked before anything is built. A risk is named, even when the message is uncomfortable. And after an incident the fault is fixed, followed by a look at how to prevent it from happening again.

The strongest signal, to me, is a partner who tells you a request is technically possible but adds little to the business. That partner leaves work on the table to save you money.

Then put in writing what can be put in writing: who is responsible for hosting, releases, security updates, monitoring and contact with external suppliers, which systems are critical and which response times go with them. Also agree who makes the decisions within your own organisation. The sharper that is on paper, the faster people can act.

Placing development and hosting with one party has a price: you become more dependent on that party. You keep that dependency manageable with technical choices that can be explained, properly arranged access and knowledge that is written down somewhere instead of living in one person's head. Check today whether you hold the login details for your hosting, your domain name and the place where your code lives.

At LJPc, custom development, hosting and technical management come together. That allows LJPc to deliver an application or integration and stay responsible for the environment it has to perform in every day.

Good support tells you when the next update comes

A generic ticket system with long waiting times falls short when customers cannot order or your platform is unreachable. You want to speak to someone who knows which systems are running and how they fit together.

I would drop a hard five-minute response time as a requirement. Complex faults need investigation, testing and sometimes consultation with external suppliers, and that does not go faster because it is in a contract. Test the communication instead. You hear quickly what is known, which action is under way and when the next update comes, in language you do not have to translate into your own operations.

Match your expectations to the rhythm of your business. A B2B portal asks for something different than a webshop with peak load in the evening. A publisher cannot wait when publishing stalls, while a SaaS platform depends mostly on constant availability and predictable releases. Ask about the approach to incidents and, if your business also runs in the evening, about availability outside office hours.

If the fault sits in custom software, whoever takes the report must be able to switch straight to whoever knows the code. When hosting, management and development are not connected, even a small problem takes far more time than it should.

Build for the growth you can see coming

This point comes last because a partner who meets the first three requirements is usually honest about what you need to grow as well. A year from now you may have more users, an extra sales channel or a manual process that needs automating. That does not require a complicated enterprise platform today. What you do ask is that today's choices do not block that growth.

A good partner therefore asks questions that go beyond your request:

Which data needs to be available?
Which other systems need to connect?
Where are the manual steps today?
Which peaks do you expect, and what happens when the number of transactions doubles?

The answers decide whether a straightforward integration is enough or a more flexible architecture is the wiser choice.

The same sobriety applies to custom work. Off-the-shelf software is a fine choice when the process is generic and your organisation can adapt to the package. Custom work pays off where your edge lies, for example in the way you serve customers or process data. Too much custom work makes maintenance more expensive than necessary. Too much standardisation pushes people into workarounds, spreadsheets and double entry.

Sometimes a small internal tool is the best solution. Sometimes an API integration between existing systems is enough. And sometimes a core application has to be rebuilt, because repairing it ends up costing more than renewing it. A test I like: ask a partner which part of your wish they would deliberately not build custom. Anyone who wants to make everything custom has not weighed that trade-off yet.

Test the requirements for your technical partner today

You do not have to replace all your technology first to get a better grip. Pick the process with the biggest consequences if it stops: ordering, planning, publishing, customer contact or data exchange. Write down which systems are involved, who manages them and where the dependencies are.

Take that overview to your current partner, with these questions:

When was a backup of this environment last restored?
Who coordinates when the cause lies between two suppliers?
Who takes the report, and does that person know the code?

If you get a quick, concrete answer, you are in good shape. If your partner has to look it up first, you have found your first point to improve.