Here is a small StoreProof demonstration from Stargap, using a fictional purchase labelled DEMO DATA: Echo One Headphones, Demo Store, $89. The purchase date is October 15, 2026, and the example return deadline is October 29. These dates are sample data, not a retailer policy.

The receipt was attached to the purchase record. The extracted merchant and amount needed correction before the record was saved. That review matters: a neat form is not proof that OCR read everything correctly.

The final check was to leave the record, search for Echo One, open the matching purchase, then open the readable receipt. The screenshots show the record, receipt preview and search result.

You can apply the same test to a folder-and-calendar system. If you can find the right document and deadline without knowing the receipt's filename, the system is doing its job. StoreProof keeps them attached to one purchase: https://storeproof.one/iod

In a local test with Mosquitto and AirMQTT in an iPhone simulator, the message history was 21, 22, 21. Here is the small test behind it. Use a separate topic on a broker you control, with your usual authentication and TLS settings. BROKER means that broker's reachable hostname.

Connect a subscriber first. Publish 21 with retain:

mosquitto_pub -h BROKER -t stargap/demo/retained -m 21 -r

Now publish 22 without retain:

mosquitto_pub -h BROKER -t stargap/demo/retained -m 22

The connected subscriber receives 22. Start a fresh subscription, with default retained-message delivery, and it receives 21. The non-retained update did not replace the retained value. Keep persistent-session replay and other publishers out of this small test.

AirMQTT automatically subscribed to # in this test. The topic tab on its screen filtered the history; it was not a separate subscription setting. An independent Mosquitto subscriber also returned 1 stargap/demo/retained 21, where 1 was the retain flag.

When finished, clear only this demo topic:

mosquitto_pub -h BROKER -t stargap/demo/retained -n -r

We're Stargap, the publisher of AirMQTT. It was the visual subscriber here; another MQTT client can reproduce the same protocol behavior. Apple and Android versions: https://airmqtt.one/iod

Command reference: https://mosquitto.org/man/mosquitto_pub-1.html

For a small app portfolio, a weekly review needs to join two things: what changed, and what happens next. A spreadsheet is enough to start. Use one row per project and these five fields:

Project. Keep each product separate. A growing app can hide a quiet one in the portfolio total.

Revenue period. Record which period and source the figure comes from. A monthly recurring figure and last week's receipts answer different questions. Don't label them as the same number.

Open task. Pick a concrete task, not "improve marketing". "Replace the first store screenshot" or "check why onboarding exits rose" gives you something you can actually do.

Upcoming date. Put the domain renewal or another relevant deadline beside the project. It is easy to miss when it lives in a separate list.

Next action. Decide what changes before the next review. If there is no action, write "leave it alone this week" rather than reopening the same question tomorrow.

The important part is the connection. If the next task has nothing to do with the figures or the deadline you just reviewed, the dashboard hasn't helped you prioritise yet.

A useful closing question is: "What did this review change?" If the answer is nothing, either the projects need no intervention or the review was just another way to check the numbers. Both are worth recognising.

qdBox is a Stargap app for keeping revenue, tasks, links and domain reminders with each project. It brings in RevenueCat and Stripe figures so the project review doesn't require rebuilding the same overview each time. It runs on iPhone, iPad and Mac, with OS 26 or later.

Screens and downloads: https://qdbox.one/iod

The app is optional. The part worth keeping is a review that leaves you with a decision, not a collection of tabs.