I’ve spent the past couple of weeks working on a series of “getting started” guides for a client. We pride ourselves on the product being simple & easy to understand, even though the subject domain is far from it. So in putting these together, there is maybe an element of admission that the product is not in fact complex, or all software is terrible and must be written about, or (god help us) the customer is dumb.

None of this is true.

1. I enjoyed Anil Dash’s recent piece on LLM. This matches my own relationship: use it a little, less than you think, and view with suspicion. Frank Chimero’s recent talk is also quite good.
2. Draft will be on our annual holiday break from December 20 until January 04, and our next intermission will take place from January 05 until February 16. During intermission, we will focus exclusively on client work & members, and put the rest of our resources into working on the business for the coming year. New shipments will be paused during both of these periods, so if you want our books, order them now.
3. When the dot-com bubble popped in 2000, an unsustainable, incorrect model of funding tech went away for a bit, then grew, then took over. Now we witness another bubble. Once that pops, will we see the hyped bits of technology take over a few years later? What will we learn from the lessons of the past, if anything?
4. What if I’ve been liberally using em dashes for 20 years prior to a robot infamously doing it? What then?
5. People have been asking how we’re doing after our repositioning. The short answer is “well.” The medium answer is “we had our second best year ever.” The long answer is best experienced in person. We’re honored to perform this work and grateful for your support.
6. On a personal note, thanks to everybody who has reached out about, you know, recent events. It’s very weird in Chicago right now, which is their whole goal, right?
7. We’re opening a slot for consulting work in April 2026. Reach out if you run an independent software business and would like to begin a conversation with us.

We’ve written quite a bit about post-purchase surveys in the past, but things get a little more interesting when you’re in software. In this paid lesson, we’ll talk about what changes – and what to do about it.

As we’ve repositioned, our research practice has shifted. Think about how research typically works:

• You observe existing behavior
• You call some customers
• Do some synthesis
• Prioritize, experiment, profit

A lot of this breaks down when you’re dealing with a relatively small customer base that happens to be on subscription:

• There are more upfront objections about the sale
• Fewer people are signing up every month, making recruitment more challenging
• You have to deal with ongoing relationship management – and churn

I’m currently working on a big project where I’m updating a beloved client’s documentation site. Docs are interesting because they’re both high value (imagine your churn rate & support load by not having them) and hard to measure, making resourcing for them hard for some people to emotionally justify.

Docs are also very easy to build once & leave to seed. If you write a doc about an integration, expect it to go out of date the moment your integration partner updates their product. Ditto your own product – you’re still building, right? And this all tracks as a distraction, especially in businesses that happen to be resource-constrained.

So in this paid lesson, we’ll talk about what we’re doing with docs, why periodic reassessments are necessary, and what you can do to get your docs back up to baseline.

Over the span of a month, I recently wrote a series of universally correct essays about the implications of LLM on value-based design. The short answer is “minimal”, but describing why took a minute.

Since then, LLM has only become more controversial. Some people are very mad about it, and some people are very enthusiastic about it. Candidly, I got a lot less excited about LLM since I wrote those essays. This happened for a lot of reasons, and one of them is because I discovered that they are the primary reason for electric bills spiking in America. In fact, my own electric bills have doubled, despite my overall electrical usage declining year-over-year. That has never happened to me before. In fact, it probably shouldn’t happen at all, right?

I think for a while, a lot of us took one look at the projected climate impact of LLM and shrugged. I think that is considerably less defensible of a position these days. Building a squillion data centers and hoovering up the collected output of the human experiment is something we are allowing to happen by supporting LLM companies. It’s not a good look.

Practically speaking, I don’t feel great about using LLM unless it’s with models that I can run on my own computers – and only for relatively simple tasks. I definitely don’t feel great about LLM replacing search, or LLM being used to do all sorts of crazy sinister things like deepfakes, artistic infringement, or replacing your therapist or girlfriend.

A dead end happens when you reach the bottom of a page or sequence of interactional steps, and you aren’t given a next step to follow. In this lesson, we’ll explain the most common dead ends and what you can do to avoid them.

Busy week, so some more reads:

• Everything that Kevin Kelly knows about self-publishing.
• Ethical design.
• Basic UX texts.
• Attention.
• How to not build the Torment Nexus.
• Wikipedia.
• “Technical”.

That’s it. Take care of yourselves & each other, always.

One of the problems about working with us is that sometimes you end up signing up enough new customers to start slowly, intentionally scaling. That involves hiring people and building process. Some of that is fun! A lot of it is not fun.

So in this lesson, we’ll talk a little bit about how to scale from the very beginning, and what to look out for.

Some sundry administrivia before we get started today. On Buttondown’s blog, I wrote a little bit about how I created onboarding for them and plan on adapting it into the future. Take a look!

I visited City last week, and am posting a two-parter about my experience this week on text.

I didn’t write this piece on airports, but wish I had. Did you know that there are no good airports in North America? It’s true.

We’re on the brink of reworking a pricing page that needs… clarification. Our current pricing page works, but it doesn’t answer every question & address every objection. In this paid lesson, we’ll walk through the job of a pricing page and outline how to rework yours – so the numbers don’t change.

Apple recently released a series of software updates that are, by most critical & customer impressions, bad. They are bad not because we react negatively to redesigns all the time. They are bad because people rammed decisions through that should not have shipped. They should not have shipped because of the basic principles of cognitive science. They should not have shipped because normative context already works well enough on their platforms. They should not have shipped because context should override consistency. They should not have shipped because Apple has always had taste as its key economic differentiator.

Now we are here, in this place.

On the other hand, the world is a confusing mess right now, so it makes perfect sense that Apple would turn all of their products into one, too.

Discussions of why translucency make for low-quality interface design are well-documented, of course, so I’m going to provide a few examples of obvious failures that have not yet entered the discourse, and then I will offer some next steps.

Your funnel is pretty simple when you sell only one thing. Grow your offerings and suddenly it gets complicated. In this paid lesson, we’ll talk about what to ask when you’re reworking your site’s structure to match your product offerings, and what structure makes the most sense for you.

I’m out on a little field trip this week, so let’s keep things light with some notes on reading. Someone once asked me in a Q&A what I read – not knowing, I think, that I read a lot. I read a few dozen articles and around two books every week.

Tools, which are unimportant

For articles I’ve used Instapaper, the greatest iPhone app, since the day of its release in 2008. Now that the consumer web is unreadable, I use archive.today to fix what needs fixing, which is most of it. When I favorite something on Instapaper, it syncs over to a tool that permanently archives the plain text of the web page so I never lose it to link rot.

I’ve used plain text exclusively for all of my work since 1992. Plain text is the only correct format, because it is the only durable format.

When you’re onboarding new customers, you obviously want them to complete whatever steps you’re asking – but you also probably want them to feel like they have some amount of agency. This can happen for a variety of reasons:

• Your customer base exists at a variety of experience levels, and one of those is “just show me the stupid product”

• People might not be ready to provide the information that you want or need them to enter

• There may be many different routes into your product, with onboarding less linear or direct

• Customers behave in all sorts of unexpected ways that might surprise the team; towards this end, a strict onboarding process might be too constraining or even unnecessary

So in this paid lesson, we’ll go deep on how to make your onboarding short and skippable – and what you need to do to make sure your customers are signing up in a way that’s helpful to them and diplomatic for you.

It’s time once again to read things that are not me, even though isn’t why you’re here? Let’s try not to think too much about that.

• I wrote once about Thomas Ptacek’s article where he uses LLM for development. Here is a nice counterpoint to it. Via. Related, clean.
• Give me all of the conversion maturity models that you have, please.
• As I’m sure all of you remember, in 1998 I wrote a brief piece on my blog about how the VC-funded advertising model for free content online was structurally untenable and would eventually come to be replaced by direct payment. Here is someone saying the same thing in 2025, and – no offense to the children, who remain our future – I’m sure they wrote it better than any 16-year-old possibly could.
• Civilization hasn’t collapsed quite yet, but when it does, it will be unsurprising to those who have been paying attention. For everybody else, there is numbness, bypass, and deferral.
• I wrote some text on Hobonichi Techo, Yeti, and some of the principles behind our repositioning. It can get even more meta than this!
• Dating as a head. Relatable.
• And lastly, how to make stirfry.

Over the past few weeks, we’ve covered:

• Common blind spots for independent software

• Home page issues & how to address them

• Baseline design for pricing pages

• Operational issues when designing as an independent developer

And now it’s time to cover our final lesson in this mini-course, which discusses what to do first.

There is the noise outside, and then there is the inner voice telling everything to shut up. We wrote about this recently, telling designers to stay in their lane, focus on the practice, and generate revenue the only way we know how.

This has turned out to be correct. 95% of recent projects fail. A new model comes out; the collective reaction is akin to a deflating balloon.

I can’t blame anyone for not believing the skeptics, though. This cycle was loud. It really did feel like the future for a minute there – maybe by sheer force of will, but it was there. There were moments when even I doubted whether my practice would continue to be relevant.

It turns out that making money is relevant.

In the past few lessons, we’ve talked about blind spots, your home page, and your pricing. But there’s a lot more, of course – like your actual product.

I care less about the final design of your product and far more about the operations that go into its maintenance. Making an amazing comp does not result in good design. High-quality operations result in good design.

And so instead of a lesson about how to teach you taste or aesthetics or even how to research, we’re starting with the bedrock of any good design process. A culture that accepts design is more likely to design well. A system that puts design at the forefront is more likely to remember design when building.

Anyone can design. You design. Every decision you make is a form of design. The goal is not to learn design. It’s to make better decisions.

One of the fun things about serving software again is that I feel like I’m working in a startup. I mean this less in terms of the economic conditions of the business and more in terms of process:

• Prototype fidelity (low, fast)
• Layers of approval (none, do what you can do)
• Process (push fast, QA/test, adapt)
• Consensus & critique (this looks good & I have notes)

Which is especially interesting as a designer. It’s always been the case that the actual design I’m doing matters less than whether & how it ships, but with such a fast turnaround cycle and so few layers of approval, you really can do quite a lot more.

If you’ve been reading these letters for over 6 years or so, you know that I once wrote a lot about how designers will code, and that learning code is how you create higher-quality design. Now the roles have flipped, and I think a lot more about how developers will learn the basic principles of design. Ultimately we’re all making design decisions, and in independent software businesses, many decisions will be made outside of a designer’s influence.