The Unsexy Truth About Running a Portfolio of AI Micro-Products
Everyone romanticizes the multi-product portfolio. "Build many, find the winner!" We heard it too. At Inithouse, a studio shipping a growing portfolio of AI products in parallel, we took that advice literally. Here is what nobody warns you about.
80% Maintenance, 20% Building
The pitch sounds great: launch fast, test product-market fit, kill what doesn't work, double down on what does. The reality? Most of our week goes to analytics setup, domain management, broken deploys, and tracking fixes. Not building.
We measured this across our portfolio over a typical month. Out of roughly 160 working hours, about 130 went to infrastructure: GA4 properties that stopped firing, Supabase edge functions returning 500s, SEO audits for products that slipped in rankings, content updates across multiple languages. The remaining 30 hours were actual product work.
At Magical Song, our custom AI song generator, we spent more time fixing the payment flow than improving the music quality. At Be Recommended, the AI visibility report tool, the analytics stack needed three rewrites before we got consistent data.
Each Product Is Its Own Business
This is the part that catches people off guard. Every product in the portfolio needs its own SEO strategy, its own content calendar, its own ad experiments, its own user feedback loop. Shared infrastructure helps (once you have a Supabase + Lovable + GA4 stack, the next one deploys faster), but the marketing and positioning work is always unique.
Here We Ask, our free conversation card game, targets couples and friend groups at game night. Audit Vibe Coding targets developers shipping AI-generated code to production. The audiences do not overlap. The content does not overlap. The channels do not overlap.
We observed that the "shared learnings compound" argument is real but slower than expected. Pattern recognition across products is valuable. Knowing that short onboarding flows convert better came from watching the same mistake across five different products. But that insight took months to crystallize, and meanwhile each product needed daily attention.
The "Kill Fast" Myth
Lean methodology says kill what doesn't work. In practice, this is the hardest part of running a portfolio.
Every product has early users who love it. Pet Imagination, our AI pet portrait generator, has a small but enthusiastic group of people who send us their generated portraits. Verdict Buddy, the AI conflict resolver, gets repeat visitors who come back with new dilemmas. Walking away from something people use, even if the numbers are pre-PMF, feels wrong.
We found a middle ground: instead of killing products, we reduced active investment and let them run on autopilot while measuring whether organic traction builds. Some products surprised us after months of quiet.
What Actually Helps
Two things made the portfolio manageable.
First, automation. We run an AI agent that handles scheduled tasks: monitoring analytics, flagging broken deploys, checking SEO changes, moving issues through our Linear board. The agent does not build products, but it handles the 80% maintenance load that would otherwise eat our week.
Second, honest prioritization. Not every product gets the same attention. We look at engagement signals, not vanity metrics, and shift energy toward the products showing real traction. Right now Watching Agents, our AI prediction platform, and Voice Tables, the voice-first workspace, are getting more focus because the early data looks promising.
Would We Do It Again?
If someone asked us "should we build a big portfolio of products?" we would say: start with three, max. We went wide because we were exploring what works in AI-native consumer tools. The learning was enormous. But the operational cost of running many products in parallel is something most people underestimate.
We are now converging. The portfolio taught us which niches respond, which acquisition channels work for small products, and which product shapes have staying power. That knowledge is worth more than any single product.
Inithouse is a studio running parallel product experiments. The unsexy truth is that running them well looks less like launching and more like plumbing. But the plumbing is where the learning happens.
The portfolio: inithouse.com
The line that jumped out at me was the AI agent handling the maintenance load — monitoring, broken deploys, moving issues through a workflow (or at least to the point of inception). That's the bit I'd push people toward hardest, because it's where I ended up too, just taken further. I run a fleet of role-shaped bots for my own company, and the one that quietly earns its keep isn't a flashy build-something bot — it's the unglamorous ops one that holds the maintenance thread so I stop dropping things. Same shape as your agent, more surface area.
The thing I'd add to your "80% maintenance" point: a chunk of that 80% can be automated, but only once you stop thinking of the bot as "a tool" and start scoping it as "a role with a tight boundary." The ones that failed for me failed because I scoped them too broadly. The maintenance agent works precisely because its job is narrow and well-defined — exactly the kind of task an agent does reliably.
Curious where your agent's boundary sits...is it purely flagging and routing (surfacing the 500 to a human), or have you let it actually action any of the fixes? That hand-off line is the bit I keep refining, and I've not found a clean answer for where to draw it.
The "unsexy" part resonates. I'm running a portfolio of digital products (wallpapers, templates, scripts, prompts) and the gap between "this should sell" and actual sales is humbling. The maintenance overhead is real too — even digital downloads need updates, customer support, and constant content. Are you finding any particular product type in your portfolio converts better than others, or is it all equally slow?
I only run one tiny iOS app, and even at N=1 the maintenance floor blindsided me. I tracked it for a month: roughly 18 of every 25 hours went to the exact plumbing you named — a receipt-validation endpoint throwing 500s, ASO slipping, a TestFlight build breaking on an OS bump. So your 80/20 isn't really a portfolio problem, it's a per-product fixed cost — which is exactly why "start with three" rings true. The one thing that compounded for me wasn't features across products, it was the monitoring setup: whatever I shipped next inherited it for free.
The 130 hours out of 160 going to maintenance reframed this for me. "More plumbing than launching" is painfully accurate.
The part I keep relearning: kill‑fast gets hardest exactly when a product has a handful of users who actually care. It's the emotional cost that stalls the call, not the numbers.
Did you ever find a signal that made parking or killing one feel less personal?
Strong point on each product becoming its own business. The trap I keep seeing is teams reuse the stack but not the trigger event. For tiny AI products, I would track one painful moment per product, one acquisition loop, and one “kill or park” metric. Otherwise the portfolio turns into 10 half-measured SEO/content machines instead of 3 learnable bets.
That 'plumbing' vs 'building' ratio is a huge reality check. Everyone talks about the launch, but nobody talks about the 130 hours of infra/maintenance.
Great breakdown of the unsexy side of a product studio.
The 80/20 split you measured is honest and most people building portfolios won't admit it. The infrastructure tax compounds as you add products. I've watched this play out with a single product: when Genie 007 added a Chrome extension alongside the desktop app, my week suddenly looked a lot like yours. Two versions, two update cycles, two sets of support tickets about different environments. The insight I keep coming back to: shared infrastructure only actually saves time if you design for it upfront. Most people bolt it on after launch 3 or 4 when the cost is already visible. What does your infra actually look like across the portfolio?
Honestly, the 'social media influencer' path is exhausting and brittle. A better playbook for solo devs is building a clean blog for SEO, and then hanging out in niche forums to genuinely answer people's technical questions. When you actually solve someone's roadblock, they'll naturally click your profile to see what you're building.
the maintenance tax has a quieter cousin nobody lists. every parked product still holds live supabase keys and a payment flow that can reach user data. autopilot is where that rots, because nobody's watching the thing that still has working keys. the product you stopped caring about is usually the one with an over-scoped key that bites you six months later. kind of funny one of yours is Audit Vibe Coding, so you already know the shape of this one.
This is a very honest breakdown. The “each product is its own business” part feels especially true — people talk about shipping more, but not enough about the maintenance, positioning, and feedback loops behind every small product.
I also like the idea of reducing investment instead of killing products too quickly. Sometimes small organic traction needs time to show up.
That 130/160 split is the real tax nobody talks about. When I ran a region of 12 car dealerships, I learned fast that the business runs on whatever you measure, so we built dashboards that made the ops visible and gave the team ownership of it. The building time didn't come back until the maintenance had a system of its own.
the unsexy part is real. a portfolio only works if each product has a small repeatable workflow behind it. otherwise every launch becomes a new custom job instead of an asset.
The 80% maintenance point is real, but I think the bigger hidden cost is decision debt.
When every product has some users, some traffic, and some reason to keep existing, the hard part becomes deciding what deserves attention this week.
The portfolio probably only works if each product has a very clear continue/park/kill signal, otherwise the maintenance layer quietly protects products that should not still be active.
That feels like the real operating system behind this model.