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.

Now that we’ve chatted about some of the biggest challenges facing your business’s home page, we turn to pricing. In this paid lesson, we’ll talk about the specific elements of a pricing page, and how to get to a solid baseline with each of them.

We’re embarking on a small, private research project here at Draft – focused on independent software, of course. Here are the steps behind what we’re doing and what we hope to get from it.

1. Map the market

The short-term goal is to map our addressable market. Who will we offer to serve? In what specific ways are they in need of value-based design?

We’re figuring this out by going to a handful of watering holes & indices, and pulling down every independent business that makes more than $600k and less than $15M (more than that and they’d probably just hire us for a workshop).

Hi! We’re gathering some more topics to chat about over the next few months – and that’s where you come in.

Got any questions about practicing value-based design for independent software businesses? Hit reply and let us know. If we answer yours, we’ll give you a free membership for a month.

Thanks again for your support, and we look forward to hearing from you!

Continuing from last week’s lesson about some of the blind spots that people experience in independent software, we’re now going to move through the most load-bearing parts of your business.

In this paid lesson, we’ll talk about the four biggest parts of your home page, and what you should do instead.

One more note about staying in your lane, building off of last week’s letter.

Recent technological developments have largely occurred because of the growth imperative. We had a big success, then another big success, then a little success, and along the way a bunch of other successes that have rewritten the way that society works now. Then we ran out of ideas for a bit, and so what fills the void? Moreover, what happens when the answer to that question is forced onto customers who don’t actually want it, and are asking for something else?

There will, of course, be a quieter rebellion against that form of technology, and it will come faster than you think. People try to do stuff they like. People seek ease & convenience. And they’re smarter than you think.

In this monthlong course, we’re going to teach you about everything we’ve learned when designing for independent software businesses.

This isn’t a “design for developers” course. There are plenty of those, and learning aesthetics only gets you so far. Instead, we’re going to talk about the real-world issues that independent software businesses face at various stages of growth.

You’ll come out understanding some of the biggest things that people mess up, and you’ll learn both why and what to do about it.

Our first lesson is going to focus on some of the more unintuitive principles or blind spots that we tend to encounter.