“When art critics get together they talk about form and structure and meaning. When artists get together, they talk about where you can buy cheap turpentine.”

— attributed to Pablo Picasso

I’ve always loved that quote. There’s a whole genre of writing about company building that reads like art criticism — frameworks, principles, taxonomies of culture. Useful, sometimes. But the conversations I find myself actually wanting to have with other founders are the turpentine ones: what’s your offer letter template, what does someone’s first day look like, how do you run a standup that doesn’t suck, what do you do when you run out of space around the lunch table?

So this is a turpentine post.

What follows is the actual stuff — handbook, offer letter language, board readouts, Friday rituals — lightly redacted but largely intact, with links to the originals where I have them. It was also the hardest year and a half of my professional life. Most of what worked here exists because something broke first; I’ll share that too.

For the year and a half we were /dev/agents (now Dreamer), I had a recurring, low-grade frustration: there was never enough time for all the company building I wanted to do. The product had to be figured out, the team was growing, users were showing up, and the docs to write, the rituals to formalize, the playbooks to steal from people I admire and adapt for us mostly stayed on the TODO list. We did less of it than I wanted to.

And yet, looking back at what we did get done, I’m genuinely proud of it. Why am I proud? Because the team truly felt they got the opportunity to do some of the most productive work of their careers together. The shape of our week, the way we hired, the norms we set after several false starts. It worked for us, and a few people have asked me about pieces of it lately.

Last Friday, we asked the team what they thought best defined our culture and ways of working. Here’s a glimpse of the figjam we made together:

The setup

A note on context, because most of what follows leans on conditions that won’t hold for everyone.

We peaked at around 18 people, majority engineers, mostly in the office most days of the week. We were building a consumer product to enable anyone to discover, build and enjoy AI agents, which meant the team were among our own first users — eating our own dogfood wasn’t a virtue we had to enforce, it was just how the work happened. We were an experienced team, most of us had worked at Google at some point. We were well-funded but the calendar was the thing pushing us, not the bank account — we had a real sense of urgency about where the platform needed to be by when. And we hired generalists, hard: we wanted people who could move between frontend, backend, infra, and product with confidence, and we paid for that range.

That’s the water this post is swimming in. If your context is meaningfully different — distributed, larger, less engineer-heavy, longer time horizon — some of what follows will translate, some will need adapting, and some will probably be wrong for you.

The docs

A few of the artifacts that took the most thought, lightly redacted but largely intact. Each title below is a link to the real doc:

• Employee handbook — every company has to have one of these. The vast majority are way too long and a total snooze. If we’re going to make someone read something on day one, let’s make it genuinely readable and useful. Ours covered our responsibilities to our users (we held ourselves to a higher bar than industry standard, because of the kinds of user data we touched), how we worked, time off, and the bits of culture we wanted in writing rather than left to osmosis.
• Our hiring process — the end-to-end loop. We aimed to differentiate ourselves from the Googles and OpenAIs of the world, and from other early-stage startups, by making hiring feel personal. The hiring manager was the locomotive; the intake call was intentionally not the HM, so candidates had a friendly face and a personal cell number throughout. Every candidate who made it onsite got a book we loved (often A Philosophy of Software Design). And the offer letter itself wasn’t a carbon copy of the last one. Every letter opened with a personal preamble: a few sentences about what specifically we’d noticed about this person, what made them unique to us, why we saw them as a fellow traveler, before it got to the standard terms. The whole thing was printed on heavyweight paper, signed by all cofounders, and delivered in person. Extending the offer was an event in its own right. Every early team offer was extended in person. As we grew we started to extend offers over Zoom. To keep it hyper personal, we’d get everyone who’d interviewed the candidate to jump on the call as a surprise, taking turns to say why we were excited to work with the candidate. (Stolen, I think, from Gusto.) It made the offer feel like the start of a relationship, not a transaction.
• Comp & offer principles — our underlying thesis: build the smallest possible team, hire incredibly diligently, pay above-market on equity to reflect that. We targeted the 75th percentile of comparable startups on cash, and the 80–90th percentile on equity. The doc also covered how we thought about negotiation: what we’d flex, what we wouldn’t, and how we judged when an exception was warranted.

Even very different companies’ versions of these are useful to read side-by-side — the deltas tell you something.

The working docs

The handbook and hiring docs above were static: written once, updated rarely. The docs that actually ran the company were different.

go/things — “Things to do next.” A single Google Doc, edited every week, that captured what we were working on right now and what was next. (go/* were our internal short-links: anyone in the company could type go/things and land here.) Every Monday I’d reset the “Biggest Friction” list with concrete items pulled from Discord, calls and chats with users, internal dogfooding, and Friday’s demos and user time. Then I’d write “This week’s big rocks” with named owners. The doc was append-only: anyone could scroll back to see how priorities had shifted, what bugs had survived three weeks of fast-follows, and what milestones we’d already cleared. It was the most-edited doc in the company and the closest thing we had to a roadmap.

go/posts — the strategy index. A directory of short blog posts linked from the homepage above. (The Google Sites page was the corporate default start page for everyone at /dev/agents, so every morning the company literally opened on the team.) Some were product philosophy (“The Magic of Direct Manipulation”, on the importance of an impossibly tight edit-to-test loop); some were operating principles (“Spend liberally on inference”, which argued that worrying about inference costs in the early days is a great way to fail to solve user problems fast enough to matter). Most posts weren’t policy — they were arguments, put somewhere anyone could find them, push back on them, or borrow from them. The most important of these was our “Null hypothesis”… Not necessarily the most optimistic name in retrospect! This was our medium-term product strategy doc — the path we’d execute in the absence of any data showing us we should be doing something else. Having the humility to be willing to be proven wrong on any aspect of this by feedback from users was a core tenet.

A live priority doc rooted in user friction, plus a public reasoning library — that combination was probably more useful day-to-day than any of the static docs above.

How we made decisions

The buck stopped with me. If you didn’t know who owned a call, it was me — which sounds dictatorial in the abstract but is fast and clear in practice when everyone trusts you’ll listen first. My co-founders Hugo and Nicholas had their own clearly-defined swim lanes where everyone knew they were the decision makers; the rest of the team had real authority over the work they were driving day-to-day. Any disagreements (or just need to stamp something consequential) surfaced fast, and we used disagree-and-commit when needed (rarely).

Three things kept this from collapsing into a bottleneck:

1. Listening preceded deciding. What looked like fast decisions was the visible part of a lot of unglamorous behind-the-scenes alignment — particularly Hugo and I, out of band, so the decision moments looked decisive because we already broadly agreed.
2. Top-level trade-offs were public. go/things and go/posts were where the big rocks and strategic priors lived, in writing, so the team rarely had to guess what we’d say.
3. Speed huddles when stuck. If something was blocked, we’d pull two or three people in and make the call right then. Being in person made this nearly free.

The shape of the week

The single highest-leverage company-building decision we made was probably also the cheapest: we got really deliberate about what a week at /dev/agents felt like.

Monday — kickoff. The whole team got together. The go/things doc had been updated on Sunday, and we’d look at it together. What were we trying to get done this week, what was blocking us, what did success look like by Friday. It was short. It set the rails. This kickoff meeting was also the forum for sharing any important company updates / special events on the calendar for the coming week and letting everyone know how to get involved.

Tuesday through Thursday — daily standups, and ruthlessly nothing else. As much as possible, the experience for every member of the team was: a short morning huddle, then the day belonged to them. No status meetings, no syncs, no “quick chats” that took an hour. If you needed to talk to someone, you talked to them — but recurring meetings were treated as a real cost, not a free coordination tool. The one daily ritual that wasn’t a meeting: lunch together. I was there 95% of the time, and a lot of the day’s most useful conversations happened around the table.

Friday — hackathon, then wrap the week. From mid-afternoon, the whole team spent about an hour using the product to build something — a small agent, a tool, a one-off experiment — and everyone kept a friction log along the way. At 4pm we gathered in our largest meeting room (called W.O.P.R., naturally), showed each other what we’d built, and shared the most blocking friction from our logs live. Totally casual, supportive audience. Once we had product in users’ hands — starting with our alpha community — we’d have a few users dial in to each Friday session to demo what they’d built too. Seeing what they were creating with the product, and hearing their friction first-hand alongside our own, was gold. The friction surfaced here, alongside what we’d heard from users in Discord and on calls, was the primary input into Monday’s go/things. We posted the demo videos in #general after.

Adjacent to that hackathon culture: meetings were generally demo-first, not deck-first. Almost every internal meeting where I’d have built a slide deck at a previous company, we’d instead gather around the whiteboard, walk through a raw doc, or run a live demo of the actual thing. If we couldn’t do it one of those ways, we usually weren’t ready to talk about it. It took a turn to get here — in the very early days we’d debate over mocks for far too long. Once we realized that iterating in running code was faster and better we never looked back.

That cadence — kickoff, deep work, demos, users — did more for us than any number of process docs. It compounded: people got long, uninterrupted stretches to actually make the thing, and a forcing function every Friday to put it in front of someone and feel whether it worked.

We also worked hard to share as much context for others asynchronously as we could, so if you ever wanted to dip into something you weren’t familiar with, some context would be right there.

I wrote a Slack post to the team about both points one Saturday morning when I could feel the meeting calendar starting to fill in around the edges. The headline arguments, paraphrased:

On channels. Keep long-lived public channels to an absolute minimum. A few busy channels beat 50 sparse ones. Use existing public channels before creating new ones; tmp-* channels for short-lived projects are strongly preferred. And please do EVERYTHING you can in public channels instead of DMs — it creates valuable shared context and search fodder.

On meetings. Most regularly scheduled, recurring meetings are harmful. They take the time of the meeting itself, but they also prevent anyone doing creative work from ever settling into anything. And the time it takes to recover focus after a meeting often equals the meeting itself. Two principles going forward: (A) we’ll schedule any necessary meetings before lunch, leaving afternoons free for deep work; (B) no recurring meeting with three or more attendees gets set up without checking with me first. I know that sounds draconian — trust me on it. Setting the norm now matters.

I post these not because I think they’re finished policy. They’re a snapshot of a specific moment, with a specific team, at a specific size. But the meeting one in particular is the kind of thing I would have loved to read from someone else when we were figuring out our own version.

Always be shipping

Code that landed in main went to production within minutes. No release weeks, no code freezes — outside of a few narrow exceptions around press launches. Partly that was a technical choice (the system has to actually support it), but mostly it was a cultural one. Once a team gets used to a two-week release cadence, the idea of shipping a small fix this afternoon starts to feel reckless. We kept the muscle by exercising it every single day, and it was the engine that made the friction logs below actually pay off.

Friction logs

If I had to name a single ritual that mattered most to how /dev/agents worked, it would be friction logs. The practice is simple to describe: you sit down with the product, with a specific user goal in mind, and you document every moment of friction as you encounter it — typos, slow loads, dead-ends, confusing copy, a button that’s two pixels off. Nothing is too small. (This post from my former co-worker Sebastian Bensusan is the best public write-up I know on the form.)

I picked the habit up at Stripe and have been quietly evangelical about it ever since. I wrote earlier this year about why it sat at the center of how we thought about product. The operational details that actually made it stick at /dev/agents:

• Calendared, not opportunistic. Friction logging had a permanent slot every Friday afternoon — the hackathon hour. The week was otherwise full; if you don’t put dedicated time down for the user’s perspective, you will never have it.
• Whole team. Everyone friction-logged — designers, marketers, and the engineers who’d built the thing being logged. An engineer who has just felt a confusing flow can fix it in the next hour, without a ticket or a meeting.
• One-week turnaround on the top items. The top items from Friday’s logs showed up in go/things the following Monday with a named owner, and shipped by the next Friday. When that broke, we’d ask ourselves why.
• Off-cycle helps too. The weekly cadence carried most of the load, but some of the most surprising friction came from off-cycle logs — when someone had a reason to come to part of the product with fresh eyes.

This was also what made continuous shipping pay off. Without the tight loop of feel the friction → prioritize on Monday → shipped by Friday, “always shipping” just means shipping the wrong things faster.

Dogfooding

Every member of the team used the product every day for real work — drafting docs in it, planning the week in it, building little internal tools in it, having FUN! Not because of a memo telling us to; because once you’ve felt how much faster it is to do your job with the thing, you stop wanting to use anything else. The fastest way to make a feature better is to need it yourself.

How we made board meetings an internal transparency moment

Two more docs that mattered more than I expected: the board materials.

Every board meeting had two artifacts: a deck and a memo. They served different purposes.

The memo was a short private letter from me to the board — not a status update, a letter. The point was to be honest and a little vulnerable about where we actually were and what I was worried about, in a raw way. Two or three pages. No charts. No company-success theater. Sometimes the most useful thing I could send was a few paragraphs about a decision we were wrestling with.

The deck was the working artifact for the meeting itself: strategy, metrics, financials, all of it. Crucially: the deck went to the whole team in #board on Slack a few days before the meeting, including all the financials, with an open invitation to ask questions and push back. I answered every question that came in honestly. Often I’d get back a sharper framing or a correction that made the actual meeting better — the team became a braintrust I went into board meetings with.

Right after the meeting I’d post a full readout in #board and talk through the same readout at the next all-hands. The format was: how the meeting went, who got specific credit, what the board reacted to, and — most importantly — the actual questions the board asked, with my honest answers. Something like:

Hey folks, the board meeting went really well earlier. The main questions they had were:

1. Any early signals on retention?

It really is too early to tell, but (i) we see a core of highly engaged users in the community and on social, (ii) there’s definitely launch-day excitement we need to wait for the data to mature past, and (iii) the leading data Johan pulled this morning shows a majority of users have returned post day one and we’re seeing promising week-over-week engagement from same users.

2. What can we learn from where competitors are seeing really viral, organic traction?

Decent back and forth. [Competitor] comes up constantly in early conversations. But we’re not seeing real retention there. It feels more like YouTube for apps: fun and polished, not genuinely useful. We’re not treating them as playing the same game right now. That could change; we’ll watch it.

The amount of “what does leadership actually believe?” speculation that just vanished when we shared the deck and the readout was hard to overstate. It also meant the next time someone on the team was in a recruiting conversation or fielding a hard question from a user in Discord — about strategy, about runway, anything — they didn’t have to guess what we’d say. They’d already heard it.

A few smaller things

A few smaller things the team kept calling out as defining when I asked, in no particular order.

No process for process’s sake. Every ritual described in this post existed because something specifically would have gone worse without it. The corollary was that we killed rituals when they stopped earning their keep. It is much easier to add a process than to remove one; both skills matter.

Fluid roles. People didn’t have rigid swim lanes. The same engineer might spend two weeks on a mobile feature, then a week on backend reliability, then a week pairing with the designer on a flow. We hired generalists who could see a problem clearly enough to know who needed to pick it up — and then often picked it up themselves. The price was that the org chart looked weird; the payoff was that the dreaded “that’s not my area” bottleneck rarely surfaced.

Easter eggs. Every team has its quirky little rituals and in-jokes that bind us together — you can imagine ours. The one I’ll share: we geeked out adding fun easter eggs to our company site. See if you can find them all.

No task too small. Cofounders emptied the dishwasher. We cleaned up spills and made sure the restrooms were presentable. We onboarded users by hand. When a customer hit a bug, one of us was usually in the Slack thread within minutes. None of it was performative — at our scale people, it was the only way things got done — but it set a tone that radiated. People mirror what they see at the top.

What didn’t work

A few things we tried that didn’t take, because the wins above were misleading without them.

Lunch and learns. I wanted these to be a thing. They never caught on. We were a small team of builders who liked eating lunch together as an informal way to catch up with each other and loved getting back to their IDEs and coding agents — ritualizing what was supposed to be a break read, correctly, as a tax. We let it die.

Distributed workstreams. For a stretch we tried fanning planning out: separate workstreams, each with its own owner writing their own doc, each picking its own next priorities. At ~10 people that was much worse than the single go/things page where the whole company’s next week lived in one place anyone could scroll. The coordination overhead between workstreams dwarfed any throughput we got from parallelism. Not everything that scales well at 200 people scales down well at 10. We thought we were giving everyone autonomy, but what everyone really wanted was clarity!

What this doesn’t capture

These documents and rituals make all this look more orderly and intentional than it actually was. We did not have it figured out, and several of these artifacts only existed because something broke first and we needed a new norm to put up against it.

Someone once told me, before we started /dev/agents, that running a startup is an exercise in getting punched in the face in a different way every single day. They were right. Over the past two-and-a-half years I’ve had cofounders depart, senior hires not work out, headcount shrink in waves I didn’t see coming, and entire stretches where the company genuinely felt at risk. The hard part isn’t writing the handbook. The hard part is absorbing all of that privately while projecting genuine optimism about where we’re going — to the team, to investors, to the people you’re trying to recruit — and continuing to sweat the details on the product itself, because that’s the only way you build something people actually want.

What I most want to convey isn’t any one of these documents. It’s that company building is real work, and at a small fast-moving startup it never feels like there’s time for it. There won’t be. You do it anyway, in the cracks, badly at first, and you keep tending it. The docs aren’t the point — the act of sitting down and writing the thing down is the point, because it forces you to decide what you actually believe.

If you’ve written your own version of any of these and want to swap notes, send them my way. The conversation I most want to keep having with other founders is about turpentine.

Thanks to Noah Pepper, Jeremy Hoon and Johan Duramy for reviewing drafts of this post.

One more thing

A couple of reviewers of this post asked which service providers and vendors we ended up using and liking best. Here’s the list — peak turpentine.