what a technical partner does (and what it doesn't)

Most companies buy software the way they buy a roof: once, from a contractor, and then they hope. It works for roofs. It works badly for software, because software has dependencies that expire, hosting bills that change, and a security surface that grows every time someone signs up for a new tool.

The alternative is a technical partner. The term gets used loosely, so here's what we mean by it, and what it isn't.

The project model, and where it breaks

You define a scope, an agency builds it, they hand it over, and the relationship ends. This is a good model when the thing you need is finite. A campaign microsite. A one-off integration. A rebrand.

It breaks in a specific and predictable way. Roughly eighteen months later:

• a dependency hits end-of-life and the site starts throwing warnings no one can explain
• the contact form stops delivering, silently, and you find out from a customer who thought you ignored them
• the domain renews to an inbox belonging to someone who left
• a bigger client asks for your security policy and there isn't one
• the person who built it has moved on, and nobody wrote down how any of it works

None of these are build problems. They're ownership problems, and the project model has no answer for them because the project ended.

What a partner holds

A technical partner holds four things continuously, whether or not there's an active project:

1. Context: why the system works the way it does, what was tried and rejected, which parts are fragile. That's the expensive thing to rebuild, and you pay for it again every time you switch vendor.
2. The perimeter: who has access to what, which accounts exist, what's exposed to the internet, and what happens when someone leaves.
3. The bill of materials: what runs where, what it costs, what's approaching end-of-life, and what would happen if any one of them disappeared tomorrow.
4. The next decision: the one or two things that would most improve your position in the next quarter. It's deliberately smaller than a roadmap, and kept current as the business changes.

Where it stops

A partner arrangement has an agreed capacity rather than unlimited work for a flat fee. Anyone offering unlimited is either capping it invisibly or planning to lose money and then your goodwill. What separates it from a project is that the capacity is yours to point at whatever matters this month.

If the arrangement is filing requests into a portal and waiting for a reply, you've bought outsourced support, which is a different and cheaper product.

There's also a company size at which having engineers on staff wins outright. A good partner tells you when you've reached it. A bad one keeps billing and says nothing.

How to tell which one you need

Count how many of these are true:

• Software is load-bearing for how you operate, not just how you market
• Nobody's job title includes responsibility for it
• You couldn't confidently list every system that holds customer data
• Something technical has surprised you in the last six months
• You've been asked a security question by a customer or insurer

At zero or one, buying projects works fine. At three or more, the surprises will keep arriving, and preventing them costs less than answering them.

The honest trade-off

A partner costs more per month than nothing, which is what most companies currently spend on this. What you get for it is that the failures above stop being events and become maintenance: caught early, and mentioned in a monthly note rather than a panicked phone call.

That's the whole pitch. It's not exciting, and it isn't meant to be.

We work this way at rebootworks: three practices under one contract, month to month, and you own everything. If anything on the list above sounded familiar, tell us which one.