Growing a side project in a crowded market to $1M ARR by playing the long game

Justin Duke didn't like how established players were powering newsletters. So, he built Buttondown on the side while working a cushy full-time job. That job gave him the runway —and peace of mind — that he needed. Now, it's bringing in over $1M ARR.

Here's Justin on how he did it. 👇

Building a respectful product

I’m Justin Duke, and I run Buttondown, the best way to start and grow your newsletter.

I studied computer science, and I spent the first chunk of my career as an engineer — and then engineering manager — at Stripe and Amazon. I learned an enormous amount at both — how good software is built, how good teams are run, how much of a company’s success is downstream of boring operational excellence rather than any single brilliant idea.

Right before joining Stripe, I created Buttondown as a side project. It started in 2017 as a tool I built for myself because every other newsletter platform felt bloated, hostile, or both — I wanted something markdown-first, quiet, respectful of both the writer and the reader. It turned out I was not the only person who wanted that. Buttondown is now a fully bootstrapped, profitable business that powers newsletters for tens of thousands of writers, from hobbyists sending to a dozen friends to authors and companies sending to hundreds of thousands.

The measure of progress I’m proudest of: every day, someone churns from a billion-dollar valuation company in favor of Buttondown.

Our current run rate is over $1M ARR.

Spite and hubris

It all started with spite, and a bit of hubris.

I wanted to send a newsletter after using TinyLetter for a long time. I looked at the existing options, and each one made me feel like the product, not the customer — endless upsells, engagement-maximizing dark patterns, editors fought me every time I tried to write a plain paragraph. I remember thinking — with the specific arrogance of an engineer who had never run a business — “How hard could this possibly be?”

The answer, for the record, is very. But by the time I learned that, I was in too deep.

Building the first version

The initial version cost almost nothing except time, and the time was mine.

My financial situation at the time was comfortable. I had a good job, which is the unglamorous truth behind many “brave” indie founder stories. The money required was close to zero, which is one of the quiet miracles of software as a business. The real cost was opportunity cost — the projects I didn’t build, the evenings I didn’t spend elsewhere.

I spent the surplus of my attention here instead of somewhere else, no small thanks to my wife, who was patient and understanding enough to get why I was doing so! I built it in the margins of my full-time job — early mornings, late nights, the occasional weekend. That constraint was secretly a gift. When you only have a few hours a week, you can’t afford to build anything speculative. You build the one thing the product needs, and nothing else, which was easy in a mature industry like email.

The first version was embarrassingly small: a text box that took markdown, a subscribe form, and a button that sent an email. That was it. No analytics, no automations, no templates — let alone, for a while, a user model.

I also stood on the shoulders of a lot of unglamorous infrastructure. Email delivery is genuinely hard — deliverability, spam compliance, the whole labyrinth — so I leaned on existing sending infrastructure rather than pretending I could reinvent SMTP from scratch: first Mailgun, then a bevy of other ESPs, and more recently, we've rolled our own. The rest was Django, Heroku, and lots of coffee.

I validated it the cheapest way I knew, by using it every single day. It solved a real problem for exactly one person. Then, I put it online, charged five dollars a month, mostly as a joke, and someone I had never met paid me. That was the moment it stopped being a toy.

The stack

The stack is Django and Python on the backend, Postgres as the database, and the front end has evolved over the years but is currently Vue for the author-facing app and Next for the docs/marketing site.

Scale drove the biggest evolutions — we rewrote and hardened the parts that handle email sending and analytics several times as volume grew, because the naive version that works for a hundred subscribers falls over at a hundred thousand. The rest is remarkably close to what I wrote in the first year.

The hardest technical challenge is email deliverability, full stop. Opaque rules at major inbox providers govern this moving target, and getting it right is less a coding problem than an operational discipline — reputation, authentication, feedback loops, and a lot of patience. It’s the least glamorous part of the business, and quite possibly the most important. DNS also, which is technically a subset of deliverability.

Growth strategies

Most of Buttondown’s growth came from a good product and customers telling their friends. There was no viral launch, no single Product Hunt day that changed everything. Instead, growth resulted from a slow, compounding accretion of people who liked the tool enough to recommend it.

A few things did matter, though. Early on, I wrote — a lot — in public at jmduke.com and elsewhere about building the product, my decisions, and the unglamorous realities of running a software business. That writing didn’t convert in a measurable funnel sense, but it built trust with exactly the kind of people who would eventually become customers. Writers tend to want to use a tool built by someone who obviously cares about writing.

LLM-based acquisition has bent the curve up a bit too. Claude loves us.

But word of mouth from happy customers is the most durable channel, which sounds like a non-answer but is really a strategy: I obsess over support. When someone emails Buttondown with a problem, a real human — for a while, often me — quickly answers and solves it. In an era of AI chatbots and week-long ticket queues, being genuinely responsive is a marketing channel disguised as a cost center.

Newsletters' inherent visibility is another quiet engine. Every email Buttondown sends carries our fingerprints, and every public archive is a small advertisement to the next writer. The product markets itself every time a customer hits send.

Charge more and apologize less

If I had to start over, I’d charge more, sooner, and apologize for it less.

I spent years under-pricing Buttondown out of a kind of misplaced guilt, and the customers who genuinely valued the product would happily have paid more the whole time.

Under-pricing doesn’t make you generous. It makes you fragile, and it starves the business of the resources it needs to serve those same customers well.

Growing to a team

The biggest challenge was transitioning from me to a team. For years Buttondown was small enough to fit entirely in my head — every line of code, every customer, every decision.

Even today I struggle to understand what "the right kind of day" looks like for me, now that I've graduated past a lot of IC work.

Why indie hackers should keep their day jobs

Starting from a position of financial stability was the single most advantageous thing I did. I emphasize this because indie hacker mythology often erases it. I built Buttondown on top of a salary. That safety net let me make patient, long-term decisions instead of desperate ones, and patience turns out to be an enormous competitive advantage when everyone around you optimizes for a quick exit.

Though it sounds abstract, the mere passage of time (and comfort with it) works well for many channels! SEO, word of mouth — all these things become more valuable when you can easily wait a year.

Two pieces of advice

Two pieces of advice:

1. Build for a specific person — ideally yourself — and resist the urge to generalize before you have to. Every feature you add “for flexibility” is a feature you’ll maintain forever for a customer who may not exist. The narrowest useful product beats the broadest vague one.

2. Take support seriously — not as a chore, but as the product. The fastest way to earn a customer for life is to answer their email like a human who cares, quickly, and fix their problem. It doesn’t scale, everyone will tell you, and they’re right. That’s why doing it anyway is such an advantage.

What's next?

For a long time, my goal with Buttondown focused on avoiding failure: "I want to get my first paying customer to confirm it's a real product"; "I want to hit a thousand dollars in revenue to ensure it's not just friends humoring me"; "I want to make $10k/mo, otherwise I can't work on it full-time"; and so on.

Now, those milestones no longer apply: it's profitable enough to support my salary and others' salaries; it grows every month.

Currently, my goal is this: I want Buttondown to grow and flourish specifically to validate and proselytize a slightly different model of software company: one that uses all the amazing things about software — e.g. negligible marginal costs and the infinite breadth of the internet — to build high-value, sustainable tools for customers while being fair and rewarding to employees.

You can follow me on Twitter and my personal website. Or learn more at buttondown.com!