The introduction happened in a hallway. The office manager grabbed my elbow, steered me toward a new hire, and said, "This is our computer person." I had been engaged, nine weeks earlier, to build one integration between the scheduling system and the invoicing system. One.
This is a small business outsourced IT engineer story, and it's more common than anyone admits. A 40-person company has real software problems and zero software staff, so the first engineer who fixes something becomes the engineer for everything.
Here's how that happens, what it looks like week to week, and where to draw the lines before you wake up administering a printer.
Can one embedded engineer effectively serve as IT for a small business? For the software layer, yes: automation, integrations, reporting, and internal tools fit one competent person on a retainer comfortably. The model breaks the moment it includes hardware, security incidents, and being on call, so the boundary conversation is not optional; it is the entire job.
How I Became the Computer Person
The drift is always gradual and always flattering. Week one you fix the integration. Week three someone asks if you can also pull that report automatically. Week six you're in the leadership meeting explaining why the CRM numbers don't match the accounting numbers, and everyone nods like you've always worked there. Scope creep by gratitude.
Nobody plans to hire a one-person IT department. It crystallizes the day the owner does math: a full-time IT hire costs $85k plus benefits for skills the company needs maybe fifteen hours a week, while the weird engineer on retainer already knows where every body is buried. Outsourced IT for small business usually means an MSP ticket queue; this was something else, an engineer who builds things, sitting in the kitchen. The ninety-day logistics engagement ended the same way; you arrive for a project and stay as infrastructure.
A Small Business Outsourced IT Engineer Story: the Actual Week
An illustrative week at the 40-person company. Monday: an automation that chases unsigned quotes dies because someone renamed a folder; fixed, plus a monitor so it fails loudly next time. Tuesday: build the dashboard the owner checks every morning, the one that replaced her 7 AM spreadsheet ritual. Wednesday: a new hire needs accounts in six systems, so you script it and hand the office manager a one-page runbook.
Thursday is the printer. The printer is always Thursday. You look at it, it looks at you, and you say the sentence that saves the relationship: "That's hardware, and hardware is Brad from the MSP down the street." Then Friday you ship something real, because Friday is for shipping. The rhythm should feel familiar if you've read the legacy ERP integration saga: half the job is integration, half is expectation management, and the ERP outlives everyone.
Runbooks matter more than the scripts. A good one fits on a page: what the thing does, what breaks it, how to restart it, and who to call when the restart fails, in that order, with screenshots. The office manager keeps hers in a shared folder labeled, without irony, "Computer Person Stuff." It has twelve entries now, and she has used exactly one of them, which she mentions at every quarterly review like a badge.
The Boundary Conversation
The retainer survives on a written in-and-out list. In: business software, automations, integrations, reports, vendor wrangling for SaaS tools, and being the technical adult in purchasing decisions. Out: hardware, networking, phishing incidents, password resets, and anything requiring an on-call schedule. The out-list is not a rejection of the client; it's what keeps the in-list affordable.
Write it in week one, not month nine. Month nine you have norms instead of boundaries, and norms are just boundaries that lost a fight. The list gets reviewed quarterly over coffee, and it gets shorter in the "in" column over time, which is a sign the engagement is healthy rather than shrinking.
My test for any borderline request sorts it into work that compounds and chores that recur. Chasing unsigned quotes compounds, because the automation keeps working after you leave. Resetting a password recurs forever and belongs with the MSP, the office manager, or literally anyone whose day rate is lower than yours.
What It Cost and What It Replaced
Illustrative math, because owners think in math. The company before: a managed service provider at $1,800 a month covering hardware and helpdesk, plus roughly 25 staff-hours a week of manual reporting and re-keying, call it $3,000 a month in loaded time, plus the quiet cost of decisions made on stale numbers. The company after: the MSP keeps the printers at $1,800, the fractional engineer retainer runs about $4,500 a month for a day a week, and the manual hours drop to five.
Net: a bit more cash out, a lot less drag, and an owner who reads a dashboard instead of interrogating three people. The math only works because the engineer also builds; a pure advisor would leave those 25 hours on the table forever.
Structure the retainer so both sides can plan. Ours was one fixed day a week plus a defined lane for async fixes, with unused hours rolling one month forward and no further. Rollover sounds generous; it's actually self-defense, because an expiration date turns December into a festival of make-work requests. And put the rate in the same email as the boundary list. The two conversations are easier together than apart, and neither improves with age.
When This Model Works and When It Does Not
The sweet spot is 20 to 60 people, no dedicated IT staff, and pain concentrated in workflows rather than infrastructure. Above that range the company needs real employees, and you become a weird single point of failure with a retainer. Compliance-heavy environments are another no: if the business needs formal security programs and audit evidence, it needs a team, not a person with opinions and a laptop.
Hero dependency is the failure mode that ends engagements. If your vacation requires a memo, you've built a job, not a system. Small business automation should compound quietly in the background; the moment the business holds its breath when you board a plane, the model has already failed and nobody has admitted it yet.
How to Set It Up So You Can Leave
Make yourself optional; that's the honest goal of the one-person IT department. Every automation gets a runbook. Every script lives in a repo the client owns. Every quarter you run a handoff drill where someone else, anyone else, restarts the thing that breaks most. The handoff success story is the gold standard: leave behind systems a competent stranger can operate.
The quarterly handoff drill is the part everyone skips and shouldn't. Pick the automation that broke most recently, hand the runbook to whoever drew the short straw, and watch them restart it while you say nothing. It takes twenty minutes and fails constantly at first, which is the point: every failure is a runbook edit. After three drills the office manager could recover the invoicing pipeline alone, and the next time I flew somewhere, nobody noticed.
Nine months in, the new hire from the hallway introduced me to someone else. "This is our computer person," she said, "but the good kind, the kind who wrote everything down." It remains the nicest performance review I've ever received, and the only one delivered at walking speed.