The Pains of Being Pure at Heart

The Pains of Being Pure at Heart

This is not a musical post

ray-garcia

Nov 18, 2025

I'm not going to lie: the topic came before the title. My extreme creativity led me to connect it with the name of a band I've been listening to lately, leveraging the incredibly complex relationship of... using the same word. Now I have to build a narrative that fits and pretend it was all planned from the beginning. I know, I'm a fraud. But these days, what isn't on the internet? At least I write my own articles.

Retry
Claude can make mistakes. 
Please double-check cited sources.
Approaching weekly limit

The Pains of Being Pure at Heart is a New York band formed in 2007, with a very authentic lo-fi sound. They self-released their first EP, self-titled, uploading their songs to MySpace. In fact, at their first show they played five songs in ten minutes using a backing track as drums. It was lo-fi, imperfect, scrappy.

The thing is, it worked. They soon got picked up by Pitchfork, were named "Band to Watch" in 2007, and their career took off.

They didn't have a designer either

This is where you discover the sad relationship between the narrative and what I actually want to talk about.

Validation as a Proxy

The main goal of validation is to reduce uncertainty. It's making sure what you're going to build has the fewest possible cracks because the cost of validating is much lower than the cost of building. Therefore, validate first, build later. Although in reality, "validate" is a confusing term. Validate what exactly? That the problem exists? That your solution solves it? That people will pay? Each discipline interprets it differently: the designer validates with prototypes, the engineer with technical tests, the PM with usage metrics. But they all share one assumption: validating is cheaper than building.

There are exceptional cases that took validation to the extreme, like Fireflies.ai, now valued at one billion dollars, which started selling "AI notetaking" services for $100 a month. But they had neither AI nor product. It was the two founders manually joining video calls, camera off, pen in hand. They took notes, typed them into Word, and sent them ten minutes later. Was it extreme? Yes. Ethically questionable? Also yes. But it was effective. Because they needed to validate that the problem was real before building complex technology.

Now they are happy

Validating today is a whole different ballgame. The cost of building a functional MVP has plummeted. You no longer need weeks of interviews before writing code, because building something tangible takes days. Moreover, the act of building the product forces you to confront the flows, the end-to-end, and the technical capabilities and limitations much more consciously. Why not validate with the product in hand? Conversations are more honest, questions more specific, and you can iterate very quickly.

Let's Talk About Generalism

A generalist is someone who knows a little about many different areas. Enough to connect the dots but perhaps not enough to dive into the depth of the concrete with agility. A generalist is not good at vertical (that's why they're a generalist, not a specialist), but excellent at horizontal. They know a bit of frontend, backend, design, business, marketing...

copyright @andrewships

In the current scenario, an LLM can perfectly cover the gaps. Want to design something? Lean on Lovable or Firebase Studio. Define the frontend? Force Claude Code to use Shadcn with Atomic Design. Maybe a simple backend? Supabase might be the right option. The generalist knows the tools, understands how things should be built, and could dive into the details if needed. Well-directed, an LLM can handle it.

A generalist understands what's a hack job and what's overengineering. They understand the tradeoff and accept it consciously. And in that sweet spot, I believe, lies the virtue. Nothing will be pure, but it won't be dirty either. It sits in the right place where something can serve as a "beginning." Let's not kid ourselves, the tradeoff exists, but it's a tradeoff worth accepting when you're validating an idea. Purity comes later.

Purity is the Destination

The goal is to find the treasure. El Dorado. The ideal route should have two lanes, preferably paved, and avoid being winding so our trucks can go to the village to load up the treasure. But this required months of planning: Maps, satellite photos, exploration teams, local guides, hostile indigenous people. It's... too much.

In this new scenario, your cousin has a helicopter and can drop you off at the edge of the jungle, walk a hundred meters, and pick you up for free, because he just paid off the last installment of the loan and is on vacation. Plus, it turns out he's close friends with the indigenous leader. Maps are still useful, but the information you get from being on the ground is invaluable. When stepping on the terrain costs the same and is just as safe as studying it, why not do it?

The Pains of Being Pure at Heart

There is pain in pursuing purity before validating you're on the right path. The band understood this: they uploaded songs to MySpace, played with backing tracks, self-released their first EP. It wasn't pure, but it was real. And it worked. Purity came later, with renowned producers and professional studios. But first they made sure they had something worth polishing.

The Practical Example

This reflection comes from my own experience. My reality has changed. A few weeks ago I left my position as Engineering Director at Factorial. And now I find myself in a new place, unfamiliar to me. I need to find my next big challenge.

But searching isn't easy and I found myself with an existential question: Is my resume good enough for this job I'm applying to? So I got to work. I pulled out my generalist soul and tried to create a product that would solve my problem. Is it ideal? I don't know. I think it solves my case, and probably others'. And what's the best way to validate it? I built it.

It's here: https://evalua.cion.es

Shall we validate it?