Which of your ten products is broken right now?

You launched ten things. Together they pay the rent. Individually, none of them earns enough to deserve a Monday morning — so none of them gets one.

That is the deal, and it is a good deal. It has one hole in it.

The portfolio only works if each product costs almost nothing to keep

The one-person portfolio is a viable business now because almost every recurring per-product cost has been automated away. Deploys happen when you push. Payments, invoices and dunning are somebody else’s problem. The database is managed and the host scales itself. Support is a docs page and an inbox you check on Thursdays. Errors land in a tracker. An uptime monitor pings every URL and stays quiet.

Each of those removed a job that used to scale with the number of products you own. That is the whole trick — the tenth product is only worth launching because it costs you almost nothing to hold.

One recurring cost is left, and it is the one you skip: knowing that the thing people pay for still does the thing they pay for. You skip it because skipping it has no immediate consequence. That is exactly what makes it dangerous.

The failures that matter do not throw errors

Picture the ways a quiet, profitable, unattended product actually dies.

A payment provider deprecates the API version you pinned. The checkout page renders, the button spins, and no card is ever charged.
A sending domain gets suspended over a DMARC change. Signup completes. The verification email never arrives, so nobody can finish creating an account. Your application never sees a problem — it handed the message off successfully.
An OAuth consent screen needs re-verification. “Sign in with Google” now shows an unverified-app interstitial. Every visitor reads it as a scam and leaves.
A dependency bump changes a form library’s defaults. Submit now validates a field that is always empty, so the form never submits — and never errors, because refusing to submit is what validation is for.
A free-tier database pauses after inactivity. The first request of the day wakes it, times out, and renders an empty state that looks like a product with no data in it.
A CSS change moves the buy button below the fold on mobile, behind the cookie banner.

The list has one thing in common. In every case the server answered, no code threw, and no customer complained.

Nobody complained because the people who hit it were strangers. They did not have your email address and they did not owe you a bug report. The customers who would have told you are precisely the ones who never became customers.

Uptime is a claim about your server, not about your product

Your monitor is not lying to you. It is answering a narrower question than the one you think you asked.

A pinger asserts that a URL returned a 200. A checkout that cannot charge a card returns a 200. A signup form that sends no email returns a 200. So does a page rendering an empty state from a database that just woke up.

An error tracker asserts that your code did not throw. Nothing in the list above threw. A suspended sending domain is a successful API call. A form that refuses to submit is validation working as designed.

Both instruments are worth having and neither watches a customer succeed. That is a different question, and it needs a different instrument.

Three sentences per product, not three test suites

The scope sounds impossible and is not, because you do not need to test ten products. You need to test the money path through ten products, and it is short.

For almost any product there are three flows that carry revenue:

A stranger can become a user.
A user can pay you.
The thing they paid for does the thing.

Ten products, three flows each, is thirty checks. That sounds like a lot right up until you notice they are thirty sentences, not thirty repositories:

Sign up with a new email address, confirm the account from the
verification email, and land on the dashboard.

Upgrade to the Pro plan with a test card and see the plan change
to Pro on the billing page.

Paste a URL into the box, run it, and get a report with at least
one row in it.

Write them the way you would describe the product to a friend. If you cannot describe the flow in a sentence, that is worth knowing on its own.

Why you have not done this already, and why you were right

It is worth saying plainly that skipping this was not laziness. It was arithmetic, and the arithmetic was correct.

A Playwright suite is a real engineering artefact: selectors, fixtures, seeded test accounts, a CI pipeline to run it in, and a maintenance bill every time you move a button. Ten of those is not a testing strategy, it is a second job. Worse, the maintenance scales per product while the revenue is also per product and much smaller. For something earning two hundred a month, one afternoon of repairing broken selectors costs more than the outage it would have prevented.

So you did the sensible thing and shipped the eleventh product instead.

What changed is not your discipline. It is that the per-product cost of a check fell far enough that thirty of them stopped being a second job.

What this still will not do for you

Two honest limits, because a check that gets oversold is a check you stop trusting.

It will not tell you a product has stopped mattering. All three flows can pass every single day while the product quietly dies of no demand, no traffic and no reason to exist. That is a real failure mode for a portfolio and no monitor detects it.

It will not cover the edge cases either. You are covering the money path deliberately and leaving the rest uncovered, which is the right trade at this size and still a trade.

And if a product earns nine dollars a month, the answer may be to sunset it rather than to watch it. A portfolio is a set of decisions, not a museum.

Where this leads

The obstacle was never knowing what to check — you could write the thirty sentences this afternoon. It was that turning them into something that runs required building and maintaining a test suite per product, which is the cost the portfolio model exists to avoid.

That gap is what Testmode is built to close: you write the flow as a sentence, it runs against the real deployed product in a real browser on whatever schedule you choose, and it tells you when a customer would have failed — with no test code, no pipeline, and nothing installed in any of the ten repositories. If you want the mechanics rather than the argument, regression testing without a QA team covers how to choose the flows and what to do when one of them fails.