Kojo Adjei

We did the full caching project and clawed back 6%. Then someone cut the system prompt from 2,400 tokens to 600 by deleting instructions the model was ignoring anyway, and that was 40%. Do the boring one first, then cache what is left.

The rule that fixed this for me: infrastructure work only happens after the user-facing thing is deployed. If the feature is live, spend what is left however you like: go and make the build fast, enjoy yourself. The ordering is the whole trick, because the leftover time is the honest budget for it.

Trust the database. It is the only source that knows what actually happened. Use the analytics tool for shape and direction, never for a number you would put in an email to anyone.

Nothing wakes me. Nothing. The app restarts itself on failure, there is a status page that updates automatically, and there is a digest at 08:00 with everything that happened. Two years of that and I have lost exactly one customer to overnight downtime, which is fewer than I lost to being visibly exhausted in customer calls.

Demo first, connect second, verification started today. The consent screen is not your worst problem, asking for document access from a stranger is.

Asked. Legal came back in five working days with a signed carve-out naming the app and the domain. I had spent a year constructing an entire imaginary confrontation.

It is normal to be confused, for what it is worth. The tools present both flows with equal prominence and only one of them has a real story for production, which is a documentation problem rather than yours.

If the tower fan is the noisy kind, check whether it is the noise keeping you up rather than the heat. I swapped mine for a slower, larger-bladed fan on a lower setting and slept better at the same room temperature, purely because it stopped whining at 3am.

Same rule here. If it needs a decision it goes on the Saturday list. Everything else is fair game at 21:00 and I stopped feeling bad about closing the laptop at 22:00.

Plus a smoke test that curls three real URLs after the deploy and shouts if any of them is not 200. Twenty lines. Catches the "forgot to set the env var in prod" deploy, which in my experience is over half of them.

The test I use: is the request a specific instance of something general I would want anyway.

An import from one obscure system is not a feature. An import framework with a pluggable adapter, of which theirs is the first, absolutely is - and once it exists the second and third adapters cost you a day each instead of three weeks. Every serious integration you ever add rides on it.

So take the 2,000, and build the general thing plus their adapter. They get exactly what they asked for. You get infrastructure someone else paid for. If the request cannot be reframed that way - if it is a bespoke report layout that only makes sense inside their company - then it is consulting work, and you price it as consulting work rather than as product development.

Flat is not fatal. But fix it while you still have income, because after you quit every experiment is being run by someone watching a bank balance, and that person makes worse decisions.

MRR is the wrong number to decide on. Three others matter more.

Trend and churn. $2.1k growing 12% a month with 3% logo churn is an entirely different business from $2.1k that has been flat for five months. The first one quits, the second one does not.

What 9 months of runway actually is. It is closer to 5, because the last four you will spend job hunting with a distracted brain and a gap on your CV, and you cannot do that and build at the same time.

What the bottleneck is. Is it hours or demand? If the last three months of nights produced no growth, more hours will not produce growth either: you have a demand problem, and going full time converts it into a demand problem with a countdown.

Sequential invoice numbers starting today. Never reuse one, never leave a gap. That single habit prevents most of the future mess.

Do the maths for your actual size rather than for the size you hope to be.

Merchant of record: roughly 5% plus a fixed fee per transaction on the base plans across the well known ones, one of them discounts the percentage if you pay a monthly platform fee. On 1,400 a year of EU revenue that is somewhere around 90 to 100 including the fixed fees, but note it applies to all your revenue, not just the EU part, unless you split providers.

Doing it yourself: card processing you are already paying, a tax calculation add-on charged as a percentage on top, plus registration and quarterly filings. The filings are where the money goes - the fee itself is small but somebody has to prepare and submit four returns a year, and that somebody is either you on a Sunday or an accountant charging real money.

At four EU customers the merchant of record is cheaper than one hour of an accountant's time. At 500 customers the percentage becomes a serious line item and doing it properly wins. The mistake is not picking wrong now, it is not knowing where your own crossover point is.

Mobile is not a feature, it is a second product with its own release cycle, store review, crash reporting and a build that breaks when an SDK deprecates something. On six hours a week it will consume all six for months, and the first submission alone can eat weeks of your eight.