This is the most personal post I have written all year, so let me be plain. I ship custom software for small and mid-sized companies, and 2022 handed me a stack of software delivery lessons the hard way. Some I learned from projects that went well. More I learned from the ones that fought me.

I want to write these down while they are still fresh, partly for you and partly for the version of me starting the next project in January. No war stories with names, no humblebragging about how many systems went live. Just the five things that actually changed how I work.

If you hire developers, or you are one, some of this will sting in a useful way.

Lesson 1: Small Releases Beat Big Launches, Every Time

The projects that hurt most in 2022 were the ones with a single big launch date months away. The projects that went smoothly shipped something small every couple of weeks.

There is a reason, and it is not just technical. A big launch hides risk until the worst possible moment. You build for four months, everyone assumes it is going fine, and then reality arrives all at once on launch day. A small release surfaces the same problems in week two, when they are cheap to fix and nobody has staked their reputation on the date.

One project I nearly lost was scoped as a single delivery. We renegotiated it into five smaller ones. The same code, the same budget, a completely different stress level. Now I resist any project that cannot be sliced. If it cannot ship in pieces, that is a warning, not a detail.

Lesson 2: Adoption Beats Features

I built features in 2022 that nobody used. That is the sentence I least want to write and the one I most needed to.

You can deliver a perfectly working module, tested, documented, exactly to spec, and watch it sit untouched because the people it was for never changed their habit. The feature was not the deliverable. The behavior change was, and I had not budgeted a single hour for it.

Now I ask a different question before building anything: who will use this, and what will make them actually switch from their current way? A slightly worse feature that people adopt beats a brilliant one they ignore. This is the same painful truth I unpacked in why your business needs a technology strategy, not just a website. Software that is not used is not an asset. It is a liability with a maintenance bill.

Lesson 3: The Client's Attention Is the Scarce Input

I used to think budget and time were the constraints. They matter, but the real bottleneck in 2022 was the client's attention.

A busy owner who cannot answer a question for two weeks will stall a project longer than any technical problem. Decisions pile up. The team either waits, which burns budget, or guesses, which burns trust. The projects that flew were the ones where a real decision-maker gave me thirty focused minutes a week. The ones that dragged were the ones where I was chasing a ghost.

So now I treat client attention as a resource to protect, not assume. I batch questions instead of drip-feeding them. I bring decisions pre-chewed, with a recommendation, so the answer is a yes or no, not an essay. Respect the scarce input and everything else moves faster.

Lesson 4: Documentation Is a Gift to Future You

The unglamorous lesson. On two projects this year I came back after six months and could not remember why I built something a certain way. I had to reverse-engineer my own decisions. That is a tax I paid for skipping documentation when I was busy.

Documentation is not paperwork. It is a message to whoever touches this system next, which is often you, tired, on a deadline, having forgotten everything. The half hour you spend writing down why, not just what, is repaid many times over. The clients I serve best are the ones where anyone competent could pick up the code, because the reasoning is written down, not trapped in my head.

Lesson 5: Say No to Scope Earlier

Every rough project this year shared a root cause: I said yes to scope I should have questioned. A "small addition" here, a "quick change" there. None of them small, all of them quick to promise and slow to deliver.

Saying no is a skill, and I got better at it late in the year. Not a flat no, but a "yes, and here is what it costs, and here is what it pushes." Making the trade-off visible turns scope creep from a favor into a decision the client makes with open eyes. That protects the timeline and, oddly, the relationship. Clients trust the developer who tells them the real cost more than the one who says yes to everything and misses.

The Takeaway

Boil a year down and the software delivery lessons rhyme: ship small, chase adoption not features, protect the client's attention, write things down, and price your yes honestly.

None of these are about writing better code. They are about the human system around the code, which is where most projects actually succeed or fail. I write cleaner code than I did a year ago. But I run projects far better than I did a year ago, and that is the difference clients feel.

If you are looking for someone who works this way, that is what I do at ervandra.com/partner. Going into next year, I am optimizing for the boring lessons, because the boring lessons are the ones that paid.