10.How to prioritize growth work across your apps

In this chapter: how to compare possible pieces of work — across one app or several — by goal, effort, confidence and what you give up by choosing them, without inventing ROI figures. You will plan two hours of real work and leave a buffer.

The problem

Most indie developers do not have a shortage of ideas. They have a list: fix the sync bug, try new screenshots, reply to reviews, write a post for a forum, localize into German, add an annual plan, look into the drop on Android. With more than one app, the list is three times longer and every app feels neglected.

The usual ways of choosing are all flawed. The newest idea wins because it is exciting. The loudest problem wins because a review was rude. The spreadsheet wins because someone typed "ROI: 4.2x" into a cell with nothing behind it. And the bigger app always wins, even when the smaller one has the one cheap, decisive fix of the week.

What is going on

Compare on things you can actually state

For each candidate piece of work, write five things. None of them requires a forecast you cannot back up.

1. Goal fit. Which goal does this serve — downloads, paying users or positioning — and is that the goal you chose for this app this month? Work that serves no current goal goes to a "later" list.
2. Evidence strength. How many independent kinds of evidence point to this being worth doing (chapter 1)? Use a small scale: none (an idea), one kind, two or more independent kinds. Two dashboards reporting the same event count once.
3. Effort. A range in minutes or hours, including the boring parts: preparing assets, waiting for review, writing the measurement card. Label it an estimate.
4. Reversibility. How easy is it to undo? Promotional text on the App Store can be changed any time [S01]; a price change or an app rename cannot be cleanly undone.
5. Cost of waiting. What happens if this waits a week? A live regression hurts users every day (chapter 6). A listing test idea usually loses nothing by waiting.

Then add a sixth, the one people forget:

6. Opportunity cost. What will not happen if you do this? Two hours on a paywall redesign are two hours not spent confirming whether a bug is costing you trials.

Ordering rules that do not need ROI

Use these in order:

1. Stop active harm first. A confirmed regression, a policy problem, a broken purchase flow.
2. Then the cheapest decisive check. If 30 minutes of looking would settle which of two bigger jobs is right, do the 30 minutes first.
3. Then a well-prepared test of the best-supported idea for the current goal.
4. Then maintenance that protects the other work (review replies, a small fix that keeps a test clean).
5. Leave a buffer. Plan about 100 of the 120 minutes and keep about 20 as a buffer. Something will take longer. If nothing does, the buffer goes to the "later" list's cheapest item.

"Watch" is a valid entry. An app with nothing pressing gets a re-check date, not invented work.

Why no ROI column

A return-on-investment number needs a credible estimate of effect size, and for most indie apps there is none: small counts, few past tests, changing seasons (chapter 8). A made-up ROI makes the list look rigorous while hiding the real reasoning. When you do have a genuine estimate — from a finished test on the same app, for example — write it down with its source and range. Otherwise write "effect unknown" and let evidence strength, reversibility and cost of waiting do the work.

Worked example

Fictional example · E10 · Tidewell, Lanternly and Pocketloom · tags: portfolio, ios, android

Situation. A solo developer runs three small apps: Tidewell (tide times, iOS and Android, paid subscription), Lanternly (reading tracker, iOS, one-time purchase) and Pocketloom (knitting row counter, Android, free with ads). It is Saturday morning, and there are two hours.

Candidate list:

Ordering.

1. #1 comes first: active harm, two kinds of evidence, cheap to confirm, high cost of waiting.
2. #4 next: short, protects Tidewell's page while the fix is in progress, and the replies can mention that a fix is coming — without marketing language [S07].
3. #2 only if time remains: preparing the test brief (chapter 4) is useful even if the test starts next week.
4. #3 and #5 go to "later": no evidence and no current goal; #5 is also hard to reverse.
5. Plan: #1 45 minutes, #4 20 minutes, #2 35 minutes — 100 in total, with a 20-minute buffer.

What happened. The investigation (#1) took 50 minutes, not 45: purchases failed on one OS version because of a changed StoreKit call. A fix was prepared for a phased release on Monday. Reviews (#4) took 20 minutes. The Lanternly test brief (#2) took 40 minutes instead of 35. The buffer absorbed both overruns and left 10 minutes for the journal.

Decision: Two hours went to Tidewell's purchase failures and reviews, plus a started test brief for Lanternly. Pocketloom got a re-check date and no work — a deliberate "watch", recorded as such. No ROI figures were used; the choice rested on active harm, evidence strength and cost of waiting.

Do this now

1. List every candidate you are considering, across all your apps, in one table.
2. Fill goal fit, evidence, effort, reversibility and cost of waiting. Leave ROI out unless you have a sourced estimate.
3. Apply the ordering rules: harm, decisive check, prepared test, maintenance.
4. Plan about 100 minutes of your 120 and keep about 20 as a buffer.
5. Give every app without planned work a re-check date, not guilt.
6. After the session, write one line per item in the decision journal (chapter 11): planned, actual time, result.

Don't change anything yet when…

• An item's only support is that it is new or exciting — park it on the "later" list with a note of what evidence would promote it.
• Two items depend on the same unknown — do the check that resolves it first.
• A hard-to-reverse change is competing with an unresolved regression.
• You are filling the buffer with new work before the planned work is done.

Worksheet

Two-hours portfolio sheet — candidate table, ordering rules, time plan with buffer, and "watch" entries with re-check dates.

Optional: Next Move works on one app per run and respects the time budget you set (two hours by default): it proposes a move sized to it, or a check. Comparing opportunities across a whole portfolio is something Indevaro is being built to do in the full product; for now this sheet does it by hand.

Sources

• S01 — Creating your product page (Apple Developer) — https://developer.apple.com/app-store/product-page/
• S07 — Ratings, reviews, and responses (Apple Developer) — https://developer.apple.com/app-store/ratings-and-reviews/