What it costs to build and run 8 products in a month
The scorecard
| Metric | Current state |
|---|---|
| Live products | 8 |
| Time since the sprint began | About 3 weeks |
| Visible monthly-equivalent software spend | $1,999.94 |
| Allocated cost per product | $249.99/month |
| Cost excluding Claude development credits and GitHub Actions | $604.63/month |
| Run cost per live product | $75.58/month |
| Goal by year-end | 15–20 products |
| Base-case recurring cost of one more small product | About $20/month |
Where the $2,000 goes
The portfolio costs far more to build than to run
Claude and GitHub Actions behave differently from Supabase and Vercel.
70% of expenses help me create products. The other 30% helps me operate them.
If I allocate every expense evenly, each product currently costs approximately $250 per month. If I exclude the tools primarily being used to build the portfolio, the eight products cost approximately $76 each per month to operate.
| Question | Better metric |
|---|---|
| What am I spending in total? | $2,000/month |
| What does the whole experiment cost per product? | $250/product |
| What does the current portfolio cost to keep online? | $605/month |
| What is the approximate run cost per product? | $76/product |
| What will one additional product likely add? | About $20/month |
My five cost buckets
Claude is expensive because I am using it to manufacture team capacity.
PostHog is valuable because one shared system can measure every product.
Supabase is mostly a product-level expense.
Anthropic API and Resend should eventually rise when users are receiving value.
Those costs should not all be evaluated the same way.
$1,220 in ~30 days is a lot of money for me right now a software tool, especially as I'm bootstrapping without any other income right now.
It is also very little money for development capacity.
The correct comparison is not: Claude versus another $20 subscription.
It is closer to: Claude versus the development output I would otherwise need employees, contractors, or much more time to produce.
That does not mean every AI dollar is productive.
It means AI needs its own ROI framework. My goal is not to minimize AI spending. It is to maximize useful output per AI dollar.
GitHub Actions became a real cost surprisingly quickly
The top three repositories generated about 75% of gross Actions usage.
That doesn’t automatically mean the spend is wasteful. Those are some of the products receiving the most active development.
But the data tells me exactly where optimization work may pay off:
- stop workflows from running when irrelevant files change
- cache dependencies and build artifacts
- remove duplicate jobs
- use cheaper runners when appropriate
- separate essential checks from expensive checks
- avoid running full end-to-end suites for every tiny change
A bill that looks like infrastructure may actually be a development-process bill.
What does product #9 cost?
Average cost per product is useful.
Marginal cost is more useful.
Average cost includes everything I already paid to create the factory.
Marginal cost asks: What actually changes when I launch one more product?
Here is my current base-case estimate for another small, low-traffic SaaS product:
There would also be approximately $51 of upfront domain, protection, and first-year Workspace cost under my current domain setup.
The development cost is harder to allocate.
Claude and GitHub are shared across the entire portfolio. The next product could require two days or two weeks.
What happens if I grow from 8 products to 20?
Under the base case:
- product count increases from 8 to 20: 150%
- monthly software spending increases from about $2,000 to $2,240: 12%
- annualized spending increases from about $24,000 to $26,880
The early portfolio thesis is straightforward: Product count and software spending do not need to grow at the same rate.
That thesis may eventually break.
Traffic may push PostHog into a more expensive tier.
A product may require specialized data.
AI inference could increase rapidly.
Support may become the actual bottleneck.
But the current cost structure suggests the infrastructure itself is not the scary part.
The operating leverage curve
This is operating leverage.
It is not an argument to launch junk. It is an argument that shared infrastructure, shared knowledge, and reusable systems create real economic value.
The first product had to absorb nearly everything:
- learning Claude Code
- creating documentation conventions
- building authentication
- designing analytics
- setting up payments
- creating deployment workflows
- establishing a design language
- building reusable components
- learning how to test AI-generated code
- building the HQ Admin
The ninth product inherits most of that work.
What scales and what doesn’t
| Resource | Scaling behavior | Why |
|---|---|---|
| HQ Admin | Strong shared leverage | One operating surface supports every product |
| Claude Skills | Strong shared leverage | Better processes transfer across repositories |
| Documentation conventions | Strong shared leverage | Less context loss and repeated work |
| Design system | Strong shared leverage | Products start with reusable components |
| Authentication patterns | Strong shared leverage | Implementation becomes repeatable |
| PostHog | Shared until a pricing threshold | Products add events, not separate subscriptions |
| Resend | Shared until volume grows | Low-traffic products use little incremental capacity |
| GitHub Actions | Partially shared | Cost follows development activity |
| Vercel | Partially shared | Cost increases with deployment and traffic |
| Supabase | Mostly product-level | New projects add compute |
| Domains | Does not scale | Each product needs a domain |
| Workspace | Does not fully scale | Each brand may need its own inbox |
| Product AI inference | Usage-driven | Cost rises when users receive value |
This framework matters more than whether my current spend is exactly $1,950, $2,000, or $2,100.
For every new expense, I want to know:
- does this increase founder throughput?
- does this support the whole portfolio?
- does this belong to one specific business?
- does this increase only when customers receive value?
Those answers determine how the cost should be evaluated.
The new bottleneck is attention
A $20 monthly footprint does not make launching another product especially risky. The risk is launching another product that demands attention without earning it.
Infrastructure is cheap. Focus is not.
That is why I am now building a Portfolio Economics and Operating Intelligence system inside my HQ Admin.
Not bookkeeping. Not QuickBooks.
More like: PostHog for running a portfolio of small software businesses.
Every morning, I want one screen that answers:
| Question | Why it matters |
|---|---|
| Is the portfolio healthier than yesterday? | Direction matters more than a static snapshot |
| What changed? | I should not inspect eight separate dashboards |
| Where is the money going? | Every expense should have an economic purpose |
| Is operating leverage improving? | Shared cost per product should fall |
| What would another product cost? | Capital allocation should be explicit |
| What deserves my attention today? | Founder attention is the scarce resource |
The system will:
- pull billing emails from Gmail
- normalize vendors
- categorize expenses
- assign expenses to the portfolio or a specific business
- build forecasts
- detect unusual changes
- calculate direct and shared product economics
- generate a weekly founder brief
- recommend no more than three actions
I do not want to manage invoices. I want the invoices to teach me how the portfolio works.
Lessons
1. Don’t confuse AI spending with infrastructure spending. Claude is expensive for me because I am using it to create capacity. That expense should be evaluated against output—not against a typical SaaS subscription.
2. Measure marginal cost before average cost. Average cost makes a shared portfolio look more expensive than the next experiment actually is. The decision to launch product #9 should be based on what product #9 changes.
3. Keep products small until users pull them bigger. Most of my database instances cost a few dollars. That is a feature. Do not provision for the company you hope to become.
4. Shared systems are the actual compounding asset. The websites are visible. The leverage happens underneath:
- shared code
- reusable Skills
- persistent context
- better tests
- common documentation
- centralized analytics
- shared infrastructure
- one operating system
5. Cost per product should fall while standards rise. More products cannot mean weaker sourcing, sloppier testing, worse security, or abandoned users. The goal is to make every new product better and cheaper. Not merely cheaper.
The experiment from here
I still do not know whether this portfolio will work. Eight launches are not eight successful businesses.
The next phase is much harder:
- earn traffic
- convert visitors to accounts
- convert accounts to paying customers
- learn which products deserve more investment
- reduce development spending without damaging output
- build systems that let one founder operate the portfolio responsibly
But I now understand the expense side much better. The portfolio is not expensive because it contains eight products. Costs are mostly from investing in the ability to build.
I can keep shared costs relatively flat, add products for roughly $20 per month each, and eventually grow revenue faster than the infrastructure supporting it, the model becomes interesting.