jmduke

I agree with many of this essay's points, but the flamboyant headline is a reductive way to view software (and a bit of a dangerous meme.)

Your job as an engineer is, amongst other things, to identify the (sometimes rare!) instances in which code creates leverage beyond the business value it creates. Good abstractions are valuable assets!

To be clear, the approach outlined above _is_ based on just HTTP; there's no javascript involved.

One hackneyed reason that some folks give for not wanting to expose their RSS is wanting some level of legibility into their subscribers. I recently learned that many large RSS readers actually expose high-level analytics numbers [^1] so you can get an estimate of RSS readership that way, too. Would love for more readers to support this functionality: as far as I can tell across all of the RSS feeds my product exposes, the only supporting clients of this faux protocol are NewsBlur, Feedly, Feedbin, and inoreader.

[^1]: ht to Darek Kay's blog post, https://darekkay.com/blog/rss-subscriber-count/, for alerting me to this fact!

Going from 0 → 1 migrated route was "medium difficulty", I'd say — there was a non-trivial amount of scaffolding I had to build out around auth, error codes, and so on, and django-ninja's docs are still a little lackluster when it comes to edge cases.

Once I had that one migrated route, though, the rest were very simple. (And I am very happy with the migration overall!)

I'll preface all of this with a couple esoteric design goals that I had in mind:

1. I actually _want_ an SPA. You might not need an SPA, if you don't need one then Vue/React/etc are overkill, etc.

2. I want to power as much of the SPA as I can using the same REST API as my core product, both for dogfooding reasons and for consolidation. Many people might argue that this is a bad idea.

---

With that in mind, some specific packages that I highly recommend:

1. Django-vite (https://github.com/MrBin99/django-vite). This makes it very easy to serve an SPA from the actual django response/request model

2. Some sort of way to get type information (if you're using TypeScript) into the frontend. I use a frankensteined system of the OpenAPI spec that django-ninja generates + openapi-typescript (https://github.com/drwpow/openapi-typescript). This means when I add, say, a new field to a response in Django, I immediately get typechecking for it in Vue — which has been _tremendously_ useful.

3. Django-typescript-routes (a package I extracted and open-sourced!: https://github.com/buttondown-email/django-typescript-routes) which gives your front-end routing information based on the Django router.

My app is a Django backend and a Vue frontend. There are large swathes of Django that I ignore, but to me the core of Django — its ORM, routing and middleware system, and admin interface — are worth their weight in gold. The migration from DRF to Django-Ninja (which is, roughly, FastAPI + Django) has also been a great improvement in terms of productivity and performance.

Not a lot of whizbang features in 5.0, but GeneratedField looks like a very nice addition, and reason enough to migrate.

(Delayed, but...) Yeah, a lot of the pricing guidance here varies wildly depending on if you're thinking about things from a B2C vs. a B2B context. I think the hard part about hitting something in the sub-$5/mo price point is the amount of money you're giving to Stripe et al starts ratcheting way up, which is also why you see so many iOS apps be very aggressive with annual pricing.

Totally reasonable question, and you'll get a very candid answer!

I wrote more about the pricing strategy here (https://buttondown.email/blog/pricing-page-driven-developmen...) but — when Buttondown first launched I _had_ a souped-up free tier (up to 1K subscribers!) and it certainly helped with early adoption, but hurt almost every other part of the business — in particular unit economics and customer service. Curtailing the free tier felt like ripping off a bandaid, but it also solved two of my biggest problems at once:

1. Conversion rates nearly doubled. People who found Buttondown valuable suddenly had an avenue and reason to pay for it!

2. _Margins_ went up. It costs money to send emails; a user who sends, say, one newsletter a week to five hundred subscribers costs around two or three bucks a year just in email alone. Supporting _thousands_ of these users (who are very nice people!) hurt my bottom line.

3. Customer service got way easier. This might not apply to all cases, but the _majority_ of my time answering emails and helping folks was spent on people who weren't spending a dime. While I genuinely want to help all people regardless of how much they are (or are not) paying, it was not sustainable for me to run a bootstrapped business where I spent 4+ hours every day helping people who did not find my service valuable enough to pay $9/month.

Having that free tier I think was a useful wedge to get initial customers and users onto the platform (and I am grateful for those initial users, who I've kept on their free tier!) but I think something significant would need to change for me to consider going back to that set-up.

I run Buttondown, so it pains me to suggest a competitor (I kid, I kid) — but to my understanding, EmailOctopus has the best free tier around at the moment, at 2500 subscribers / 10K emails.

> I know this is a side point, but I imagine people might be interested in the challenges of being able to work a second job while not annoying your employer. How did you manage it?

I ran my company (https://buttondown.email/) as a side project for ~three or so years before taking it full time and it was _similarly_ in a position where I could get paged for downtime or plumbing-related issues. My suggestions:

1. Honestly, choose a project where downtime or operational issues are less prevalent. This is a cop-out answer, but when you're evaluating potential projects it should be top of mind.

2. Be very up-front and honest with yourself and your employer about your commitments and your priorities. My personal rule was to only ever look at Buttondown-related stuff outside of what I considered my "core" working hours unless I was getting paged, and even then responding to pages would wait until my meetings or time-sensitive work was finished.

3. Set a schedule and rely on the schedule. For me this ended up being "side project hours are from 7-9pm M-F and 3-8pm Sat"; at times I wanted to do more and at times I wanted to do less, but the former path leads to burnout and the latter path leads to languishing.

Good.

I'm someone who a) uses Google Suite (or Workplace, or whatever it's called) b) runs a newsletter service [buttondown.email] that sends millions of emails every day, most of them to Gmail.

The amount of cold email I get from prospecting/outreach tools that is nigh-impossible to unsubscribe from is _infuriating_. Any legitimate bulk sender is already conforming to DKIM + one-click unsubscription, and anything we can do to cut down on obvious spam is a win in my book.

There's a lot of things Gmail does as de facto tsar of email that I don't love — initiatives like AMP for email come to mind — but this is an unalloyed positive in my mind.

If you're interested in similar approaches to the space, I've been slowly migrating some of my blog content + structured data onto Keystatic (https://keystatic.com/). Very similar philosophy; used structured flat data, backed by Git, but with an admin interface.

I'm not saying you're wrong (I've never tried to raise a round!) but I meant that in the context in which I've encountered it, which is in sales to enterprise/larger users who absolutely do expect that if I am hit by a bus there is someone else who can ensure continuity of service.

I'm glad I could help! Always happy to answer more questions, either here or via email (i'm justin@buttondown.email).

(Context — I run Buttondown (http://buttondown.email/) as a solo founder, with a handful of contractors on support/documentation but no other W2s.)

1. You need to either a) have an answer for "what happens if you get hit by a bus?" or b) create a product for customers to whom that doesn't matter. In general, people really _like_ being able to chat with the founder directly (lean into that! it's a superpower!) but feel very anxious about committing $X0,000/yr to you.

2. It will be somewhere between "vanishingly rare" to "non-existent" to feel like you are moving as fast as you should be. Instead of setting milestones and thinking about metrics, _especially_ in the early goings I'd focus on just spending as much time as you can on critical-path work (chatting with customers, chatting with prospects, improving core flows.)

3. This does not matter. I moved from Seattle to Richmond, VA last year and literally nothing changed about my business.

4. This is a very broad topic that is hard to answer concisely, but the closest answer I can give is "figure out how your first five users found your product and then figure out how to find more people like them".

5. Venture capital is a tool by which you exchange agency for large sums of money. There are a lot of great businesses that require more time, energy, and money than can be provided by a single engineer working for an indefinite amount of time; there are a lot of great businesses that can be built without those things. I would not take a lot of stock in any prescriptive answer that says you HAVE to take VC or you HAVE to bootstrap; it depends on the type of company you want to build and what you consider a successful way to spend a decade or so of your life.

Applaud the effort, and I think this kind of project is a really good substitute for an info-product or ebook: relatively low effort to get started, lots of room to scale + grow if it goes well, and in general a good way of "getting in the reps" of building a business.

However — I think you need to spend a lot more time putting yourself in the shoes of who would use such a product. As an example, going to the "Modal" section shows me four very small thumbnails, of which I can only really discern the high-level structure and not any of the actual details. Having to copy and paste this into my own editor or something like CodePen just to see how it really "works" is a very rough feedback loop compared to all the other existing tailwind component sites (take, for example, how Flowbite handles it: https://flowbite.com/docs/components/modal/).

Also, for projects like this I like to have some level of social proof and your social media links in the footer are broken! That, coupled with the "trusted by 1000+ businesses", gives off some ... bad vibes, to put it mildly.

I use very little of the outbound/link-building things, but find the alerting on broken content and notifications of which specific pillar pages are hitting traction very actionable and useful.

A friend of mine who was at one point a GH employee gave me a (lifetime? it was around four years ago) F&F discount that IIRC amounts to $200/mo free across all SKUs.

Love this! I published a similar one last month:

https://buttondown.email/stack

---

A couple notes on where I differ/concur from OP:

1. ahrefs is absolutely worth its price in gold.

2. IMHO intercom is overpriced relative to competitors depending on how you use it, with the caveat that I hate in-app messaging widgets and consider them a blight on the modern web. (HelpScout is my preferred app.)

3. I deeply miss my Free AWS Credits Era.

Done! T/y.

You might find https://howisfelix.today/? interesting, as both inspiration/prior-art/cautionary tale.

I run an app with a bunch of separate processes managed in a Procfile invoked by Overmind (https://github.com/DarthSim/overmind):

```

app-web: cd app && poetry run invoke server

app-vite: cd app && pnpm dev

app-storybook: cd app && pnpm story:dev

api: cd api && poetry run invoke server

docs: cd docs && npm run dev

marketing: cd marketing && source .env && npm run dev

```

Maybe it's my getting older, but I've found it _infuriating_ to remember which process is bound to 3003 vs 3002 vs 3001 and so on. Very grateful for this project so I can save myself a couple seconds of frustration every day — t/y OP for building it!

I think this verbiage is a little bit more provocative than is necessary, but it's still _true_. I've met with, worked with, and chatted with a lot of founders (both in the 'indie hackers' / lifestyle businesses sense and in the YC / venture-backed sense) and the gulf between people who are running something because they have a keen understanding and kinship with the problem that they are solving and people who "always wanted to start a business and do the whole founder thing" [^1] is... dramatic. The latter cohort is _much_ more inclined to invest in branding, meta-structure, and 'big-picture thinking' as opposed to finding design partners [^2], doing duct-tape work, and so on.

[^1]: Their words, not mine! [^2]: Not in any rigorous/bureaucratic sense, just in the sense of "finding people who are willing to work closely with you to provide feedback on how you're solving their problem"

As context: I live with a partner and run a SaaS with a handful of contractors. I think this is important context, because most productivity tools and systems fall down when you have to introduce state outside of your control, and half your time is spent syncing your to-do list with your company's JIRA board or whatever.

I run my life pretty much entirely inside of Things (https://culturedcode.com/things/). It has just enough functionality that I can track and record things easily without getting bogged down in the meta-work; I've used it for five years without complaint or wandering eye.

Other notes:

- I follow GTD's philosophy pretty closely (next action, weekly review, that kind of thing.) The book is a little fluffy and some of the concepts are dated at this point, but worth perusing.

- Any state that has to be shared with someone other than me either goes to Apple Notes (friends and family) or Github (https://github.com/buttondown-email/roadmap/issues)

- No productivity system is going to solve all of your problems. It can make you execute better, but you are not One Perfect App away from the ideal version of yourself; when evaluating tools or systems, be sure to focus on very specific, concrete problems ("I am bad at following up with people after meetings", "I don't pace myself throughout the week", "It's hard for me to close out large projects") as opposed to nebulous ones ("I wish I had more time in the day", "I don't know which side project to work on")

A while back I built out a quick guide comparing all of these alternatives, because the core value prop was pretty similar and it was annoying to compare between pricing plans. (My personal vote goes to Fathom.)

https://buttondown.email/comparison-guides/google-analytics-...

Two immediate nits (and I mean these from a place of love — I am a sucker for docs tools):

- Your splash page's hero image is indistinguishable at first glance from basic Markdown. More than that, it's the kind of thing I'd expect a tool to _automatically_ generate!

- The idea of colocating documentation with the files its documenting is really interesting, and a core pain point of most internal docs ("what do I need to update when I change this file...?") I think your screenshot here can be much improved.

There's a quote from Sarah Manguso's _300 Arguments_ that I love:

> With great and solemn portent, my teacher announced she would tell us something that her teacher had told her, and that her teacher’s teacher had told him, and so on, back to Yeats: The thing to remember is that no one ever finds out that you don’t know what you’re doing.

I run Buttondown (buttondown.email) full-time now, but until this past year it was a side project for me alongside my day job as an IC (later EM).

It took...around two and a half years, I think, to hit $2k/mo MRR. It was definitely not the stereotypical "launch → iterate a bit → boom, PMF" story that you often hear, which was fine because it was 'just' a side project and I didn't have to worry about running out of money or time.

Thanks! (I run Buttondown.)

To echo others: I love the concept for this, but I do not think the current implementation is successful. I put in The Lowe Post (a fairly popular ESPN basketball podcast) and got:

1. another basketball podcast (nice!)

2. a podcast about outdoor camping

3. a podcast about Ohio State University sports

OP: what I'd _really_ love in this vein is a way to go from "here's a podcast I like and listen to, give me a list of podcasts in which the host or guests of the host also appear." I suspect that may be a difficult set of structured data to assemble, but I think it'd be very valuable.