Continue, stop or scale: how we make portfolio decisions at 30, 60 and 90 days

Launching a company is exciting. Deciding what to do with it afterwards is harder — and far more important.

Without a clear decision process, new companies tend to drift. Nobody wants to be the person who says "this isn't working", so the company keeps running on hope. Months pass. Attention and money that could have gone to something stronger are spent on something that stopped improving long ago.

At Oryvelon every company — and every major new initiative within a company — has written KPIs for 30, 60 and 90 days after launch, and a commitment to make one of three explicit decisions at each checkpoint: continue, stop or scale. This note explains how that works.

Write the targets before launch

The most important rule is about timing: KPIs are written before launch, not after.

After launch, it is very easy to look at whatever happened and find a way to call it a success. "We didn't hit our sign-up target, but engagement is great." "Revenue is low, but we learned a lot." Sometimes those statements are true. Often they are a way of avoiding a decision.

Writing targets in advance — as step ten of our new-company protocol — removes that temptation. The targets can be wrong; that is fine. What matters is that they were stated honestly beforehand and that any change to them is a deliberate, recorded decision.

Choose KPIs that measure behaviour

Good checkpoint KPIs measure what customers do, not what we do or what they say.

The specific numbers differ by company. For MerchNivo, activation might mean a store connected and a first briefing opened; for CastLyra, verified profiles on one side and requests sent on the other; for KeşifAtlası, eligibility tests completed and reports purchased; for Noveniq, repeat purchases.

We try to keep the list short — three to five KPIs per checkpoint. A long list makes it easy to find one metric that looks good and ignore the rest.

The three checkpoints

Day 30: is anything working?

Thirty days is too early to judge a business, but it is not too early to see whether the basics work. The day-30 checkpoint asks:

• Are the right people arriving?
• Do they understand what the product does?
• Are they completing the first meaningful action?
• Is anything technically broken or unexpectedly expensive?

Most day-30 decisions are continue, often with a list of fixes. A day-30 stop is rare and usually means something fundamental was wrong — the audience is not who we thought, or the product cannot deliver its core promise.

Day 60: are people coming back?

By sixty days, the question shifts from first use to repeated use:

• Do activated users return?
• Are early paying customers staying?
• Is the cost of serving each customer in line with expectations?
• Is at least one acquisition channel showing sustainable economics?

This is often the most revealing checkpoint. A product can generate curiosity for a month on novelty alone. Return behaviour at day sixty says whether the product solves a real, recurring problem.

Day 90: is this a business?

At ninety days we ask whether the company is on track to become a business worth running:

• Is revenue growing from paying customers who stay?
• Does each customer generate more than they cost to acquire and serve, or is there a credible path to that?
• Is the team learning faster than the problems are growing?
• Compared with other opportunities in the group, does this deserve more, the same or less attention?

The day-90 decision is the one most likely to be scale or stop.

What each decision means

The three decisions are deliberately simple. Each has a clear meaning.

Continue means the evidence is good enough to keep going on the current plan, with any adjustments written down. It is not a default. A continue decision should come with a short statement of why, and what we expect to see at the next checkpoint.

Stop means the company or initiative ends in its current form. That might mean shutting it down, pausing it until conditions change, folding its useful parts into another company, or reshaping it into something different that starts the protocol again. Stopping is described more below, because it is the hardest decision to make well.

Scale means the evidence is strong enough to put more resources behind it: more budget for acquisition, more engineering time, more of the founders' attention, perhaps outside partners. A scale decision should also specify what must stay true — margins, retention, quality — as the company grows.

Evidence we weight heavily

At each checkpoint we look at a set of evidence, and some of it counts more than the rest.

Heavily weighted: - activation and retention curves; - paying customers and whether they renew or repurchase; - cost to serve each customer, including AI costs; - qualitative feedback from customers who use the product regularly; - whether a sustainable acquisition channel is emerging.

Lightly weighted: - total visitors; - social media attention; - feedback from people who do not use the product; - the team's excitement — important for morale, weak as evidence.

Ignored: - competitors' fundraising announcements; - metrics that were not defined before launch and appear only because they look good.

Why stopping is a skill

In most organisations, stopping something is treated as failure. In a company builder, it has to be treated as a skill — one we practise deliberately.

Attention is finite. Every company in the group competes for the founders' time, engineering capacity and budget. A company that should have stopped takes those resources from one that should have scaled.

Sunk cost is invisible but powerful. The more we have invested, the harder it feels to stop. Pre-agreed checkpoints make it easier to look at the evidence rather than the history.

Stopping well preserves value. When a company stops, its domain, content, code, learnings and relationships remain. Useful parts can move to other companies. The knowledge flows back into the group's standards. A well-documented stop is often the start of something better.

Stopping protects trust. A company kept alive without investment tends to decline slowly — slower support, fewer updates, frustrated customers. Stopping clearly, with proper notice and data export options for anyone affected, is more respectful than fading away.

How we stop responsibly

When the decision is to stop a live product, we follow a few rules:

1. Tell customers early and clearly, with a reasonable timeline.
2. Offer data export so customers leave with what belongs to them. See Retention, export and deletion.
3. Refund fairly where customers have paid for service they will not receive.
4. Delete what should be deleted according to the product's retention policy.
5. Keep the domain and, where appropriate, a page explaining what happened.
6. Write down the lessons, including what the checkpoints showed and when.
7. Move useful assets — content, code, research — to where they can be reused.

Checkpoints for features, not only companies

The same discipline applies inside companies. A large new feature — an AI capability, a new pricing tier, a new market — gets its own short list of KPIs and checkpoints. Features that do not earn their keep are removed or simplified. This keeps products focused and prevents the slow accumulation of complexity that nobody uses.

How checkpoints connect to capital allocation

Checkpoint decisions are the raw material of the group's capital allocation. When several companies reach checkpoints, the decisions are compared: which companies deserve more investment, which should hold steady, which should stop. We write about that process in Capital allocation inside a company builder.

Because each company's economics are tracked separately — revenue, hosting, database, AI, email and tools — the comparison is based on real numbers rather than impressions. See Unit economics per product.

A checkpoint template

Each checkpoint review follows the same short template, written by the company's owner and discussed with the group.

1. KPIs as written before launch, with the actual numbers next to them.
2. What surprised us, positively and negatively.
3. What customers told us, quoting real words where possible.
4. Cost to serve, broken down.
5. The proposed decision — continue, stop or scale — and the reasoning.
6. What we expect at the next checkpoint, if the decision is continue or scale.

A review should fit on two pages. If it takes longer to explain, the situation is probably less clear than it should be — which is itself useful information.

Common failure modes

We watch for a few patterns that undermine checkpoint decisions:

• Moving the goalposts — changing KPIs after seeing the results.
• Averaging away the signal — reporting totals that hide weak retention.
• Permanent "continue" — continuing without stating why or what should change.
• Scaling too early — putting money into acquisition before retention is proven.
• Stopping too quietly — letting a product decline without a clear decision.

Naming these patterns makes them easier to spot in ourselves.

Examples of checkpoint reasoning

Abstract rules are easier to apply with examples. The scenarios below are illustrative — simplified patterns of the kind every product team meets — rather than reports on specific results.

A strong start that fades. A consumer product gets excellent sign-ups in its first month, driven by novelty and a well-received launch. At day 60, few of those users are returning. The right decision here is usually continue with a narrow focus: stop spending on acquisition, study the small group who do return, and rebuild the core experience around what they value. Scaling would multiply the leak.

A slow start with loyal users. A business product signs up far fewer customers than planned in its first month. But nearly all of them are still active at day 60, and several have asked for features that would let them use it more. This is often a continue, then scale pattern: the product is solving a real problem for a narrow group, and the question becomes how to reach more people like them.

Healthy usage, unhealthy economics. A product is used and loved, but the cost to serve each customer — perhaps driven by AI usage — is higher than what they pay. The decision is not stop or scale; it is continue with an economics fix: model routing, caching, pricing changes or usage-based tiers. See Subscription plus usage.

A marketplace that fills one side only. Talent sign up enthusiastically; businesses do not. Scaling talent acquisition would make the imbalance worse. The decision is to continue with a single focus on the scarce side until requests start flowing. See Two-sided marketplaces: thinking about the cold-start problem.

Nothing moves. Visitors arrive but do not act, even after several changes to the message and offer. Customers who try the product do not return. At day 90, the honest decision is usually stop, preserve what was learned and redirect the attention elsewhere.

Who makes the decision

Checkpoint decisions are made by the company's owner together with the group, not by committee. The owner proposes; the group challenges the evidence and the reasoning; a decision is recorded. If there is disagreement, the default is the option that preserves more future choices — usually continuing on a smaller budget until the next checkpoint rather than scaling or stopping irreversibly.

The record matters. Six months later, when someone asks why a company was scaled or stopped, the answer should be a short document with the numbers and the reasoning, not a memory.

What scaling actually involves

"Scale" can sound like a single switch. In practice it is a set of specific commitments, and we write them down when the decision is made.

• Acquisition budget: how much more we will spend, on which channels, and what cost per customer we will accept.
• Product capacity: which improvements the extra engineering time will go to, prioritised by what retained customers value most.
• Operational readiness: support, onboarding and documentation that can handle more customers without quality dropping.
• Guardrails: the retention, margin and quality levels that must hold as volume grows. If they slip, scaling pauses.
• Next review: a date — usually sooner than the next normal checkpoint — to confirm that the extra investment is producing the expected results.

Scaling a company that has not proven retention is one of the most common and expensive mistakes in digital business. Writing guardrails into the decision is how we avoid it.

Setting targets when you have no history

The first objection to writing KPIs before launch is obvious: how can you know what "good" looks like for a product nobody has used yet? You can't, precisely. But you can do much better than guessing.

We build first targets from three sources:

• Validation evidence. The phase-zero site and early conversations tell us roughly how many interested people arrived, how many left an email or joined a waitlist, and what they said they would pay. That sets a floor for day-30 activation.
• The cost floor. Every company has a monthly cost it must eventually cover — hosting, database, AI usage, tools, a fair share of the core. Working backwards from that number tells us how many paying customers the day-90 target has to point towards, even if day 90 is too early to reach it.
• Patterns from similar products. Retention in a daily-use tool behaves differently from retention in a product people use once a season. We set expectations by product type, not by the best numbers we have read about elsewhere.

We write the target as a range with a short sentence of reasoning — "we expect between X and Y because the waitlist converted at about this rate". When a target turns out to be badly wrong, the reasoning shows which assumption failed. That is often the most useful finding of the whole checkpoint.

Worked example: a MerchNivo feature through three checkpoints

Here is how the process looks for a single feature. The scenario is illustrative, not a report of results.

Imagine MerchNivo adds an alert for unusual refund activity: when refunds in a store rise well above that store's own normal pattern, the daily briefing flags it, shows the orders involved and suggests what to check. The numbers come from the store's own data; the AI explains what changed and why it might matter. We describe the wider approach in Shopify operations signals.

The KPIs written before release might be:

At day 30, suppose merchants open most alerts but rarely act. That is a continue with fixes — probably the suggested action is vague, or the alert fires on refunds the merchant already knew about. At day 60, suppose many merchants mark alerts as noise during a sale period, when refunds naturally rise. The fix is to compare against seasonal patterns, not a flat average. By day 90, the question is whether the feature changes behaviour that matters. If stores using it retain better and the cost per alert is small, it becomes a standard part of the briefing. If not, it is simplified or removed — without drama.

Before the checkpoint: making sure the evidence is real

A checkpoint is only as good as the data behind it. A week before each review, the company's owner works through a short checklist:

• [ ] Tracking for every KPI has been tested end to end, not assumed.
• [ ] Test accounts, staff activity and internal orders are excluded from the numbers.
• [ ] Cohorts are defined by sign-up date, so new arrivals do not flatter retention.
• [ ] Costs for the period are attributed to the company, including AI usage.
• [ ] At least a handful of real customer quotes have been collected from people who use the product.
• [ ] Any change to a KPI since launch is listed with the date and reason.

We measure what the decision needs and nothing more; checkpoints do not require tracking individuals across the web. See Analytics without surveillance.

The most common problem this checklist catches is not dishonesty. It is a broken event or an internal test account quietly inflating a number. Finding that the week before is far better than discovering it after a scale decision.

Summary

Every company we launch comes with a promise to ourselves: we will look honestly at the evidence at 30, 60 and 90 days, and we will make a clear decision. Continue, stop or scale. The discipline protects our customers, our team and the group's capital — and it is what makes the companies on our Companies page the ones worth running.

Questions and answers

What are 30/60/90-day KPIs?

Targets written before launch that describe what success should look like 30, 60 and 90 days after a company or major feature goes live.

What does 'continue, stop or scale' mean at Oryvelon?

At each checkpoint the group makes one explicit decision: keep going as planned, stop or reshape, or invest more because the evidence is strong.

Does Oryvelon ever stop companies?

Yes, when the evidence says so. A portfolio that never stops anything is not being managed.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Company Building

NextDesigning a recurring revenue loop from day one →