I keep coming back to the difference between a flashlight and a lantern.
A flashlight is useful. It points directly at the thing you already decided matters. It helps you move faster toward a known destination. It answers the question, “Where am I supposed to go?”
But it also creates a tunnel. Everything outside that beam disappears.
A lantern works differently. It throws light in every direction. It does not point at the answer. It reveals what is already around you: the side path, the strange object in the corner, the person standing just outside your attention, the better question you would have missed if you kept staring straight ahead.
That difference has become one of the most useful ways I understand how I build.
I do not usually begin with a perfect product idea. I notice something. A person is doing work outside the system because the system does not fit. A metric sounds impressive but falls apart when you inspect the data. A process technically works but nobody can explain it. A project folder looks finished until you realize it contains five reusable parts that could become something completely different.
The flashlight response is to solve the request directly and move on.
The lantern response is to illuminate the surrounding problem long enough to understand what is actually there.
That does not mean wandering forever. Curiosity without judgment can become another form of procrastination. The point is to see broadly before choosing narrowly.
I think children are naturally good at this. They do not begin with a syllabus. They touch something, notice what happened, ask another question, try again and build a model of the world through interaction. The lesson arrives after attention, not before it.
I want products to work that way too.
Do not explain the entire system before the person has a reason to care. Give them a meaningful action. Let the interface respond. Reveal the deeper layer when they encounter it naturally. Use short missions instead of a wall of instructions. Let difficulty expand curiosity instead of merely making the answer more obscure.
That thinking became part of DRYFTR, where the question was not “What is the highest-rated place nearby?” but “What kind of day are we building?” It shaped NetViz, where a technical network feed had to become understandable without hiding the truth underneath. It is inside the interactive runbooks, where someone can see what they do, what appears next and what the system evaluates behind the screen.
It is also how I use AI.
AI is very good at producing a bright beam. Ask a precise question and it can give you an answer almost immediately. That is powerful but speed can make weak thinking look finished.
I do not think the important human contribution is typing every character by hand. It is noticing the gap, framing the problem, choosing the constraints, deciding what should remain deterministic, judging what came back, testing the result and refusing to call an answer true because a model said it confidently.
Different models help me see different parts of the room. Claude and Claude Code are strong implementation partners. ChatGPT helps me develop the product, synthesize messy ideas, shape the experience and challenge the direction. Gemini gives me another research and verification angle. None of them gets the final vote by default.
The product, the data, the code and the person using it get the final vote.
That is why proof keeps showing up in the things I build. It is why generated content needs deterministic validation. It is why a recommendation should be able to show its evidence. It is why a working prototype matters more than a beautiful description of one.
My process is not complicated:
- I observe what is happening.
- I simplify the real problem.
- I make the idea interactive.
- I prove what happened.
- I save the result.
- Then I look for the part that can become reusable.
That last step matters. A useful solution should not die as a one-time fix if there is a system hiding inside it. A walkthrough can become a training engine. A content builder can become a local-first creator platform. A network visualization can become a way to explain an unfamiliar repository. Old projects can become a library of product DNA.
The world was never empty. Most of the time, the useful material was already there. It needed better light.
So that is the kind of work I want to keep doing.
Not building a brighter flashlight for the destination everyone already chose.
Building lanterns that help people notice what else is possible, understand what is happening and take the next step with more confidence.