what does a "technical partner" mean?

the term gets used loosely, so here's the version we mean. most of the companies we work with have no engineer on staff and no IT department. software still runs the business: the website, the booking system, the spreadsheet that turned into the source of truth without anyone deciding it should, the mailboxes, the domain. each of those has an owner in theory and nobody in practice. a technical partner is the team that takes that ownership on, across all of it, so a problem never falls into the gap between "the agency that built it" and "the person who left".

what that looks like month to month

four things, held whether or not there's a project running:

• context: why the system works the way it does and which parts are fragile, so you never re-explain your business
• the perimeter: who has access to what, and what happens when someone leaves
• the bill of materials: what runs where, what it costs, and what's approaching end-of-life
• the next decision: the one or two changes that would most improve your position this quarter

the mechanics are plain. an agreed block of hours each month, a shared channel instead of a ticket portal, and priorities you set and re-cut whenever you want. some months that's a new internal tool; some months it's a copy tweak and a backup restore test. same people every time.

what it isn't

it isn't unlimited work for a flat fee; anyone offering that is capping it invisibly. nor is it a support desk you file requests into. and it doesn't last forever: there's a company size at which hiring engineers wins outright, and a good partner tells you when you've reached it.

the longer version is in what a technical partner does (and what it doesn't). for how it's priced, see what a retainer costs.