TetraCore operates six SaaS products: FourSight (uptime monitoring), CallsAround (AI receptionist and emergency dispatch), LinkPilot (link management), ItemStage (chain-of-custody item workflows), Franexis (franchise operations), and VoterCXM (civic engagement). Six products, one small studio in Ohio.
Conventional wisdom says this is a mistake — pick one thing, focus. The conventional wisdom is not entirely wrong, and this post is honest about where it bites. But running a portfolio has taught us things a single product never would have, and those lessons are the point of writing this down.
Shared infrastructure is the only way this works
Six products cannot mean six of everything. The portfolio survives because the boring layers are shared: common deployment patterns, common authentication approaches, a common design system, common conventions for status pages, privacy pages, security pages, and pricing pages. When we improve how one product handles something, the improvement is a template the other five inherit.
The discipline this forces is underrated. A solo product can accumulate one-off decisions forever. A portfolio punishes every snowflake immediately, because every one-off is something a very small team now has to remember six times. We say no to clever custom architecture not out of virtue but out of arithmetic.
A concrete example of the template effect: every product in the family has a pricing page, a security page, a privacy page, and a terms page, built from the same skeleton. When we decided CallsAround needed a dedicated reliability page — because an AI receptionist that handles emergency dispatch for trades businesses has to answer "what happens when you go down?" before anyone will trust it — the pattern of writing that page honestly became the standard we now hold every product to. The first product pays the design cost; the other five inherit the answer. Over enough decisions, that compounding is the portfolio's entire margin for survival.
Every product ships llms.txt, schema, and a status page
A pattern we adopted portfolio-wide: every product publishes machine-readable descriptions of itself — structured data (schema.org markup), an llms.txt file for AI assistants, and a public status page. Partly that is modern SEO reality: people increasingly ask ChatGPT or Google "what is ItemStage?" or "who makes FourSight?", and the answer gets assembled from whatever machines can read. If you do not describe your own products precisely, something else will describe them imprecisely for you.
But it is also just operational honesty. A status page is a promise made in public. Structured data forces you to state plainly what the product is, what it costs, and who is behind it. Doing that six times over, consistently, is how a small parent company becomes a coherent entity rather than six disconnected websites.
One team, six roadmaps: how work actually gets prioritized
The question we get most often is some version of "how do you decide what to work on?" The honest answer is that we run one queue, not six. Work enters it in a strict order of precedence. First, interrupts: a security issue, an outage, or anything touching customer data jumps every queue in the portfolio, no debate. Second, friction reported by paying customers — a real person hitting a real wall outranks any roadmap item, on any product. Third, and only then, planned feature work, which flows to whichever product has momentum at the moment: an active sales conversation, a seasonal deadline (VoterCXM's calendar is set by election cycles, not by us), or a batch of related changes we can ship across several products at once.
The corollary is one of the more counterintuitive lessons of the portfolio: a product is allowed to have a quiet quarter. Single-product companies treat a slow roadmap as an emergency. We treat it as a rotation. ItemStage does not need a new feature every month to keep doing chain-of-custody work well; it needs to be up, fast, and correct. Learning to distinguish "this product is neglected" from "this product is stable" — and to say the second one out loud without guilt — took us longer than it should have.
The failure mode this system guards against is peanut-buttering: spreading effort evenly across six products so that nothing ever gets a real push. Even effort feels fair and produces mediocrity everywhere. Uneven effort, applied honestly and re-aimed often, is what makes a small team viable at this width.
Dogfooding is a strategy, not a slogan
FourSight, our uptime monitoring product, monitors the rest of the family. When a product in the portfolio has a bad night, our own pager knows before any customer does — and every gap we find in FourSight while depending on it becomes a fix that ships to every FourSight customer. There is no sharper product feedback loop than needing your own product to work.
It is not just monitoring. When we need to hand a credential to a contractor or a client, it goes through LinkPilot's one-time secrets rather than an email thread — because pasting a password into email is exactly the habit we tell clients to break, and a policy you do not follow yourself is just decoration. Every rough edge we hit as users of our own tools becomes a ticket, and those tickets are consistently better than the ones we would have invented in a planning meeting.
The same principle built ItemStage. It was developed in cooperation with Millers Restoration, a real restoration company, inside a working restoration facility — where items arrive by the truckload and chain-of-custody is not a feature request but a daily operational fact. Products built inside real operations come out shaped differently: fewer speculative features, more of the unglamorous ones that only matter when you are actually doing the work.
Flat, transparent pricing is a portfolio discipline
With six products, we cannot afford six bespoke sales processes, so every product publishes flat, transparent pricing. What started as a constraint became a conviction. "Contact us for pricing" is a tax on the buyer's time and a tell about the seller's incentives. Published pricing forces us to know what our products are worth, keeps the sales conversation about fit instead of negotiation, and — at portfolio scale — is the only model that does not consume the team entirely.
The honest trade-off: published flat pricing means we sometimes leave money on the table with buyers who would happily have paid more, and it occasionally filters out enterprise procurement processes that expect a negotiation as proof of seriousness. We accept both. The alternative — six products' worth of custom quotes, discount matrices, and renewal negotiations — is not a pricing strategy for a team our size; it is a second full-time business stapled to the first.
Context switching is the tax nobody warns you about
The genuinely hard part of a six-product week is not the volume of work; it is the cost of moving between codebases. Monday you are in franchise royalty logic for Franexis, Tuesday in call-routing behavior for CallsAround, Wednesday in an ItemStage photo-documentation workflow. Every switch has a reload cost, and a small team pays it dozens of times a month. We have never eliminated that tax; we have only learned to shrink it.
Three habits do most of the shrinking. Batching: we group work by product into contiguous blocks — half-days at minimum — instead of ping-ponging on demand, which means some requests wait a day longer than they strictly need to, a trade-off we accept on purpose. Writing everything down: any decision that lives only in someone's head is a decision the next context switch will destroy, so design notes, runbooks, and "why is it like this" comments are not documentation hygiene, they are how we re-enter a codebase we have not touched in three weeks. And ruthless convention: because the products share deployment patterns, project layout, and design system, the shape of every codebase is familiar even when the domain is not. The shared infrastructure section above is usually read as a cost story; it is equally a cognition story.
What breaks when you run many small products
Honesty section. Four things quietly break at portfolio scale, and all four broke for us before we fixed them.
Support routing. A customer with a problem does not care about your org chart. Six products means six front doors, and requests arrive at the wrong one constantly. We had to build deliberate routing — clear support entry points per product, plus a central support page at the studio level — so no ticket depends on the customer guessing our internal structure.
Brand consistency. Six products drift apart by default — voice, visual design, even how each one describes its parent company. Left alone, the portfolio starts to look like six unrelated companies, which wastes the trust each product earns. The fix is unglamorous: shared design system, shared copy standards, and every product saying "a TetraCore product" the same way, everywhere.
Maintenance surface. Six products is six dependency trees, six sets of framework upgrades, six certificate renewals, six domains, six backup schedules. None of these are hard individually; the failure mode is that any one of them can silently lapse while attention is elsewhere. Our defense is twofold: standardize until the six trees look as much alike as possible, so one upgrade recipe applies everywhere — and monitor relentlessly, because a lapse you find out about from your own monitoring is an incident, while a lapse you find out about from a customer is a reputation.
Entity SEO. The subtlest one. Search engines and AI assistants have to learn that FourSight, CallsAround, LinkPilot, ItemStage, Franexis, and VoterCXM are one family with one parent — and they will not infer it. It has to be stated explicitly and identically on every site: structured data linking child to parent, consistent naming, reciprocal links. A single-product company gets this almost for free; a portfolio has to earn it deliberately.
What we'd tell anyone attempting this
Share everything boring. Dogfood ruthlessly. Publish your pricing. Describe yourself in formats machines can read, because machines are increasingly who gets asked about you. And accept that the portfolio itself is the product: the consistency across six small products is worth more than any individual feature in one of them.
We would also say, plainly: do not start here. Every one of the disciplines in this post — the shared templates, the single queue, the batching, the monitor-everything reflex — was learned by getting it wrong with fewer products first. A portfolio does not forgive the mistakes a single product forgives; it multiplies them. If one product is not yet boring to operate, a second one will not fix that, and a sixth would be an act of self-harm. The order of operations that worked for us was: make one product operationally dull, extract everything repeatable about it into a template, and only then let the template earn the next product.
The six products are all live — browse the portfolio and try them. And everything we learn operating them flows directly into the custom software work we do for clients; more on the studio itself is on our About page.