Sam

Before you rewrite anything, check what happened to the 180. Sending tools report opens loudly and bounces quietly. Pull your hard bounce rate - if it is above about 2% your list is not verified and some mailbox providers are already discounting you. Also check whether anything landed in Promotions or in a quarantine, which will not show as a bounce and will not show as an open either.

And nine days for 180 sends from a three-week-old domain is aggressive. I ramp new domains at 10-15 a day for the first fortnight, and never send from the domain the product lives on.

Tested roughly this. Version A had a grey logo band with three fake-looking placeholder marks, version B had a labelled screenshot of real output. Over about 1,100 visits split evenly, trial starts were 1.6% on A and 2.3% on B.

I would not bet the company on that gap, but it was enough for me to stop trying to manufacture proof and start showing the product.

We auto-attach the environment to every ticket raised from inside the app: browser and version, operating system, screen size, app version, account ID, and the last route they were on. None of it is asked for, all of it is in the ticket before I read it.

Round trips on vague tickets dropped hard, because the two days of back and forth were nearly always establishing facts the app already knew. The remaining vague tickets are the ones emailed from outside the app, and there are far fewer of those.

Before any redesign, find out where inside the connect flow they stop. "Did not connect" is not one event, it is at least four: never clicked connect, clicked and did not reach the provider, reached the provider and abandoned the consent screen, consented and hit an error on the way back.

Instrument those four. The shape of the answer decides everything. Mass abandonment at the consent screen is a scopes and trust problem. Failures on the callback is a bug you cannot see because it only happens to accounts unlike yours. Never clicking at all is a motivation problem and no amount of design fixes it.

I assumed mine was design for three months. It was a callback error affecting one provider's business accounts.

And commit the working container config as its own commit before touching a single dependency. Future you needs a point to bisect from.

I keep the note as a comment marked TODO NEXT at the exact line I stopped on. Opening the file puts me back where I was without having to read anything else.

You save on the things the high street prices as special and lose on the things it prices as disposable. A plain t-shirt or a basic cotton shirt you will always lose on, because the factory buys the fabric for a fraction of what you pay per metre. A lined wool coat, a well fitted pair of trousers in a good fabric, anything in a size or a body shape the shops handle badly, those you win on and sometimes by a lot. My winter coat cost me about 95 in materials and its nearest equivalent in a shop was several times that.

That rule also explains why the beautiful dashboards die. Nobody bookmarks anything anymore.

I moved a customer onto per-core and did not model it against their actual hardware first. They had recently consolidated onto two large modern hosts, so their invoice roughly tripled at renewal for a product they were using exactly as before. They churned, politely, and told me why. Whatever metric you choose, run it against every existing customer's real numbers and look at who gets a shock before you announce anything.

The bouquet is the one to deal with today. True lilies are the genuinely dangerous ones for cats - pollen, petals, leaves, even the water in the vase have all been implicated, and the concern is kidney injury rather than an upset stomach. Get it out of the flat rather than moving it to a higher shelf, and if you think the cat has already chewed or licked any part of it, ring your own vet or a pet poison line straight away rather than waiting to see whether symptoms appear. The rest of your list is a different category of problem entirely.

i think i have been assuming a fight for two years without ever sending an email. three of my four are small businesses who mostly want the thing to keep working.

my history is the opposite of that, client two is a fork of client one, and client three is a fork of client two. so the story the repos tell is not the one i want.

Mild disagreement with buying a tool at 30 tickets a week. Two people and a clear boundary works fine and costs nothing: they own everything that arrives between midnight and 8am your time, you own the rest, and whoever touches a ticket first stars it. We ran that arrangement for over a year with no collisions worth mentioning.

What forced the move to a real tool was not volume, it was the third person and wanting reporting. If your helper is ten hours a week, a rule and a shared label will do until it does not.

Disagreeing slightly with keep DNS at the registrar. I keep DNS wherever I make the most changes, which is the CDN in front of the site, because that is where I am already logged in during an incident and where the proxying features live. The registrar is a place I visit once a year. The important part of the rule is that it is a deliberate choice and it is written down in the client's handover doc, not which company wins.

The condition report is the key move. Ours turned a quoted full rewire into a consumer unit plus one circuit, which freed up most of a year's budget.

Nineteen months for me, from zero to a junior data role, at roughly your hours. The shape mattered more than the total: months one to twelve were fundamentals and small projects and felt like nothing was happening, and then months thirteen to nineteen were almost entirely applying, interviewing and fixing what interviews exposed. I sent 154 applications and got 9 first-stage conversations, which sounds grim until you notice one of them was enough.

Your instinct is wrong and you already suspect it. Updating is how a broken build becomes an unrecognisable broken build.

Order that works: get it building exactly as it was. Lockfile untouched, same runtime version. If there is no file pinning the runtime, infer it from the lockfile format and whatever your CI config says it used, then install that specific version locally. Only once it builds green do you touch a single dependency, and then one at a time.

Second thing, before any code: write a page of notes about what is actually true. Where it deploys, which service holds the database, what the deploy script does line by line, where the secrets come from, what happens on a new signup. You are the only person who can write that document and last night proved you are also losing it.

Third: do not deploy anything until you have reproduced a deploy of the unchanged code. Finding out the pipeline is broken while you also have a change in flight is how a bad evening becomes a bad week.

That is a fair correction and I agree the front loading is real. The thing I would add is that the front loaded cost lands on whoever joins the team third, and that person is not in the room when you pick.

Both of you are right and the resolution is that knife work is a session on its own, done badly, with a cheap onion, before anything goes near heat.

Roughly how the bands played out for me across four cameras. The cheapest tier is a small sensor with fixed focus and heavy processing - fine in daylight, mushy in the evening. The middle tier is where autofocus and low light get usable and where I would stop for meetings. The top tier mostly buys you field of view options, better glass and firmware that does not oversharpen, which shows up in recordings and is invisible on a compressed call.

This reframes the whole thing. The client does not want to buy hosting, they want the site to be up.

I gated CSV export on the cheapest plan and it went badly. Three refund requests in a fortnight, one public review that mentioned it specifically and still comes up, and I reversed it a month later. The revenue from the handful who upgraded rather than left was smaller than the churn. Whatever you gate, do not gate the door out.

Stop cutting features and start picking one person.

Write down one real photographer you know, with a name. Not a persona, a person. Now list only the things that person needs to send their next invoice on Friday. Everything else goes on a separate list called later, which you are allowed to look at in three months.

Multi currency is not needed if your one person invoices in one currency. Recurring invoices are not needed if your one person sends four a month by hand. A client portal is definitely not needed for one person who emails a PDF.

The reason your cutting exercise fails is that you are testing each feature against an imaginary market where somebody needs everything. Against a specific person on a specific Friday, most of the list evaporates in about ten minutes.

The trigger number is the useful part. Without one, do it manually becomes forever, and people burn out doing 90 minutes a week for two years while telling themselves they are validating.

For what it is worth, the embarrassment does not fully go away, it just changes shape. I have shipped a lot of small things and I still get a version of that feeling on the day. The difference now is that I recognise it as the feeling of having actually done something rather than as evidence that I made a mistake.