Halfway through building ProductLog, I realized I was about to position it as the wrong product.
Not the wrong product technically. The code did what I wanted it to do. The wrong product strategically, the version of it I was about to launch would have competed in a market I didn't actually want to compete in, against incumbents who'd already won.
This is the story of how that almost happened and what saved it.
Two products in one codebase
ProductLog has, broadly, two halves.
The first is a community and discovery platform. Maker profiles, public product pages, updates, trending, leaderboards, followers. The mental model is Indie Hackers crossed with Product Hunt, with a build-in-public social layer on top.
The second is product-management tooling. Roadmaps. Feedback boards. Changelogs. The mental model here is Featurebase. Or Canny. Or Productlane. Tools that help makers run the back-of-house side of their product — collect feedback, ship public roadmaps, communicate changes.
I built both. I have one codebase that contains both. And I almost made a mistake about which one I was selling.
Why this matters
These are two different products. They look the same from the inside — same database, same auth, same user model — but they sell to different people, compete with different incumbents, and have different paths to revenue.
Community platforms are notoriously hard to monetize. The most successful ones (Reddit, Indie Hackers, Product Hunt) struggled with revenue for years. The network effects are powerful but the willingness-to-pay is low. Users come for free. Money comes from ads, featured listings, or eventual platform extraction, none of which fit a small indie operation.
Feedback tools, on the other hand, have clear willingness-to-pay. Makers will pay $20-50 a month for a good feedback board with a custom domain and embed widgets. Featurebase, Canny, and Productlane are all profitable businesses. The unit economics work.
So if I positioned ProductLog as a feedback tool, the path to revenue was clear. If I positioned it as a community platform, the path was unclear.
The trap
Here's where the trap forms. When founders see this comparison, the temptation is to say: "I'll do both."
That's what I was about to do.
I started writing the homepage copy as "a place for makers to build in public — plus the feedback and roadmap tools to manage your product." Two value propositions in one sentence. The kind of pitch that sounds comprehensive and tests well in your head.
It would have been a disaster.
A homepage that promises two things promises nothing. A visitor lands, reads "community platform plus feedback tooling," and asks "okay, but which one is for me?" The answer they get is "both!" The answer their brain hears is "neither."
Worse, the two audiences want different things. Indie makers looking for community don't want to be sold a feedback tool. SaaS founders shopping for a Featurebase alternative don't want to land on a "build in public" manifesto.
By trying to serve both, you serve neither.
Why I'm still building it this way
After I made the call to position ProductLog as a community platform first, I had to sit with a harder question. If the two-things-in-one approach is a trap, why am I still doing it? Why is everyone else's product cleanly separated, and mine isn't?
The honest answer: I'm building this because the way these tools are split today doesn't match how a maker actually works.
A maker's work lives across three different time horizons, and current tools cover one of them at a time.
There's the immediate, what I'm doing right now, what I just shipped, the tweet-sized "look at this." This is what X is good at. Fast, public, ephemeral. It scrolls away in a day and that's fine, that's the point.
There's the durable, the longer thinking. "Here's how I solved this problem." "Here's why I made this decision." These deserve to stay findable. Someone hitting the same problem six months from now should be able to find the answer. This is what blogs are for, and there's no good shortcut.
And there's the stateful, the things that have a status, a trajectory, an answer pending. "I found this bug." "This feature is in progress." "This is on the roadmap for Q3." These aren't moments and they aren't essays. They're entries in a system that has to keep track of where each thing stands. This is what feedback boards, changelogs, and roadmaps are for.
A maker working seriously needs all three. And right now, they need three different tools to do it.
X covers the immediate. A blog covers the durable. Featurebase or Canny or Linear covers the stateful. None of them talk to each other. Your product page on Product Hunt knows nothing about the bug you tracked in Featurebase, the blog post you wrote about solving it, or the tweet announcing the fix.
That's the gap I'm trying to close. Not because Featurebase is wrong to be only a feedback tool, they're correct for the audience they serve, which is companies that want a clean, focused product surface. They're trap-free because they're not pretending to be more than they are.
But I'm not a company. I'm a maker. And as a maker, I don't want to live in three apps. I want one place where my product, my updates, my blog posts, my roadmap, and my bug list all sit next to each other, telling a single coherent story about what I'm building and where it's going.
And if I'm building that for myself, the showcase layer comes almost for free. If a platform already holds a maker's full build-in-public picture, the immediate, the durable, the stateful, then turning it into a discovery surface is the obvious next step. "Look at what these indie hackers are building" is a much stronger pitch when what you're showing is a complete picture, not a launch-day screenshot.
That's the bet. Not a feedback tool with a community bolted on. Not a discovery site with feedback bolted on. One place where everything an indie hacker is looking for lives in the same product, around the same maker, in the same story.
This might be wrong. It might turn out that splitting the three time horizons across three tools is the right design, and combining them creates more confusion than coherence. I'll find out by using it. But I had to acknowledge what I was actually betting on, instead of pretending the unification was accidental.
The other trap
There's also a structural reason ProductLog can't compete as a feedback tool today, which I figured out only after I'd already decided to try.
Featurebase, Canny, and Productlane all work because the maker can embed feedback collection on their own site, or use a custom subdomain — feedback.yourproduct.com. The maker's customers never have to leave the maker's brand. The feedback tool is invisible. That's the whole point.
ProductLog doesn't have embed widgets or custom subdomains yet. Feedback boards live on productlog.net/products/yourproduct/feedback. Which means asking a customer to leave the maker's site, land on ProductLog, see ProductLog's branding, and submit feedback there.
No maker wants this. Customers don't want it either, they get confused. "What's ProductLog? Why am I here?"
So ProductLog can't actually be sold as a feedback tool until those features exist. The capability is there technically. The market position isn't.
The decision
I made two calls.
First: ProductLog is a community and discovery platform. That's the headline. The feedback and roadmap tools are supporting features — they make the platform more useful once you're inside, but they're not the reason you come.
Second: I'm not trying to monetize the feedback tool side, at least not now. Maybe ever. The point of having those features isn't revenue; it's that a maker's product page on ProductLog should be a complete picture — what they're building, where it's going, what users are saying. Feedback and roadmaps make the product page richer. They serve the community-platform proposition, not a separate one.
This means I'm choosing the harder revenue path. Community platforms are hard. I know this. But trying to be two things would have been worse than choosing the hard thing.
What this changes about my plan
The decision reshapes what the next few months look like.
I'm spending my 2-3 hours a day in two modes: building ProductLog, and using ProductLog for my own other projects. The using-it part isn't a side activity, it's the way the platform gets stress-tested before I invite anyone else in. Every one of my projects gets its product page, its updates, its roadmap, and its feedback board on ProductLog. I'm the first user, the first maker, and the first one to find every bug.
What I'm not doing is racing to ship embed widgets and custom subdomains so I can compete with Featurebase. Those features will probably come eventually, because they're useful even within the community-platform framing — but they're not the priority. The priority is making ProductLog work well enough as a community platform that other makers want to be on it.
That's a longer road. I know.
Comments
No comments yet. Be the first to comment!