jmduke

Most successful API products in the sense that you're describing share two common characteristics:

1. They are a thin wrapper around some dynamic dataset.

2. The cost to an organization maintaining that dataset is prohibitively large and/or difficult relative to the value they receive from it.

If I were in your shoes, I'd find a niche that I was relatively well-positioned to address (say, Shopify stores, or programmatic SEO — something small enough to have a uniform opinion but large enough such that there are multiple cohorts of individuals willing to pay) and spend time in their forums looking for people complaining about datasets or information they wish they had. The API part is an implementation detail.

- It rewards experience though, except for niche-specific writing, does not require understanding of specific frameworks or programming languages - It is often 'important-but-not-urgent' work, so intermittent availability is less of a deal-breaker - Clear writing is very much an orthogonal skill from programming aptitude writ large, and you don't need to compete with new grads

I would go so far as to say that the hypermodern template, nomenclature aside, is strictly better than the recommendations that the OP put forward both here and in the previous essay on dependency management. Poetry and ruff, for instance, are both very good tools — and I can understand _not_ recommending them for one reason or another but to not even mention them strikes me as worrisome.

I tweeted and wrote a fair deal about the process, and had good-but-not-great launches on HN and Product Hunt. There was definitely no 'big bang' where one day I did not have product-market fit and/or traction and then the next day I did; it was a slow drip of new users and new customers who helped refine the product & its position.

This is a strong _advantage_ of having something be a side project; your runway is drastically longer than other business models. (For example, from 2017—2018 MRR slowly grew from around $500 to around $1500. This slow growth felt painful, but also it was incredibly sustainable since I wasn't drawing a salary from it; churn was extremely low, and the only real problem was a small top-of-funnel since I wasn't going viral or spending money on ads.

My strategy was fairly simple: I wanted to create a better version of a tool (in this case, Tinyletter) that:

1. I already used whose quality I thought was extremely poor,

2. I did not think the creators were incentivized to make improvements;

3. I could think of a sub-niche that I was well-equipped to build because it reflected my own experience (support for Markdown, a REST API — basically developer-adjacent functionality.) [^1]

I think we are in general pretty awash in bad products; it is not particularly difficult to pay attention to what you use over the course of a week and see what could use some obvious improvements.

[^1]: People often think of 'niching down' as adding features, but I would argue it is often just as much about removing features. As companies grow, they must add more and more surface area to satisfy certain use cases. Side projects do not have this problem; they can be laser focused on one or two such use cases, and as such remove all the surface area that many users find to be detritus.

It is certainly trickier than I expected at the onset of starting the project (which is true of pretty much everything related to the email space), but not overly onerous. Most of my risk lies less in content and more in recipient, and I pour most of my efforts into subscriber validation during onboarding & activation.

I've got a side project that's current bringing in around ~2-3K MRR (https://buttondown.email).

I spent a long time daydreaming about having it hit four-digits in recurring revenue — it felt like such an accomplishment that if I were able to crack it, it'd be a dream come true. It's certainly not enough to live off of (especially living in Seattle), but it's a non-trivial amount of money and gives me a great source of pride.

The idea of doubling that amount, though, seems — well, if not _exhausting_, certainly unappealing. I can't think of a way in which my life would be improved by additional revenue, but I can think of a lot of ways it would be hampered by having twice the customer base:

1. More customer support and time spent writing emails

2. More time working on features that aren't what I care about

3. Less freedom to experiment with other projects or ideas

One of the joys of having a project that is truly _yours_ is that you alone get to dictate your terms of success.

https://en.wikipedia.org/wiki/Commonplace_book

In practice, this ends up being a huge markdown file (so I can store readable code) with entries prefixed by tags to make for easier searching.

(I think that the MBA cohort is still making more overall, but I suspect the value prop is less impressive.)

https://gizmodo.com/the-best-bluetooth-speaker-now-works-wit...

For a more emblematic example of the script quirks these games employ, The Final Fantasy Tactics remake (War of the Lions) goes much more Shakespearean, for good and ill (you lose some of the most classic lines in the original, like Don't blame us. Blame yourself or God., but the entire thing is more cohesive and vivid)

Here's a good side-by-side: https://dekaja.dreamwidth.org/1675.html

Eventually, I set a deadline for myself; I said if, six months later, I couldn’t scratch the itch to make something better (or at least find something better) than what I was using, then I’d start working on it.

The six months passed, and so it was born:

https://buttondown.email

https://itunes.apple.com/us/app/kayak-flights-hotels-cars/id...

(As far as I can tell, the answer to "why is LinkedIn.app so large?" is not "because LinkedIn's iOS team sucks", but "because LinkedIn's iOS team works under a number of constraints, including app size, and app size is not a particularly powerful constraint to optimize for.")

At a slightly more existential level, I miss how lightweight React components are: they're literally just functions, which makes breaking them out really frictionless. If I've got a FooWidget and I want to break out the header of the widget out into a new component, it's incredibly trivial to do — as opposed to Vue, which forces you to create a new file for it, register that component in the namespace, etc.

(I wrote about this a little more in depth here: http://jmduke.com/posts/what-vue-needs-next/)

My newsletter app's frontend is entirely in Vue 2. It's been very pleasant to work in, coming from both a React and Angular background, though there are definitely some things of React I miss.

(I feel like the only important question is "if I were to go back in time and restart the project, would I still use Vue?" — to which the answer is an emphatic yes.)

Here's the entirety of the roundtable between Baldwin, Poitier, and others (shown briefly in the film), which I found fascinating and, in many ways, as relevant as ever:

https://www.youtube.com/watch?v=2H7Cr0HtiJI