I Was the Entire Technology Department for 10,000 Subscribers. The Hard Part Wasn't the Technology.

For two years I was the entire technology department of a subscription business with more than 10,000 active subscribers across multiple countries.

Not the lead of a department. The department.

Development, security, operations, design, marketing systems, and the business mechanics underneath all of it. I know how that reads. A list of disciplines usually means someone is passable at several and accountable for none. So let me make the opposite case, because I think the combination is the point rather than a compromise.

I did not start from a blank page. I inherited a decade of books, programs, and audiences that had been consolidated into a subscription product across Kajabi, Mighty Networks, VidApp, WordPress and WooCommerce, Stripe, Zendesk, and Cloudflare.

Every one of those is a defensible choice on its own. Together they are seams.

A customer's entitlement has to be true in five places at once. When it is true in four, someone is paying for something they cannot open, and they do not file that as an integration defect. They file it as "this is broken and I want a refund." The failure is technical, the symptom is financial, and the fix requires knowing both.

That is the pattern I would put at the center of everything below. In a small operation, almost nothing fails inside a discipline. It fails between them.

Here is the constraint that shaped the rest.

Two platforms we depended on did not offer the API access we needed. Not an expensive tier - not for sale. We were a paying customer with a legitimate need to move our own subscriber and content data between systems we also paid for, and the door did not open.

The usual options are all bad. Manual exports forever, which is a person doing a robot's job until they quit. Fragile UI scraping that breaks on every front-end deploy. Or an expensive migration off platforms that otherwise worked fine, paid for with months of disruption to customers who did nothing wrong.

I built the integration layer instead. I used AI as the spearhead for the reverse engineering - reading traffic, inferring the shape of undocumented endpoints, mapping response schemas, working out authentication flows - far faster than I could have alone. Then I wrote a stable internal API on top of what I found, with the failure modes named up front, because an interface you do not control will change without warning you.

That layer is what made everything downstream possible. Once our own data was addressable, automation, reporting, lifecycle messaging, and migration became engineering problems instead of negotiations.

The judgment I would keep: a vendor's product decisions are a constraint, not a verdict. And the corollary, which matters more - I wrapped it in an interface I controlled and monitored, because the responsible version of this is not the clever hack. It is the boring layer around the clever hack that tells you the moment it stops working.

I hardened OpenClaw into an agentic orchestration layer and pointed it at our own development cycle. Not a demo, not a prototype that impressed people in a meeting and quietly died - a system that did real work on a schedule and that I owned when it broke. When a workflow failed, I diagnosed and fixed it. Reliability was mine. That distinction is the entire difference between having agents and using them.

I put a fine-tuned model on the support queue. It absorbed the repetitive volume so that tickets needing judgment arrived at a human with context already attached rather than cold.

I wrote custom webhooks and n8n and Zapier workflows to connect proprietary software to the rest of the stack, so systems stopped requiring a person to sit between them relaying messages by hand.

What I did not automate is the more useful list. Refund disputes, cancellations with a complaint attached, anything where a wrong answer costs a customer permanently - those stayed with a person. Not because the model could not produce a plausible reply, but because a plausible wrong reply in those moments is more expensive than the labor saved. Knowing where that line sits is the actual skill. Everything on the other side of it is throughput.

An automation that costs more than the labor it replaces is a science project.

The instinct with LLM work is to send everything to the strongest available model. It is also the fastest way to build something you have to switch off at the end of the month. Most volume in a real workload is not hard. Classifying a ticket, extracting an order number, deciding whether a message needs a human - none of that requires a frontier model, and paying frontier prices for it subsidizes nothing.

So I routed by difficulty. Small and local models handled high-volume, low-ambiguity work on hardware I already owned. Hosted models were reserved for genuinely hard calls, escalated to deliberately rather than by default. Caps and budgets were part of the architecture, not something I discovered on an invoice.

Fine-tuning attacked the same problem from another direction. A smaller model taught our specific domain beat a larger general one on our actual tickets, at a fraction of the cost per call.

The simplification matters as much as the savings. A system with a clear rule about what goes where is one you can reason about at 2am. A system that sends everything to the most expensive endpoint and hopes is one you cannot debug, cannot forecast, and will eventually turn off. I also kept the stack portable - self-hosted where practical, open formats, minimal lock-in - so a vendor's pricing change was an inconvenience rather than a rebuild.

This is the part of a one-person technology department that people forget, and it is the part where being wrong is unrecoverable.

The business took payments continuously across several platforms, held subscriber records in multiple jurisdictions, and ran a support function with access to all of it. That is a real surface: payment data handling, access control across a stack where each vendor has its own permission model, secrets management, and the unglamorous discipline of knowing who can reach what and why.

Agents expanded that surface rather than shrinking it. An agent with tool access is a system that takes instructions from data - which means anything it reads is a potential instruction. Prompt injection, tool misuse, and data exfiltration through an automated pipeline are not theoretical risks once the pipeline touches customer records and payment context. I treated retrieved and ingested content as untrusted by default, and built the checks in front of the model rather than hoping the model would exercise judgment it does not have.

That instinct is older than the AI work. It comes from years of datacenter incident response, PCI and HIPAA-compliant environments, and internal penetration testing - being the person who had to find the hole before someone else did. What that background gives you is not paranoia. It is a realistic sense of which risks are worth engineering against and which are theater.

The other half of the job did not look like engineering at all.

I owned design and brand work, marketing support across paid social and lifecycle email, coupon and checkout mechanics, subscription and renewal messaging, and the analytics to tell whether any of it worked. I supported a German-speaking customer base and its localization workflows in a language I do not speak, which is its own lesson in building processes that do not depend on you personally being able to read the output.

And I still built product: custom application work from scratch in React, TypeScript, and Supabase, for what the off-the-shelf platforms could not do.

I list these together deliberately, because in a subscription business they are the same problem viewed from different angles. Checkout is a design problem, a payments problem, a copy problem, a trust problem, and an infrastructure problem simultaneously. Churn is not a marketing metric - it is what a broken entitlement, a confusing renewal email, and a slow support reply look like when you add them up at the end of a month. Someone who can only see one of those layers will fix the visible symptom in a way that quietly damages the others.

The prevailing story about AI at work is that it makes individuals faster. Type a prompt, get a draft, save twenty minutes. That framing is real but small, and it is why most AI adoption stalls at the level of a nicer autocomplete.

The larger shift is that one competent operator can now hold a surface area that used to require a team - but only if they build systems rather than consume outputs. Those are different activities. Asking a model to write your support reply is consuming an output. Building the thing that routes, drafts, escalates, logs, and refuses - then owning it in production for two years - is building a system.

The second requires everything the first lets you skip. Why the integration breaks. What should never be automated. Where a wrong answer costs a customer permanently. What it costs per call at volume. What it exposes when it reads untrusted input. How to instrument it so you find out before a customer tells you.

That is not an AI skill. It is an engineering and operations skill that AI now amplifies enormously. The people who get the most from the next few years will not be the ones with the best prompts. They will be the ones who already knew how to run things that stay up.

I came to that role from fifteen years across infrastructure and agency work - datacenter escalation at a hosting company, then technology leadership at an agency across a lot of client projects, for brands including Nickelodeon, Marriott, and Royal Caribbean. The old instincts turned out to be the load-bearing ones. Knowing what a failure mode is. Writing the runbook before you need it. Assuming the integration will break and designing for the moment it does. Reading a protocol closely enough to work out what it is really doing.

Agents did not replace that judgment. They made it worth more, because the ratio changed: less of the week spent executing, more of it spent deciding what should exist.

The support queue was never the hard part. Deciding what a system should do without a human in it - and being willing to own the answer - is the hard part.