Paul Graham's new essay, Making Startups Powerful, asks founders to set revenue aside for a moment and ask a bigger question: "what would make this company more powerful?" Then he walks through the ways companies get there. Get upstream. Own the customer relationship. Have money flow through you. Find network effects. Open up a platform.

It's easy to read that as a menu, and my first pass did exactly that. Earmark sits in the meeting where decisions happen, so we're upstream. Teams share context in Projects, so there's a network effect. Our users run agents all day, so tokens could flow through us. Add a marketplace of workflows and you have a strategy that would look great on a slide.

It would also be mostly wrong. Two sentences in the essay are the reason.

Two sentences

The first is the condition Graham attaches to every tactic: "They all have to make things better for the customer." If they don't, "you won't have any uptake." Power that customers didn't choose to give you isn't power. It's a slide.

The second is closer to an aside. Graham notes how much of his advice to founders contains the word "just," and that the complexity founders add usually comes from fear. A lot of the time, he says, the advice amounts to "just stand up straight."

Put those together and my menu falls apart. Most of it was a way to sound bigger than we are. The question I'd been stepping around was the simple one: what do our customers need us to be?

Power that customers didn't choose to give you isn't power. It's a slide.

The simple version

Graham suggests asking what the perfect world looks like from the customer's point of view. For the product and engineering teams we work with, I think it's this: you talk, you decide something, and the decision shows up in the work intact. Nobody re-explains it or rebuilds it from memory. When it changes, the change follows it.

Here's how that breaks today, in a made-up but familiar example. A team agrees to let customers export their data, but only after legal confirms what can leave the EU. Two days later the ticket reads "Add CSV export." An agent builds exactly that, quickly and well. The condition never made the trip.

That gap has always existed. What's new is how fast it turns into software. When building took weeks, someone usually caught the bad instruction in standup. Now a misunderstanding can ship before anyone notices that two people left the meeting with different ideas of what was agreed.

The condition never made the trip.

So the simple version of Earmark is this. When a decision leaves a conversation and lands in someone else's hands, or an agent's, it should arrive with its meaning intact. That's the whole job, and it isn't a small one.

Why that's the upstream position

Graham writes that "upstream is almost always good, whether it's with money or user relationship or customer stage or data." His example is Rippling, which started with onboarding software "because that's where the life of employee data begins," and built it far better than that market required.

In product work, a requirement's life begins in a conversation. Everything after it, the spec, the ticket, the prompt, is a compressed copy. That makes the conversation the upstream point. Being present for it is an opportunity, though, not a moat. Capture keeps getting better everywhere, and any capable agent can read a transcript.

"Upstream is almost always good."

— Paul Graham

The Rippling detail is the part I keep coming back to. Starting upstream only matters if you do much more there than the spot requires. For us, that means being useful while the people who know the answer are still in the room. Noticing that nobody decided who approves the exception. Catching that the deadline was a preference, not a commitment.

It also means keeping the decision current after the meeting ends. The customer changes their mind on Wednesday. Engineering finds a constraint on Thursday. The brief written on Monday shouldn't still look authoritative on Friday.

A plain transcript can't do either of those things, and that's the test we have to pass. If a general agent given the same transcripts produces an equally useful brief with the same effort, we haven't earned the position.

Back to the menu

Run the menu through that lens and most of it changes shape.

Start with token flow. We could route every agent call through Earmark and bill for it. But our users already pay for Claude, Codex or Cursor, and many have put real time into those setups. So Earmark goes to them instead. We save Markdown transcripts locally for their agents to read, and Chat hands questions off to Claude Cowork or Codex. Making people switch agents to get value from us would fail the customer test on day one.

Network effects look different too. Projects let teammates pool meetings into shared context, but that only counts if adding a teammate makes Earmark better for someone already using it. If a PM's next brief improves because of an engineering discussion and a customer success call they weren't on, it's real. If not, we added a seat. More shared context also can't quietly become more access. Today, teammates can't open each other's meetings, even when Chat can draw on them.

Making people switch agents to get value from us would fail the customer test on day one.

Generosity becomes portability. Graham argues that creating more value than you capture tends to pay you back. For us, that means your context comes out as files you can read, edit and take anywhere. If exporting a transcript solves a team's whole problem, we need to hear that. And Earmark doesn't use your meetings or chats to train AI models. Sharing inside a team doesn't change that.

Platforms and going full stack can wait. A marketplace of workflows is premature, and so is doing our customers' product work for them. What I'd borrow from both is the ambition: take responsibility for one complete workflow with a few teams, from customer call to reviewed brief to shipped work, and find out exactly where it breaks.

How we'll know

One tactic from the essay I am taking literally is selling to early-stage companies. Graham's case is that they decide quickly and grow with you. That's who our Earmark for Startups program is for: qualifying teams get up to 20 Pro seats free for three months. Small teams feel every handoff, because the person who hears the customer often writes the brief and reviews the code too.

They're also the fastest way to find out whether the simple version is true. After a few weeks with a team, I want plain answers. Did they get useful work done with less reconstruction and fewer avoidable mistakes? Did they come back without being reminded? Did a second teammate make it better? When the free period ended, did they pay?

"Just stand up straight."

— Paul Graham

If the answers are yes, the power Graham describes should follow. If they're no, a better slide won't fix it. Either way the work is the same. Just make sure the decision survives the trip.