Most agencies sell you something they've never had to live with. We took the opposite bet: before NAZCO took on a single client, we built an AI operating system to run our founder's own company — and we still run it there every day. That decision shapes everything we build for clients, so it's worth explaining what it actually is, and what it taught us.
We run on the same playbook we sell to clients. For the practical, step-by-step version of it, read our complete guide to AI automation for small business.
Why we run our own company on it
Our founder's company, Provyd, supplies peptides and related compounds for laboratory and research use. Like any new business in a regulated category, it had to do the work of a real company before it had any revenue: market research, compliance review, inventory math, content, SEO, customer intelligence, day-to-day operations, and reporting. Hiring a specialist for each of those would have burned the runway long before the first sale.
So instead of hiring a team it couldn't afford, we built it an operating system — the same kind we now build for NAZCO clients. We call it Hermes. The reason we run our own company on it is simple: if we're going to put a system at the center of someone else's business, we should be willing to put it at the center of ours first. Building for clients while living inside the thing we build keeps us honest about what actually works.
What it actually does
Hermes covers the recurring, first-pass output of the functions a lean company needs to run: watching the market, checking copy and claims for compliance, working out inventory and reorder math, drafting content and SEO, keeping an eye on customer signals, and sending the founder a plain-language briefing each day. It isn't a chat window you open when you remember to. It runs on a schedule, keeps a memory of the company, and produces source-backed work you can check — not loose answers you have to take on faith.
It's worth slowing down on each of those, because the headline ("AI runs the company") hides what's actually useful. None of this is exotic. It's the ordinary, unglamorous work that quietly eats a founder's week, done on time and written down. Here's what each category looks like from the outside, at the level of outcomes rather than wiring.
Market watch
In a research-compound category, the landscape moves: competitors change pricing, new suppliers appear, demand shifts, and the regulatory mood tightens or loosens. The system tracks that terrain and surfaces what changed, so the founder reads a short digest instead of opening twenty tabs. The win isn't speed for its own sake. It's that nothing important slips past on a busy week.
Compliance and claims review
This is the one that earns its keep. Everything Provyd publishes is research-use framing — no health or wellness claims, full stop. So copy gets read against that line before it goes anywhere near a customer. A single careless sentence can create payment-processor, platform, or legal exposure in a sensitive category. Having a tireless first reader that flags risky language early is worth more than any growth hack.
Inventory and reorder math
Stock decisions are boring until they're expensive. Order too much and cash sits on a shelf; order too little and you're out of the thing people came for. The system keeps the math current and brings a reorder recommendation with the reasoning attached. It never places the order. A person reads the logic, agrees or doesn't, and pulls the trigger.
Content and SEO
A new company is invisible until it isn't. The system drafts content, structures pages so search engines can actually understand them, and keeps the library growing instead of stalling after the founder's first burst of energy. Drafts are exactly that, drafts. They get reviewed and shaped by a person before anything publishes. The point is that the blank page is never the bottleneck.
Customer signals
Once people start arriving, they tell you things, through questions, hesitations, where they drop off, and what they ask twice. The system watches those signals and flags patterns worth acting on, rather than leaving them buried in a busy inbox. For a pre-launch company, that early feedback is gold, and the easiest thing in the world to miss when you're doing ten jobs at once.
The daily briefing
All of it lands in one place: a plain-language briefing each morning. Not a dashboard with forty widgets, a short read that says what changed, what needs a decision, and what's already handled. We've found this is the part founders feel first. You start the day knowing the state of the business instead of reconstructing it from memory and dread.
The part everyone gets wrong: it recommends, it doesn't act
The most important design decision isn't technical, it's a rule. The founder can ask something like "how much stock should we order?" and get back a researched, compliance-checked recommendation — but the system never places the order. Anything that spends money, publishes in public, or ships to a customer stops at a human approval gate.
In a sensitive category that guardrail isn't optional. One unsafe claim can create payment-processor, platform, or legal risk, so the system is built to bring a recommendation to a person, not to take the real-world action on its own. That's the same principle we put into every client build: the AI removes the busywork and the waiting, and a human keeps the final call on anything that carries risk.
The four things that make it actually work
People assume the magic is a smarter model. It isn't. After running our own company on this for months, we'd argue the model is the least interesting part. Four design choices do the heavy lifting, and any of them missing is usually why someone's "AI experiment" quietly died. We build all four into client systems for the same reason we built them into ours: without them, you don't have an operating system, you have a toy.
Persistent company memory
A chat tool forgets you the second you close the tab. Our system doesn't. It holds the company's context, what it sells, the rules it operates under, what was decided last week, so every output starts from the real situation instead of a cold start. Most "AI didn't work for us" stories are memory problems in disguise. A model with no memory gives confident, generic answers that don't fit your business. Memory is what turns a clever assistant into something that actually knows where it works.
Real tools, not just talk
An assistant that can only describe what should happen is a meeting, not an employee. The system is connected to the actual tools the work lives in, so it can read the real data and prepare real outputs rather than narrate from the sidelines. That connection is what makes the difference between "here's what you could do" and "here's the thing, ready for you to approve." Talk is cheap; tools are the product.
Source-backed outputs
Every recommendation that matters arrives with its reasoning and its sources attached. The founder can check the work, not just trust it. This is non-negotiable in a regulated category, where "the AI said so" is never an acceptable answer to a processor or a regulator. It's also how trust gets built day to day: you stop spot-checking once you've seen the receipts enough times, but the receipts are always there.
The human approval gate
We said it above and we'll say it again, because it's the line that makes the rest safe. Anything that spends money, posts in public, or ships to a customer stops at a person. The system can prepare everything right up to that edge. It does not step over it. That single rule is the difference between handing real work to a system and lying awake about what it might have done overnight.
Audit logs you can actually read
Because every step is recorded, there's always an answer to "why did it recommend that?" The trail isn't there to impress anyone. It's there for the day a decision gets questioned, by a partner, a processor, or your own future self. In our experience, the existence of a readable record changes how much you're willing to delegate. You delegate more when you can always retrace the steps.
The math: the output of ~10 roles, run by one founder
Put together, the functions Hermes handles map to roughly ten specialist roles — operations, compliance, market research, SEO, content, social, email, e-commerce, customer success, and business intelligence. At 2026 US salary benchmarks, that's on the order of $1.1M a year fully loaded. We didn't pay that. We pay a small fraction of a single hire to run the system on infrastructure we own.
The honest version of that number matters. Hermes does the first-pass and recurring output of those roles — it does not replace licensed counsel, an accountant, fulfilment, or the founder's judgment. The saving isn't "fire your team." It's "don't hire every specialist before the revenue exists to pay them." For a pre-launch company, that's the difference between launching and running out of road. You can see the full role-by-role breakdown on the Provyd case study.
We want to be careful with that ~$1.1M figure, because it's easy to wave around dishonestly. It's a rounded benchmark for what those roles cost at fully-loaded 2026 US salaries, drawn from published US salary data (BLS, Salary.com), not a promise that you'll bank the difference. Nobody actually hires all ten people at a pre-launch company, which is the whole point. The real comparison isn't "ten salaries versus a subscription." It's "the work gets done at all, on a founder's budget, versus the work not getting done and the launch slipping."
There's a second, quieter saving that doesn't show up in any salary table: the founder's attention. The scarcest resource in an early company isn't cash, it's the founder's hours and focus. Every function the system carries is a context-switch the founder doesn't have to make. That's harder to put a number on, but in our experience it's the part that actually decides whether a lean company makes it to launch.
Why owning the infrastructure matters
Here's a question worth sitting with: if a system runs your business, who runs the system? When you rent your operating layer by the seat from a third party, the honest answer is "not you." They can change the price, the rules, the access, or the product underneath you, and your company's day-to-day rides on decisions made in a boardroom you'll never see. For a tool, that's a nuisance. For the thing your company runs on, it's an existential dependency.
So we built Provyd's system on infrastructure the company owns, and we build clients' systems the same way. The company's memory, its workflows, and its outputs belong to the business, not to a vendor's roadmap. That ownership is unglamorous right up until the day a platform changes its terms or sunsets a feature, and then it's the only thing that matters. We learned that by choosing not to be a tenant in our own operation.
Ownership also changes what you're willing to build. When the foundation is yours, it's worth investing in depth, because the depth compounds for you instead of for whoever you're renting from. That's the same logic we bring to an enterprise build: the more central the system is to the business, the less sense it makes to rent it. You wouldn't lease the ground your factory sits on by the square foot.
What this taught us about building for clients
Running our own company on Hermes turned a few opinions into rules we now build by:
- Memory beats cleverness. A system that reads the company's context before it acts is worth more than a smarter model with amnesia. Most "AI didn't work for us" stories are really memory problems.
- Tools and a schedule are the product. The value isn't the chat — it's that the work happens on its own, on time, with the real tools connected.
- Guardrails are what make it safe to trust. A human gate on spend, publishing, and shipping is what lets you hand real work to a system without lying awake about it.
- Own the infrastructure. When the system runs your business, you shouldn't be renting it by the seat from someone who can change the rules. We build on infrastructure you own — the same way we run ours.
If you've read our take on what an AI operator actually is, this is the same idea scaled to a whole company instead of a front desk. It's also why we offer a considered take on the tools rather than a default answer: the right foundation depends on what you're running. If a term in here is new, our plain-English glossary defines the pieces without the jargon.
The biggest lesson, though, is one we didn't expect. Building for ourselves taught us how much of the value lives in the boring parts. Founders come to us wanting something impressive; what changes their week is something reliable. A system that quietly does the same unglamorous work every morning, on time, with its sources attached, beats a flashy demo every single time. We only know that with confidence because we lived it before we sold it.
It also reset our sense of who this is for. We assumed the obvious fit was product companies racing to launch, and it is. But the same shape, a small team stretched across too many functions, describes a lot of mission-driven and nonprofit teams too. The principles don't care whether you're selling a product or running a cause. They care whether the work is recurring, rule-bound, and currently eating someone's whole week.
How we'd build the same thing for you
The version of this that works isn't dropped in overnight, and we'd be wary of anyone who promised it would be. We built Provyd's system in stages, and we build clients' the same way, because a system that runs your business has to earn that trust one function at a time. Skipping the early steps is how you end up with an expensive thing nobody quite believes, which is the opposite of the point.
It starts with a teardown: a plain look at how your business actually runs today, where the recurring work lives, and which functions are quietly eating the most hours. That's where the dollar figure comes from, and it's deliberately the cheapest, lowest-commitment step. From there we pick one function to prove the shape, not ten. Usually it's the one that's both painful and rule-bound, because that's where an owned system shows its value fastest without touching anything risky. We'd rather earn a small, real win you can see than demo a big one you can't check.
Once that first function is carrying real weight, we build out the core: the persistent memory, the connected tools, the source-backed outputs, and the human approval gate that make the rest safe. Then we expand, function by function, until the system covers the recurring load you agreed was worth carrying. We keep building until it hits the target we set together up front, not until a project plan says we're done. The result belongs to you, on infrastructure you own, which is the whole reason to do it this way rather than rent it by the seat. If you want to see the destination before the first step, the Provyd case study shows where this path leads, and the free teardown is where it begins for your business.
Why we keep some of it to ourselves
We'll happily walk you through the principles — and build them into your business in plain sight. What we won't publish is the specific internal architecture that makes Hermes run, for the same reason we'd never publish a client's: it's the part that's actually ours, and yours. When we build a system for you, you own it. The thing we're protecting isn't a secret feature; it's the hard-won detail of how the pieces fit, which is exactly what you're paying us to get right the first time.
That's the whole pitch, really. We didn't read about this in a thread. We built it, we run our own company on it, and we'll build you one that does the same — then keep building until it hits the target we agree on up front.
The honest limits
We'd rather tell you where this ends than oversell where it goes. The system does not replace judgment, and it doesn't pretend to. It won't make the call on whether to enter a market, take on a risk, or trust a partner. It won't do the licensed work a lawyer or accountant does, and it won't pack a box or ship it. In a research-use category, it specifically does not make health or wellness claims, and we've built it not to.
What it does is narrower and, honestly, more useful: it carries the recurring, rule-bound, time-consuming first-pass work so the people involved can spend their hours on the parts that need a human. Anyone promising more than that is selling something we wouldn't run our own company on. We'd rather under-claim and over-deliver, because we're the first client the system has to satisfy every single morning.
If you want to see the principles applied to a real operation rather than described in the abstract, the Provyd case study walks through the role-by-role picture, and the free teardown does the same exercise for your business.