What I learned at Campsite
In February 2024, I joined Campsite as a product engineer to help build a new product that aimed to reshape how product teams communicate. While my time there was short — we announced Campsite would be winding down at the end of 2024 — I had the rare pleasure of working on a product that was genuinely fun to build, with a team that cared deeply about craft. Here are some lessons from that journey.
Ship early, ship often
The biggest practice I'll take away from Campsite is our relentless commitment to shipping early and often.
Every change followed the same pattern: feature flag it, ship it to staff, iterate on real usage, then roll it out. We kept our PRs intentionally small and focused (I ran the numbers: our average PR size was 8 files, with a median of 3). This wasn't by accident; we designed our development process specifically for these small, incremental changes.
Like many engineering practices, the benefits compound over time:
-
Small, incremental PRs create momentum. Breaking big features into smaller pieces lets you ship value continuously and get feedback earlier. This is especially important for early-stage products: the benefits of this fast feedback loop can't be understated. It also let us continuously use the new features, making course corrections a natural part of the process.
-
Frequent deployments demand robust infrastructure. Merging to main automatically deployed to production, and because of the small and frequent PRs it was common to do deploy updates dozens of times a day. When you're deploying to production this often, you need rock-solid test coverage and deployment processes. I know the team put a lot of work into our CI/CD pipeline and it felt great to have confidence in deploying frequent updates.
-
Small changes enable better collaboration. Instead of long-running feature branches, we were constantly reviewing and shipping each other's work. This created a natural rhythm where everyone on the team knew what was shipping and why, plus it generated abundant content for our public changelog.
The Campsite codebase is available on GitHub.
Small text input -> small ideas
I think Campsite's core product thesis is true: writing forces clarity, and collaborating on product work solely via scattered conversations on Slack is a bad way for product teams to work. The sweet spot is somewhere between chat and docs - less formal and more conversational than a doc, but something slower and more thoughtful than chat.
The writing I did at Campsite was better specifically because Campsite required me to slow down and think before I posted. And just like our engineering process forced us to have high confidence in tests, deployments, and releases, not having chat forced us to be more thoughtful about product discussions.
(Campsite does have chat, and we did use it for quick back-and-forth (ok, mostly memes) — but the meat of our product work happened in long-form posts where ideas had room to breathe and evolve.)
Posts + comments > chat threads
The other thesis I believe strongly in — especially in a world where LLMs exist — is that having discussions organized into titled posts with discussions in the comments is clearly better for organization than a bunch of unorganized chats.
Some will argue that you don't need to organize discussions when you have LLMs, but I disagree: we discovered that LLMs are significantly better at summarizing when a little bit of structure is already present.
It was incredibly easy to look up a discussion about something because our workspace was naturally self-organized into discussions. Each post had clear context, thoughtful responses, and — most importantly — actual conclusions. When you're forced to write something that others will reference later, you naturally put more care into making it clear and complete.
Thanks to this format, we were able to build:
- A search experience that found discussions, not just chat messages (good search in knowledge tools isn't easy; I think ours was pretty good!)
- A rollup feature that summarized long comment threads at the top of a post
- A daily summarization feature that highlighted important conversations
I think these features are much harder to build when all correspondence happens in chat.
Changing company culture is hard
While I'm no stranger to trying to get people to switch tools - prior to Campsite I was on the founding team of a developer tools startup - it turns out getting companies to change their internal culture is even harder.
People hate Slack, but they also like it. They like the familiarity, the instant gratification of quick replies, and the visibility into all of the conversations happening at the company. And I actually do think some companies are better off using Slack, particularly if they're operations-heavy — there's just too much ongoing communication happening to slow down and write posts.
But I really believe a lot of product teams would be better off kicking their Slack addiction and trying a different change of pace. Campsite's early adopters "got it", and it felt good to work on an opinionated product that wasn't for everyone. Several customers told us that they could feel their team's communications become more thoughtful after getting past the initial hurdles, validating our thesis that longer-form writing forces clarity.
I spent a lot of time thinking about how to help companies switch - by giving them a playbook, by shrinking the change, by knocking down common objections, and by appealing to identity. I think Linear has done a great job at all of this - in Linear's early days it was basically treated like a badge of honor for startups to say that they run on Linear, and their recently published guide to switching is pretty good.
Rails is a lot of fun
I built a lot of Rails apps around 2010-2014 and had forgotten how fun Rails is to work with for a certain type of developer (and I am definitely one of them). There's something deeply satisfying about a framework that guides you toward sound architectural decisions without being prescriptive — and our codebase at Campsite really leaned into Rails' strengths.
A few of my personal highlights:
-
ActiveRecord ORM: Rails' ORM lets you express complex business logic in a way that reads like plain English —
member.published_posts.with_commentstells you exactly what you're getting, and does so with barely any code. We had these elegant model scopes scattered throughout the codebase that turned complex database queries into clean, reusable methods, with additional tooling that identified N+1's and slow queries. Writing code like this makes me feel clever without making me write clever code. -
TypeScript tooling: Our homegrown TypeScript client generator was a particular joy — it took our routes and models and generated a fully-typed API client that plugged into React Query. It really let us flex the power of TypeScript and made working across two languages feel seamless.
-
Serializers & API design: We had a really clean serialization layer that transformed our Rails models into JSON for the frontend. Combined with strong test coverage and automated checks for N+1 queries, it made API development feel remarkably robust - the kind of setup where you could confidently refactor without worrying about breaking things.
Working with Rails again reminded me why I fell in love with software engineering in the first place — there's a certain magic in working with tools that just feel right, even if you can't always put your finger on why.
I also had the benefit of learning from an exemplary codebase - h/t to Nick Holden for re-introducing me to Rails and giving me a ton of helpful pointers in his code reviews.
Keeping a daily work log pays dividends
At Campsite we had async end-of-day standups, which Brian Lovin covered here. But I found my own reason to love them: they created a perfect record of my work. I recently fed nearly a year's worth of daily updates into an LLM and got back a nice high-level summary of what I did at Campsite. Writing down exactly what I did each day is now a regular habit.
The rare luxury of being your own power user
Finally, one of my favorite parts of working at Campsite was that we really dogfooded our own product. Most B2B products are built for external customers; at Campsite, we were building the communication tool we'd always wanted, using it exactly how we hoped our customers would.
This kind of extreme dogfooding is rare and I'll miss that experience. When your team feels every rough edge firsthand, quality becomes personal. We'd ship something, immediately experience what wasn't quite right, and iterate until it felt great. And because everyone on the team had strong design, engineering, and product taste, we never settled for "good enough".
What stands out from my time at Campsite isn't just the product we built, but how we built it: thoughtfully, iteratively, and with genuine joy in the craft. 🏕️
