Building with Claude: Lessons from the Field

A year ago I started building tools that use Claude as a core component rather than a bolted-on feature. These are notes from that experience. Patterns that held up, assumptions that didn't, and a few things I wish I'd known at the start.

The framing that actually helps

The most useful mental model I've found is thinking of Claude less like an API and more like a very fast, very well-read collaborator who has no memory and needs clear context every time you start a conversation.

That framing changes how you structure prompts, how you think about state, and what you try to automate vs. what you leave to the user.

Prompts are product decisions

The biggest mistake I see teams make is treating prompts as implementation details. Something the engineer handles after the feature is designed. Prompts are product decisions. They determine tone, scope, failure modes, and where the human stays in the loop.

Write them early, test them with real content, and put them somewhere reviewable.

What surprised me

Shorter context windows actually helped in some cases. When I forced myself to summarize rather than pass everything in, the outputs got better. There's something about constraints that clarifies thinking, both the model's and mine.

A year in, the pattern that keeps holding: the builds that work treat Claude like a collaborator who needs setup and constraints, not a service that takes input and returns output. The teams getting useful work out of these tools are the ones taking that distinction seriously. The teams that aren't tend to ship features that demo well and break in production.