Gus Rialto

Two data points. First launch, held four days, released with no conditions. Second product, bigger spike, held nine days and then a rolling reserve for about two months where a share of each payment was held back and released on a schedule.

The reserve was the part I had not planned for, and it is worth knowing it exists. It is not a punishment, it is cover against refunds and disputes on a book of customers with no history.

The practical lesson is boring: never commit launch revenue before it is in your bank. I now treat the first payout date as an unknown between one and four weeks and keep enough to cover a month of everything. Paying a contractor out of money that has not settled is how a good week turns into an awkward email.

Log every notification body you receive into a table before you process it, raw. When a customer says "I paid", being able to look at the store's own record of what happened beats any amount of reasoning about your own state machine, and it makes replaying a bad deploy trivial.

Ship it broken to two people or delete it. Eight months of maybe is more expensive than either outcome.

The honest test is whether you can describe what the 20% does from memory. If you can't, you don't understand it well enough to port it and you'll just rebuild the bugs.

That is fair on price discovery, but the failure mode you are describing is fixable in an afternoon by editing a web page, and the one I am describing is invisible - you never learn about the buyers who bounced because they could not tell whether you were a $50 or a $50,000 product. I would rather make the fixable mistake.

Don't touch pricing yet. Your problem is that 200 documents a month isn't a free tier, it's the entire product. Nobody in your market hits 200 unless they're already a power user, and power users are 19% of your base: which is exactly your flat line.

That flattening is your real signal and it's good news. You have a genuine product for a specific person. You just gave it to them for free.

With two months: work out what the 19% have in common (job, team size, what they did in week one), then set the free limit somewhere a casual user hits in week two and that cohort hits on day two. Leave $19 alone.

The shelf thing is funny and universal. Everyone knows the word for democracy and nobody knows the word for shelf, because books talk about ideas and life talks about furniture. Learn a room's worth of nouns from your own flat and a chunk of this fades.

Or pass the db in as an argument. Modules that take their dependencies never need any of this machinery, and the test reads as three lines instead of a hoisting lecture.

Flush Redis and requeue from your own database. Fastest way out of a stuck queue and you know exactly what state you are in afterwards.

They may have done you a favour. Go and sign that account to a twelve month term, put the other forty on current pricing, come back in a year at $5k with a contract in hand and ask for the same multiple. That is a better twelve months than most people get from a $150k exit anyway.

Neither as stated, but closer to B.

First, ignore the open rate. 22k at 38% is a number designed to be quoted. Ask for median clicks on the last five sponsor slots, and ask for a screenshot. If it comes back at 300-500 clicks and your landing page converts at 3%, that is roughly a dozen signups for $450, or $37 a signup. Whether that is good depends entirely on what a customer is worth to you, and you can do that division yourself.

Second, the directories: about 20 of your 25 are dead and exist to sell you a featured slot. But four or five of them genuinely rank, and a listing there is a permanent backlink plus a trickle for years. Do those five yourself on Saturday morning for free and skip the rest. That is two hours, not a weekend.

So: five directories for $0, keep the $500, and only buy the newsletter slot if the click numbers survive contact with an actual screenshot.

Practical thing that saved me: pre-write the first comment, the maker intro, and three or four likely answers, before the day. At 09:01 you will be too wired to write anything coherent, and the first comment sets the tone for everything after it.

Also check that nothing in your app merely looks like a login. A settings row called Sync, an email field for feedback, anything with a padlock icon, a "restore" button that opens a sheet. Reviewers work a checklist against what they can see, not against what you know is behind it.

I had a rejection once for an "account" screen that was a contact form.

Worth swapping the mouse to the left hand for an hour a day while things settle. Clumsy for a week, and it gives the right side a real break. If it is still burning after a few weeks of setup changes, get a physio to look at it rather than buying more equipment.

Do not spend a week on transaction-per-test. It does not work for e2e and lots of people lose time to it before working out why.

Your test's transaction lives in the test process on one connection. The app's queries run in the server process on a different connection. The server cannot see your uncommitted rows, so either your setup is invisible or you commit and you are back where you started. It is a great pattern for integration tests inside a single process, and only there.

Six weeks matches my experience for the fatigue easing off. What surprised me was that some general strength work did more for my sitting than any sitting technique did — though that is only what worked for me, and if there is pain rather than fatigue involved it is worth a physio session to find out what is actually going on.