I tend to ignore the entire genre of what we now refer to as BNPL businesses — Affirm, Afterpay (RIP), Klarna, et al — not for any particular sin I feel that they are committing, but because they in my mind are much less interesting companies with less volatile upside than the Stripes and Squares and Adyens of the world.

It's tempting to think of these companies as a successor cohort to Wachovia and other since-departed financial firms — organizations that survive and persist in a commodity landscape due to operational rigor and process power and existing momentum more than for any other ineffable asset, a sort of fintech Yes, Dear. ^[1]

It is in that deeply cynical light that I listened to a pretty delightful interview with Klarna's CEO, Sebastian Siemiatkowski. Most CEO interviews are in one of two buckets: "this person is abusing stimulants and has a lot of points to convey" or "this person's PR team has coached them into complete banality". Conversely, Sebastian here has a lot to share: I thought this was an uncommonly honest and insightful interview, and I'm not sure I'm used to a CEO of an active company admitting so many mistakes in such little time. Some notes:

• Klarna, like many technology firms that quietly grew in Europe before exploding onto the US scene due to one particularly wide-eyed VC firm, has been around for a long time, and history has its own innate advantages.
• Obviously the full story is in the process of being told (as I write this, Klarna is still not particularly close to profitability) but Sebastian delivers the story of Klarna's pivot from largely back-office infrastructure to trying to compete in full-stack payments to pivoting to fighting the BNPL wars to doubling down on consumer-facing surfaces in a way that is much more useful than other corporate bildungsromans. Nineteen years is a long time for a software company in a blood-soaked industry to stick around.
• The insight that Klarna can outcompete legacy providers because of their ability to ingest and surface SKU-level information is a great one, and an example I think I will return to often. Even if it's a little post-hoc, I think taking a look at the downsides of deeply-integrated systems and understanding how you can exploit their coordination problems is... interesting.
• I get klarna.com (and that entire genre of wrapper-browser) now! Insanely clever. ^[2]
• Life is long, and relationships change, and organizations you consider rivals may be your trusted integration partner in three years time. (And five years after that, they might be trying to put you out of business.)

---

1. Which is to say: Yes, Dear is nobody's favorite show and won no awards and there are still a lot of actors and actresses who would give a right arm to have lasted six seasons on CBS. ↩︎

2. What does a klarna.com for newsletters look like? ↩︎

Buttondown was kindly featured in H1 Gallery last week, and Ryan asked me to opine a bit on how we arrived at our current iteration, which is the anodyne yet pointed Email for you. Yes, you.

Historically, we've called Buttondown a 'newsletter tool' — the h1 before this was 'The best way to start and grow your newsletter.' This was really nice and effective, but I talked with a number of folks who felt a little turned off by that word "newsletter", as if it felt amateurish or insufficiently "haha business" (for lack of a better term) for their use case.

So I started toying around with replacing "newsletter" with "email" as the proper noun that we'd rally around (and email has its own baggage, to be clear — there's a handful of people who sign up thinking that we're, like, a Proton Mail alternative.) And the more I liked "email", the more I hated "email " — email automation, email marketing, email campaigns all felt very corporate and stodgy in a way that betrayed the unique voice I think most of our marketing copy has. Eventually I landed on "email for people like you", which I liked but lacked... a certain punch, if you know what I mean.

Finally, I was batting around ideas and landed on the current two-sentence structure, which I think accomplishes a handful of things:

1. Tells the user, frankly, nothing about our product or positioning besides "email" (and therefore invites them to learn more)

2. Immediately gives us a certain voice and friendliness that is, uh, missing from the Constant Contacts of the world.

Two other notes:

1. This current iteration — much like the current iteration of the site, brand, and vibe of Buttondown, comes just as much from the inimitable nickd as it does from me. ^[1] One of the virtues of Buttondown being around this long and having the user base that it does is that when I work with people, they already get what we're going for.
2. I've said this a couple times already, but — the best part about running a software business is the freedom to have fun with things, and part of that freedom is recklessly changing your H1 as often as you like. We do seasonal H1s ("Email software that's all trick, no treat"; "New year; new you; newsletter.") — even if they tank conversion for a few days, it's fun.

---

1. Nick, if you're reading this, I promise I'll respond to that Loom soon. ↩︎

This great essay from Sean Goedecke went viral two weeks ago, drawing fury and fervor alike for a Moral Mazes-esque analysis of how engineers at large companies should think about shipping:

Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped.

This essay reminded me of Zach Holman's on 'Double Shipping' from 2018, in which he argues the same point — shipping is not an actual concrete event so much as a social construct by which we proselytize:

One of the things we did all the time at early GitHub was a two-step ship: basically, ship a big launch, but days or weeks afterwards, ship a smaller, add-on feature. In the second launch post, you can refer back to the initial bigger post and you get twice the bang for the buck.

---

Three useful things to internalize as early as possible in your career:

1. The act of writing and deploying code is more akin to potential energy than kinetic energy.
2. The platonic ideal of software development is a world in which changes and improvements are instantly and comprehensively understood by all stakeholders; the delta between this ideal and reality is much larger and more pernicious and more valuable than software itself.
3. Nobody has even a fraction as much knowledge or context or even baseline awareness of what you're doing as you do.

It's very easy — and comfortable! — to be cynical about this kind of stuff. Certainly there are organizations notorious for prioritizing shipping in a pluperfect sense — Google, for instance, and their promo-doc-driven culture. Certainly there are organizations that wither and die because their engineering culture is insular and insufficiently collaborative. Certainly there are great engineers who build great things and are washed out of the company because they "didn't politic enough". Running big technical organizations is an unsolved problem; there are few strictly correct answers.

Here is a slightly different and more useful framing: when you are writing code, start from the why — who cares about this thing, why do they care, and what is their success criteria? That person might be you (or future engineers on your team); it might be a customer (or one who is secretly planning on churning next month anyway); it might be a VP (who green-lit the project largely as a reason to get a couple extra heads). Willful ignorance of the answer "what happens, what really happens if this thing never hits production?" (or, conversely, "what happens if this thing hits production and is never used?") is the path to being a capable "programmer" with no leverage or cultural capital.

(Put another way: Your job is to produce value, and code is Work in Progress and not the value itself.)

Had a blast live-coding some experimentations with Steve and Shovel yesterday using Val Town. (If you haven't used Val, well, watch the stream — think live, zero-deploy code snippets that can be arbitrarily extended and executed.)

Reflecting on the experience, the most exciting part of the entire hour for me was using Townie, Val's AI live-coding tool. I was — not skeptical, but agnostic — about it (I know exactly what I want to write! What's the point in having an AI potentially-lossily do it for me?) and, as has been the case many times over the past two or so years, my tepid expectations were blown out of the water.

At this point, I'm comfortable using Claude to generate snippets for me as proof of concepts of where I want to go with a larger project, and I'm happy to offload certain menial and easily-verifiable tasks to Cursor (see Using Cursor to port Django tests to pytest), but Townie was the first time I've felt like a tool was both faster and more efficacious than I could have been.

Watch the full stream

One third of the way through The MANIAC, I found myself wondering why this book was not more popular: it seemed to be a perfect storm of formalism and postmodernism (it being told in a fugue-like oral history), scientistic reckoning (suddenly in vogue thanks to Oppenheimer), grappling with AI and AGI explicitly.

By the time I finished the book, I think I arrived at an answer: it's just not that fun or interesting of a read! The ostensible pleasure of a Greek chorus of larger-than-life scientists deifying von Neumann fades once you realize how the arc and voice of every character is so thin and uniform (compared with, say, HHhH or Autobiography of Red, where the experimental structure adds to the storytelling and diegesis rather than acts as a bit of showmanship). It is clear to understand why Labatut chose to write this book, and one quickly groks the thesis that the aforementioned Oppenheimer arguably delivered more succinctly and persuasively (our current runaway train of scientific progress is driven less by the desire to understand and improve the world and more by the desire to master it for the sake of mastery).

But you are left with prose that is all text, no subtext — the final part of the triptych perhaps most emblematic of this flaw, a New Yorker-tier play-by-play of Lee Sedol's five-part match against AlphaGo. It is a fun story, especially if you are not burdened by understanding of Monte Carlo tree search. You are told, page by page, exactly how to feel about the entire thing: awe, wonder, despair, hope, dread. Labatut takes care of all of that for you; nothing is left to interpretation.

Highlights

“All processes that are stable we shall predict. All processes that are unstable, we shall control,” he said, and I, for one, believed him, because I’d never seen him be wrong about anything else before.

Technology, after all, is a human excretion, and should not be considered as something Other. It is a part of us, just like the web is part of the spider.

Two companies that I started following (with no small amount of envy) back in 2021:

• Hype (fka Pico) sold to an MMA-themed holdco earlier this year. Raised a $4.5m seed from Stripe and Bloomberg Beta and a $10m Series A; crossed the finish line at $200K ARR after eight years.
• Stir (which raised $16M from a16z at a $100M valuation) informally shuttered some time last year. As far as I can tell, they never GA'd a product.

These two examples are arbitrary: it only takes a few years for any venture capital-subsidized gold rush to be littered with thesis-driven investment memos for companies that never found product-market fit, in no small part because they were never forced to.

As I wrote in Befriending the Goon Squad:

This is an important message for independent developers to internalize: especially in crowded markets, survival, not victory, is the success condition.

(Lest this sound too censorious: I think venture capital is a useful financial instrument. I think there are many really ambitious, gnarly problems that simply require a lot of capital to solve! But it requires a certain level of luck, grit, and patience to land your tenterhooks in a competitive niche, and venture capital provides none of those things to founders who do not already have it.)

Hello! Lots of writing in October (what early parenthood takes away in terms of deep flow, it gives back in terms of twenty-minute pockets of time and thought):

• On the content front, I wrote about Monster Sanctuary (a delightful JRPG), The Anderson Tapes (a solid late-period Sean Connery heist), Trust (a rare postmodern novel that I disliked), Wolfs (meh, even with Pitt & Clooney to keep the thing afloat), and Slow Horses (Season 4) (a return to form!).
• I jotted down some notes on Meta's two assets, Zed, and Migrating to Django 5.
• Opined a bit on productivity in My approach to GTD and PKM and Projects are things with steps.
• I let my mind with You should build this:, Notebook as marketing primitive and Consider the data product.
• I argued that Talking to customers is overrated.
• I thought led on Indie Rails and People & Blogs.
• Most importantly, I checked in on two weeks of parenthood.

Kevin Twohy has a list of heuristics for new projects/clients, and my favorite is simple:

No Bozos. Simple policy. No exceptions. You know it when you see it.

Every founder has a story about the time that they ignored the red flags and bent over backwards for a particularly standoffish or problematic customer/prospect/client/hire. It's easy to get lost in the details of the anecdata (was it a bad policy to even entertain the request? was the user technically correct, just a jerk about it?) and therefore slightly more hard to form specific policies to prevent that exact genre of scenario.

But it's very easy to make a policy of "no bozos". Everyone innately knows what it means.

Here's the rough pitch on Monster Sanctuary:

• Take the general framework of a monster collecting game (Shin Megami Tensei V is a good comp).
• Plug in a very lightweight Metroidvania framework (open world, but only kinda; monsters let you access certain levels and items, but it's fairly railroaded) and the aesthetics + plotting of a Saturday morning cartoon.
• Tune the gameplay perfectly, such that the game is never a cakewalk but never a chore.

That's it. Does tuning a squad of six cute pixel art monsters (each one of them with a unique and interesting skill tree) sound like fun to you? If so, Monster Sanctuary is for you. It is intensely designed for a specific kind of pleasure: there is very little "work" to be done (hatching eggs is instantaneous; respeccing is trivial; grinding or replaying rare encounters is easy). The plot is very akin to Crystal Project — almost self-parodic in its homage to its forebears, but never in a grating or cloying way.

The game was a delight, and feels like a Saturday morning as an eleven-year-old. I have never been more tempted to finish a game and immediately start playing it again on a randomizer.

(For those truly in the weeds: I finally blazed through the last third of the game on a Water-themed team that revolved around mass-application of Chill, damaging through Congeal, and out-lasting through shields + regeneration. If that's the kind of sentence that makes part of your brain light up, download the game immediately.)

(Epistemic disclaimer: there are few Extremely Big Tech Companies to whom I feel apathy more vividly than Meta. I had a Facebook account in high school and college and got rid of it at some point post-graduation, though I'd be hard-pressed to tell you when exactly that was.)

It was fun to listen to Acquired's six-hour episode on Meta. Ben and David have reached the Dan Carlin podcast local maxima for me: you can take some level of umbrage with their analysis (see, for example, The taste of beer) but their storytelling is so earnest and thorough it's hard not to have a great time listening to them.

Meta, in particular, was a fun episode, because listening to it felt not unlike taking a trip down my own memory lane and getting a better grip on my own relationship with social media (and how it's changed over the past two decades.) Some notes I jotted down:

• One thing that I lived through that I didn't quite understand until now was just how much of the Facebook "platform" was a feint towards a business model that never quite worked out, and how immaterial it became to their overall strategy once they really solved advertising. This is particularly noteworthy in 2024, as it contextualizes Meta's ostensibly developer/network-friendly efforts in Threads (for more thoughts, read Bluesky et al) and, conversely, a bit of a bull case for Bluesky itself.
• The concept of "reading someone's wall-to-wall" feels like a lifetime ago. The social primitive of a "wall" has technically not existed for a decade, now!
• As bullish as Ben and David are on Meta writ large, I think they are correct in saying that Meta's enduring two assets are:
  • the single largest network effect in human history
  • an organizational agility to be comfortable deploying as much energy, capital, and user activity as possible to what it considers useful.
• Relatedly, the open question of "what social interaction has Facebook actually developed or pioneered in the past decade" is a trenchant one, and one to which I cannot find a cogent answer.
• One rhetorical question: was Facebook inevitable? Which is to say: is Zuckerberg a Great Man of History, or if he decided to hard pivot into, say, video game design, would some other mega-corporation own a three-billion-MAU network graph? I have always felt the latter — I'm a dialectical materialist at heart — and yet there is something singular about Meta's agility and (I mean this not unkindly!) complete lack of scruples that I suspect would not play out in a parallel universe.

In closing, I am reminded of Zero to One's cute thesis about monopoly power being net-beneficial because it gives organizations margin and overhead to invest in projects that are otherwise unjustifiable in short-term competitive landscapes. Some of Meta's open source work is nakedly strategic (OCP, Llama); much of it is less obviously so (React, Presto, fbt).

Xerox was founded in 1906; 118 years later, its chief legacy is that of PARC — the personal computer, the mouse, the GUI, Ethernet.

Meta was founded in 2004, a time that this year more than others seems so distant as to be foreign. It is hard for me to prophesy what its stature will be in 2122, but it does not strike me as impossible to believe that its technological contributions will speak larger than its sociological ones.

Lots of kind words poured in as a response to My approach to GTD and PKM, and one question was asked so frequently that I decided to write about it.

Why is “Get mom a birthday present” a project and not a task?

---

GTD is very orthodox in what a “project” is: it’s anything that:

1. you think you’ll complete in the next year
2. requires more than one step to complete.

I used to think this was an overly broad definition for things like “buy mom a present”, “install weight rack”, etc and would just have them sit as tasks.

Over the past year, though, I've come to realize that this was not quite ideal. It's hard to read "buy mom a present" as a task when I'm looking for something idly to do between meetings or during weekly review; it's discrete, sure, but not so immediately actionable that I know exactly what to do or when to sequence it. (This is in contrast with, say, "buy mom a signed copy of Piranesi", where the action is clear and the time required is obvious.)

So: more things have become "projects". This has a couple second-order effects:

1. I'm forced to actually think about what the next step is for these smaller things, which is useful — especially the past month, where with Lucy the amount of executive function and mental capacity I have to actually do something is pretty limited.
2. At any point in time I have more projects active than I am used to, which is of course Not Ideal (context switching is hard! work in progress is bad!) but also truer than pretending I only ever have two or three things bouncing around my head at any given time.

(Again: none of this stuff has inherent merit; it's only useful insofaras it lets me spend my time more effectively and calm my mind so that I can focus on what I'm doing at any given point in time. But GTD does do those things, at least for me.)

Earlier this week, I stumbled upon this brilliant marketing-slash-documentation idea from SingleStore — notebooks as a first-party page! There are a handful of nice things about this idea:

• Very easy to fan out. You're not going to really run out of sample notebooks from which you can create pages.
• Easy to share and 'productize'.
• Lends itself obviously to both onboarding and existing users ("try it now" for people who aren't signed in, "use my API key" for people who are.)
• Doesn't require narrative or cohesion in the same way the same content as a blog post does.

I wouldn't be surprised if this doesn't become much more popular across developer tools businesses in the next few years.

One pernicious thing with writing about productivity and knowledge systems: you only change systems that aren’t working, and you tend to write about things during times of change. So most writing about productivity systems stem from people whose systems have failed them.

It is with this ironic prologue that I answer a question I've received from a few folks in reference to my usesthis.com interview:

Curious if you could share a bit more about how you use Things & Obsidian? I love Things but feel like I’m kind of holding it wrong. And haven’t yet been able to get into Obsidian.

---

Things

I have used Things for six years now; as of today, this is what my setup looks like.

I think Things is pretty much the perfect amount of organizational detail for most people: it encourages just the right amount of planning and administrivia without letting you delude yourself into thinking nested projects and deep meta-gardening of your work is anything more than cosplay.

The only change in how I use Things over this time has been how I organize my "Areas". Running a company, co-running a holding firm, being an active husband and father — my days and my schedules are much less neatly organized than they used to, and at any given point in time I have the temporal freedom to work on anything. This freedom is nice, but also a little bit difficult to wrangle: how do I know if I should be working on a new marketing initiative or setting up a 529 for Lucy? Breaking stuff up into my core identities as a person helps (though this is mostly just syntactic sugar around Home / Work / Side projects / Leisure, if we're being honest.)

Beyond that, Things' guide is really good. The only other bits of flavor I'd add:

1. Tags are useful in small doses. I only really use two: Phone and Errand.
2. Only use deadlines for things that are actually exogenous (customer-facing features, government regulations, birthdays, etc.) Otherwise, you run into a kind of urgency fatigue.
3. Being a founder means having a lot of stuff in the air, whether due to delegation or being blocked. For things that I'm waiting on in a non-temporal way, I prefix those projects with ×.
4. Conversely, "unfinishable projects" (blog posts to read, writing ideas, etc.) I prefix with ♾️.

Obsidian

I don't use Obsidian any more! I really love/loved it: it is a delightful piece of software to use, but everything I put into it I needed to share with other people (both technical and non-technical) — so off to Notion it went.

("But Obsidian for Teams is a thing", you might say! This is technically but not really true; it's not something that I can feasibly put in front of a tier one CS rep and expect them to be able to both consume and edit.)

("What about the stuff that you don't need to share with anything else?", one might ask. I posit to you: this information probably does not need to be recorded, and you probably have better things to do with your time.)

I use Notion for this now, and Notion is... fine. It gets the job done; everyone knows how to use it, cross-linking is really useful, the application is slower than I would prefer. It is not a decision or product that feels like it makes a huge impact in my life.

The goal is to do good work

In general, I am much more suspicious of PKM as a field than ever before. Andy Matuschak puts it well:

Most people who write about note-taking don’t seem particularly accomplished in their own fields, whatever those may be. In fact, most such writers aren’t applying their notes to some exogenous creative problem: their primary creative work is writing about productivity. These writers offer advice on note-taking to help scientists and executives with the challenges of their work, but the advice was developed in a context disconnected from those external realities.

My information-related problems in 2024 can be summed up in three ways:

1. I am often juggling dozens of projects of varying cadence, urgency, and aperture, and it's easy for me to forget certain things.
2. I have a lot of internal/tribal knowledge that doesn't neatly fit into some existing repository (codebase, blog, Slack) but should be shared with others.
3. It's easy for me to overfocus on short-term urgent work to the detriment of longer-term, more important but less time-sensitive work.

These problems were not the same as my problems in 2020; I suspect they will not be the same as my problems in 2028.

Solutions are only good insofaras they solve your problems; before committing to Yet Another App or Yet Another Methodology, ask yourself if really what you need is eight hours of sleep, a long walk on a sunny day, or a particularly good Manhattan and a particularly engrossing book. These things cannot be bought on Gumroad for $49 (with a cohort-based video series for an additional $299), but tend to be much more efficacious.

The advice might seem dated these days, but I think the stair step approach to bootstrapping is evergreen:

It’s much easier to sell an add-on to an existing ecosystem like a WordPress plugin, a Shopify app, a Heroku add-on – they’re usually small things to build, relatively inexpensive for customers to purchase, and you have built in discovery through the plugin repository or app store.   Other examples include Magento or Drupal add-ons, a Photoshop plugin, a WordPress theme, or an ebook or course.

These are all great examples for how to obviate marketing as a huge concern for a first product, but they also share a certain sense of finality that a full-fledged SaaS rarely does. Once you've built the thing and added it to the marketing channel of choice, it is done (modulo minor going concerns like changes to the underlying ecosystem, version updates, et cetera.) It is very hard to spend too much tinkering around the margins on a fifty page book or a Shopify <> Helpscout connector, and that inability is a feature that gently nudges you onto greener pastures.

This is a circuitous path to my suggestion of a new genre of entry-level product for the prospective bootstrapper, which I will call the data product. Here are some examples:

• A beautiful and meticulous dossier for various iOS devices and their screen sizes
• A dense tabular UI to poke around various AWS instance prices
• An even denser tabular UI to poke around SSD prices

These projects have many merits: they are small in scope, require few engineering decisions that could cause an otherwise well-intentioned engineer to bikeshed, easily marketable, and lend themselves to expansion into adjacent products.

A prior iteration of this site had a page called "Project ideas" that listed a bunch of things that I'd like to build. This was a good idea and useful in its own right (I got a few people to build companies and projects based on them, and it was a useful avenue by which folks could tell me which ideas were already implemented.)

I still haven't quite worked out how this current iteration of my site should handle these sorts of long-form mutable catalog-style posts: the whole thing is really organized around a central timeline, and in lieu of search or a colophon page its harder to designate a given post as an evergreen dumping ground. So instead, I'm just going to batch a few ideas every few months.

(If you end up exploring any of these ideas, please let me know!)

Fuzzy search atop git history

There's a lot of interesting work around applying LLM-powered search to software development workflows; many of these are inordinately ambitious (You gotta be able to taste the kool-aid), to the detriment of the more mundane but solvable problems. Things like:

1. "Which commit introduced the Automation model?"
2. "Which of my myriad stashes contains the exploration work I was doing on a new splash page?"
3. "What un-merged branches touch the markdown rendering engine?"

API wrapper around RDS Performance Insights

One genre of project that I stubbornly refuse to change my priors on despite a dearth of success stories (RIP Briefmetrics!) is: "UI wrapper around obscure/arcane/annoying but valuable FAANG API." RDS Performance Insights is a great example of this, and one can even purloin the great work done by Planetscale to find an early form factor that works well.

A better search around chat.db.

iMessage is one of the biggest social networks in the world; every MacBook has its entire iMessage history stored in a SQLite database called chat.db. It is wild to me that there aren't more projects that take advantage of this, given how annoying it is to actually search and collate one's iMessage history at scale?

...I always hammer on locked doors.

What's that supposed to mean?

The Anderson Tapes was released in 1971, placing it a decade after the original Ocean's Eleven (perhaps the first film to boldly ask: what if committing a heist was really cool?) and before The Conversation, a film more widely credited as introducing the concept of surveillance to the American filmgoer.

The Conversation only came out three years after The Anderson Tapes, and yet its treatment of surveillance is somehow much more postmodern and cynical; Coppola is interested in the interiority and paranoia of his characters, and it is taken for granted that everyone involved is already aware of their wiretapped lives (in no small part, I suspect, due to Watergate happening between these two films.)

This film, conversely, treats surveillance with a heavy-handed sincerity that could be construed as gimmicky ^[1] if it weren't so prescient. This is a straightforward movie with a straightforward message: we have spent the past decade building the Panopticon, and no amount of Scottish charm or ingenuity will purchase your escape.

Connery is great, of course, and there are bit parts to enjoy outside its use as a time capsule (a young, sinewy Christopher Walken; a Burn After Reading-esque denoument) but the enduring virtue of this film fifty years after its release is its wisdom in understanding exactly how and why the world changed, and to what end.

---

1. One of the few things that did not age well was the sound effects as we smash cut from one scene to another. ↩︎

Next page