Every time I show someone a project I've built, the first question from a technical person is the same: "What's the stack?" Not "what does it do?" Not "who is it for?" Not "what problem does it solve?" The stack. As if the technology underneath is the most interesting thing about a product that exists to serve actual humans.

I'll answer the question, because I have nothing to hide. Some of my projects use Next.js. Some use vanilla HTML and JavaScript. One uses Supabase. One uses a Python script that generates static files. The answer is boring, and it doesn't matter. Not one bit.

Nobody who uses Modern Retro cares whether it's built with React or vanilla JS. They care whether the images are interesting. Nobody who reads CultureTerminal cares about the RSS parsing pipeline behind it. They care whether the content is good. Nobody who uses the London Pub Guide cares about the deployment infrastructure. They care whether the pub recommendations are trustworthy.

The stack is an implementation detail. It's plumbing. It's the thing behind the wall that makes the taps work. And while plumbing matters -- you want it to function, you want it not to leak -- nobody has ever moved into a house because of the plumbing.

The tool obsession

The tech industry has an unusual relationship with its tools. No other creative field talks this much about the means of production. You don't ask a chef what brand of pan they used. You don't ask a photographer about their lens before you've looked at the photo. You don't open a novel and check what word processor it was written in. But in tech, the tools have become fetish objects, discussed with more passion than the things they're used to make.

You don't ask a chef what brand of pan they used. You don't ask a photographer about their lens before you've looked at the photo. The obsession with tools is unique to tech, and it's a distraction from the only thing that matters: does the product work?

I think this happens because technical people conflate the means of production with the quality of the output. They assume that a product built with a sophisticated stack must be better than one built with a simple one. That Next.js is inherently superior to a static HTML page. That a React app is automatically more professional than something built with vanilla JavaScript.

This is a category error. The quality of a product has almost nothing to do with the technology behind it and almost everything to do with the decisions made by the person building it. What to include. What to leave out. How it feels. What it prioritises. Those decisions are independent of the stack. They live in the realm of taste, judgement, and understanding of the audience. They're the hard part. The stack is the easy part.

The right tool for the job

When I'm deciding how to build something, the question I ask isn't "what's the best technology?" It's "what gets this thing live fastest with the quality I want?" Sometimes that's Next.js with Supabase for something that needs a database and authentication. Sometimes that's literally a folder of HTML files deployed to Netlify. Both are valid. Both produce working products that serve real people.

🎯
The real stack: Taste + Claude Code + whatever gets it live fastest. That's it. The specific technology is an implementation detail that changes project to project. The taste and the tool stay constant.

Forest Quiz is a static site. It loads fast, it works everywhere, and it does exactly what it needs to do. Building it with React wouldn't make it a better quiz. It would just make it a more technically complicated quiz that does the same thing. Complexity isn't a feature. It's a cost. And if you can achieve the same outcome with less complexity, you should.

This is a perspective that's obvious to anyone outside of tech and apparently invisible to many people inside it. The user doesn't see your stack. They see the product. And the product is either good or it isn't, regardless of what's powering it underneath.

The questions that matter

Here are the questions I wish people asked instead of "what's the stack?"

What problem does it solve? This tells you whether the product has a reason to exist. Who is it for? This tells you whether the builder understands their audience. What's the one thing it does best? This tells you whether there's focus and clarity. What would you change? This tells you whether the builder is still thinking critically about their own work.

These are product questions. Strategy questions. Taste questions. And they're infinitely more interesting than what JavaScript framework is running under the hood.

The question "what's the stack?" reveals the asker's priorities, not the product's quality. The question "what does it do and who is it for?" reveals everything that actually matters.

A liberating perspective

Here's why this matters, especially for people like me who came to building from outside of tech: the stack doesn't matter. If you've been told you need to learn React, or master TypeScript, or understand containerisation before you can build real products, you've been sold a lie. What you need is a clear idea of what to build, who it's for, and what good looks like. Then you use whatever tool gets you there.

I can't write code from memory. I couldn't explain the difference between server-side rendering and client-side rendering in a technical interview. But I've shipped fourteen live products that work, that serve real purposes, and that look considered. The stack behind each one is different. The taste behind each one is the same.

Stop asking what it's built with. Start asking what it does and whether it does it well. That's the only stack that matters.