It takes $4,169 a month across 58 services to keep Buttondown running and sending your emails. Plus another 30 open source software projects (and the 10% of our revenue we donate to them) to power our codebase—not to mention the hundreds of other open source projects behind the SaaS services powering Buttondown.

Buttondown sits on the shoulders of giants. So does every single software project—and nearly every human endeavor.

“We see more and farther than our predecessors, not because we have keener vision or greater height, but because we are lifted up and borne aloft on their gigantic stature,” one Bernard of Chartres is said to have quipped nearly a thousand years ago. It’s the snowballing effect of generational knowledge that took humanity from the first transistor to the Frontier supercomputer and its 1.102 exaFLOPS of computing power in 75 years. Someone figures out how to switch electronic signals, another how to etch that into silicon, and a million trial and errors later humanity has LLMs running in their pockets.

Sometimes it’s the hard-won lessons that guide our intuition into the next great discovery. We don’t have to reinvent the wheel; we can innovate on top of it. Sometimes it’s just in knowing that something’s achievable, the “adjacent possible,” as Farnam Street quotes scientist Stuart Kauffman. No human in recorded history had run a 4 minute mile until Roger Bannister did in 1954—and today, that time is now run by virtually every state-level-best high school cross-country runner.

Once you’ve done something with that knowledge, with that framework and foundation undergirding your work, it’s worth giving those whose shoulders you’re standing on a shout out.

What’s your stack?

I couldn’t have built Buttondown without Ray Tomlinson sending the first email over ARPANET in 1971. And I couldn’t have built it as easily without Mailgun’s email delivery service. 

Every bit of software is a story of interdependence, all the way back to the first version of Linux. “Sadly, a kernel by itself gets you nowhere,” lamented Linus Torvalds after painstakingly writing his 0.0.1 Linux kernel in 1991, before recommending the GNU shell and compilers and detailing how the Intel 386 CPU made that first version possible. Fast forward several decades, and a modern Linux install will come with thousands of packages, built and maintained by an army of developers.

Open source, perhaps thanks to its academic roots, has a strong tradition of attribution. One forks a project, the new iteration takes on a life of its own, until someone repeats the process. Thus the KDP project’s HTML Widget got turned into a browser engine, KHTML, which Apple then forked into Webkit to power Safari, which Google then forked into Blink to power Chrome, which Microsoft then used to build Edge, and a bit of code committed in 1998 dictates the design choices of web developers in 2024.

At one level, it’s a cool historical footnote, like the knowledge that we’re made of the dust of the big bang. But at another level, it’s a reminder to share the love, and show the next generation of developers how they, too, could pull such things off.

How was this thing built?

New products, so often, start off as a tinkerer’s paradise. You can take an Army Jeep down to its bolts and put it back together again, learning what makes it tick along the way. Then, products gain sophistication and polish, then go mainstream, the innards hidden behind Do not remove stickers. Good luck taking apart a modern EV.

Same for PCs—modular, then streamlined into a thin aluminum wedge. Same for software—remember dropping into DOS mode, or hex editing files?

The web is one of tech’s remaining bastions of openness. Sure, it’s increasingly hard to know how sites work, with obfuscated code and web services running behind the scenes, but you can still Inspect Element and see what font was used for a site’s headings or infer if it’s powered by WordPress. You can get a bit further with Chrome extensions like WhatRuns, Wappalyzer, or BuiltWith which can tell you that a site is powered by Next.js, uses Cloudflare’s CDN, and Stripe for payments. Enough to get a budding web developer started, anyhow.

You’ll have to share your stack, manually, to give them any more clues.

There’s a fun tradition on the web of sharing how a site is built. Like the colophon in a book, with publisher and typesetting info, an About or What I Use page can shed light on how one built this particular site.

Rewind AI Co-Founder and former Twitter designer Paul Stamatiou maintains both a Stuff I Use page with everything from displays to his email client, and an About this Website page detailing his Jekyll setup. Founder and author Derek Sivers maintains a more minimal What I Use page, featuring his camera, keyboard, and car. And the Uses This blog, perhaps most famously, includes well over a thousand interviews featuring hardware, software, and ideal setups from everyone from John Gruber, Valve co-founder Gabe Newell, and Cory Doctorow to yours truly. It’s good fun, but also insightful to see the choices that go into each creator’s setup, the slight differences that make all the difference.

The project-level version of those pages are even more impactful. StackShare features the tech behind everything from the New York Times to Facebook and Shopify, ideally helping you see which teams are using Typescript or AWS Lambda. And if there’s enough interest in stacks to make StackShare an acquisition target, there’s plenty of interest in you and your team sharing your stack.

Share your complements

So, start by listing your stack. It could be a blog post, or an addendum to your About page.

You could list the services you use, like Buttondown’s Stack page listing every paid service we use—inspired by freelancer tracking app Cushion’s Running Costs page. That could give the next generation of founders both ideas on how to build, and an estimate for their expected burn rate.

Then, you could also build out your open source stack, like Buttondown’s Open Source page, listing the packages and projects that made your tool possible. And, if possible, you could use that as a chance to give back, as Buttondown does along with Sentry, Spotify, Vercel, and more in the FOSS Funders project. Or you could give back in kind, contributing upstream to their projects or building add-on packages that you, in turn, give back—something else we do, with our Tiptap extensions for footnotes and LaTeX, among other projects. And if your project is open source with direct contributions from others—or if you’ve pulled in beta testers to help make your project possible—credit them as well to share the love.

“Err on the side of giving props liberally,” says the WordPress Core contributor attribution guide. That matters, for those who contribute code and those who made your contributions possible, alike. Apple does it. Meta, as well. Startups, though, tend to do it the best. You’re building the product, you’re making the stack calls, so your endorsement rings even stronger.

Then build on that. Write in your developer newsletter about your decision process, why you use the tools you do, and how you’ve solved problems and built your product with them. Mention in your Changelog when you’ve added something new to your stack. Give the team a shout-out on your favorite social media when they come to the rescue. And keep your stack updated, as things change over time (perhaps saving the old choices for the record, so people can trace the roots of how your current stack took shape).

There’s the benefit of openness. Want developers to use your product—or consider joining your team? Make sure they think you’re building on a cool stack, and solving interesting problems instead of reinventing the wheel.

There’s also the benefit of trust. We were more likely to trust new PC OEMs when we knew they were built with components we trusted from Intel and Nvidia. The Arc browser’s security page leans into that, listing the cloud services and specific data sent to them. You might not trust Arc yet, but you might already trust Google Firebase, and the trust trickles down.

And, perhaps most beneficial, there’s the benefit of community. Publish what your product is built on, then share that page with the services and project maintainers you featured. Thank them. You might make a new connection, might get a bit of reciprocity if they feature your product, might just get warm fuzzies out of the interaction. It’s all worth it, in the end.

No project is an island unto itself

“I grow little of the food I eat,” started a soliloquy Steve Jobs emailed himself in 2010. “I did not invent the transistor, the microprocessor, object oriented programming, or most of the technology I work with.”

“I love and admire my species, living and dead, and am totally dependent on them for my life and well being,” he concluded.

Jobs was many things, but not known for humility, nor for sharing the spotlight. Yet here, through a crack in the façade, shined a glimmer of respect for the ideas and inventions he’d spent his life perfecting.

Gratitude’s part of it, but so is curiosity. I love seeing behind the scenes of my favorite projects, and have a child’s curiosity at construction sites and factory tours. Does it matter that your project used SES to send emails, and how you solved some obscure problem that only a handful of us would even know existed? Will I care, and be more likely to read your writeup? Absolutely.

It just might be the thing that makes me remember your project, think of it the next time I need to add a tool to my stack or build in a new integration.

It’s my favorite developer marketing—because it’s marketing for the other tools, and who doesn’t like someone who’s always praising their friends?