Then I put it in front of actual photographers, which is who this thing was built for, and it did fine. It sold and people use it, and by most reasonable measures it was a success.
It also underperformed what the enthusiasm had predicted. By a lot. And working out why has been pretty enlightening.
Two Different Evaluations
Builders assess craft. It's what we do and mostly we can't help it.
Show a developer a tool and they'll work out how it was made and whether they'd have approached it the same way. That's a real evaluation and it's often generous, because we know what it costs to make something work. It's hard.
None of it tells you whether anybody wants the thing though.
Photographers evaluated it very differently. They asked whether it solved a problem they had already, and plenty of them decided it didn't quite do that for them, so they said nothing at all and went back to taking photographs.
The trouble with silence is that it reads like nothing is happening, when it's usually the clearest answer you're probably going to get.
I Did Test With Photographers
The part that stings is that I wasn't careless about this at all. I even ran a beta round with actual photographers before launching, because I already knew better than to validate a photography tool with developers.
The feedback was good, solid They understood it straight away and many of the beta testers had suggestions I ended up using in the app.
But look at who volunteers for a beta.
The photographers who put their hand up for an unreleased tool from someone they follow online are, almost by definition, more technical than the median photographer.
They're comfortable with beta software. They enjoy trying new things. Many of them read this blog (hello!)
I had assembled a group that was nominally my target audience and functionally a slightly softer version of the same room.
So you can do the right thing, ask the right category of person, and still end up with a biased sample, because willingness to be asked and beta test something is itself a filter.
The photographers who would have told me something useful were the ones who'd never volunteer for a beta and had no idea I even existed.
The Loop
Here's what happens...
- You build for indie hackers, because being an indie hacker is the problem you have closest to hand.
- You launch where indie hackers gather, because that's where you already stand.
- You collect feedback from indie hackers, because they respond fastest and understand what you made.
Every signal you receive originates in the same room, and then you mistake the room for a market.
Each of those steps is individually sensible, which is what makes the whole thing rather hard to see. Nobody consciously decides to build inside an echo chamber.
You just follow three reasonable instincts and they close the circle behind you.
What took me longest to notice is that the room hands out false positives even for products aimed outside it. That tool was never built for developers.
They liked it anyway, for reasons that had nothing to do with whether anybody would actually buy it.
Encouragement Is Free
An upvote costs nothing, and neither does a supportive reply. "Congrats on shipping, this looks great" is a social gesture between people who understand how hard shipping is (and it still matters, always will). The thing is, it arrives in volume from people who will probably never give you money.
Meanwhile the people who actually want something tend to be quiet. They find the thing and buy it and use it, and you hear from them only if it breaks.
Which means the loud feedback is arriving from people who won't buy, and the people who will are saying nothing. That's the wrong way round.
That Audience Is Also Hard To Sell To
Even setting the signal problem aside, developers are a difficult market for a solo builder.
They're skeptical buyers who are immune to most marketing, pressed for time, and permanently comparing your product against the version they could build themselves. I know, I do it too!
Every purchase decision runs through a build-versus-buy filter that most other audiences don't have.
Datadog's own annual filing puts their sales and marketing organization at roughly 3,000 people. A meaningful chunk of that exists to convince engineers that buying beats building, at enterprise scale, with enterprise budgets.
You have none of that. You got a landing page.
LaunchDarkly say outright that some of their best customers built an internal version first and only bought later, once maintaining it stopped being worth the trouble.
That's the good outcome.
The usual one is that somebody builds it over a weekend and you never hear from them again.
Add a small population and high price sensitivity on top of that, plus the fact that a good share of the room is also trying to sell you something, and it's close to the worst market a one-person operation could pick, really.
What Has Actually Paid
I've been running photography properties since 2012 and developer-facing things alongside them for years.
The photography side has always out-earned the dev work. Not marginally, and not because those products were better built. Some of my dev tools are better software than anything I've made for photographers.
The audience is just different.
Photographers don't know what MRR means. Most have never opened Product Hunt. They don't care what my stack is, they won't rebuild my tool on a Sunday afternoon, and when something solves a real problem they pay for it and stay for years.
There's no cleverness in any of that.
It's a market where the product gets judged on whether it works rather than on how it was made.
And I love photography for that.
Why That Audience Behaves Differently
"Sell to non-technical people" sounds like lazy advice until you look at what actually changes.
- They can't build it themselves, so the build-versus-buy filter never runs. The comparison in their head is between having the problem and not having it, which is a much easier comparison to win.
- They evaluate outcomes rather than implementations. Nobody has ever asked me what a photography tool was written in. They ask whether it does the thing, and if it does they stop asking questions.
- They're not saturated. A photographer might buy two or three pieces of software a year and think about it properly each time. A developer is drowning in tools, most of them free, several of them better funded than yours.
- And they stay. Churn on the photography side has always been lower than anything I've run for a technical audience, and I don't think that's about product quality. Developers switch tools for fun, it's practically a hobby. Photographers find something that works and keep using it until it stops.
What The Room Is Actually Good For
Peer feedback is valuable when you point it at the right question, and I don't want to overcorrect.
Builders are excellent at telling you whether something is well made. That's super valuable.
They'll spot the edge case you missed, notice that your error handling is thin, and tell you honestly when your onboarding is confusing because they've built onboarding themselves and know where it goes wrong.
They're also good at telling you whether your explanation lands.
If another developer reads your landing page and can't work out what the product does, that's a real problem and you should fix it.
What they cannot do is tell you whether anyone wants it.
They aren't being dishonest about it. They just aren't the person with the problem, and enthusiasm about a well-executed solution is a different feeling from needing something.
The useful move is to keep the relationship and change the question. Ask peers about the craft and customers about the need, and stop expecting either group to answer for the other.
I'm Still In The Room
I haven't taken my own advice, for the record.
I still build developer tools. DailyTips.dev is aimed squarely at developers, Preflight is a CLI tool for people who ship websites, and AutoChangelog was built specifically for dev teams. I like building those things and I'm going to keep doing it.
So take this as an observation rather than a purity argument.
It's about which side of my portfolio has paid the bills for 15+ years, made by somebody who keeps working both sides anyway.
What changed is that I read the feedback differently now.
Are You In The Room
A few questions that have helped me work out where I actually am.
- Where did the last ten signups come from? If most trace back to one community, a launch platform, or your own following, that's the room.
- Could a customer rebuild this over a weekend? If yes, a decent share of them will try.
- Do the people giving you feedback have something of their own to sell?
- How did your testers find out about the test? If they volunteered, they're already unusual.
- Would somebody outside tech understand what the product does from one sentence?
If the explanation needs context only your peers have, your addressable market is roughly the size of the room you're standing in.
Getting Out Is Slow
The honest answer takes years rather than a launch cycle.
You pick a domain you know something about that isn't software.
Something you'd read about anyway, where you understand the problems from the inside because you've had them. For me that was photography, and it took a long time before it earned anything.
Then you build distribution there, which is the boring part no one wants to hear about. My photography audience took over 5 years to assemble and most of that time produced very little.
There's a smaller fix you can make today, though.
When peers respond enthusiastically to something you've made, take it as information about the craft. It's useful information and it's often accurate.
Just don't file it under demand.
And when you do go and test with your actual audience, go looking for the people who wouldn't have volunteered.
Ask the person who's been shooting for twenty years and has never joined a Discord. Their indifference is worth more than a dozen enthusiastic beta testers who found you through a newsletter.
The Room Is Pleasant
None of this is an argument against the community.
I've learned a great deal from other builders, this blog exists partly because of them, and the encouragement has kept me going through stretches where nothing was working.
The people cheering you on and the people who'll pay you are usually two different groups though, and I spent a while confusing them.
It was a soft lesson, as these go. Nobody was unkind, nothing broke. A product I still like ended up in front of fewer people than I'd been led to expect. This is fine.
The developers were in the room. Most photographers were somewhere else entirely, taking photographs, not thinking about me at all.