devs

Attention over time

7-day rolling share of analyzed posts/comments mentioning this entity · 90 daily points ending 2026-10-14

Final complete day: 2026-10-14. Attention was 0.7% — this entity appeared in 6 of 883 analyzed posts/comments in the seven days ending that day (6 mentions).

Each point is a seven-day rolling window of complete UTC days; a point is comparable only when at least 100 analyzed posts or comments fall inside it. A day with no analyzed records counts as zero; missing coverage is marked and never shown as zero. The series ends at the latest complete analyzed day — it never extends into the current incomplete day. How attention is measured.

Recent mentions

1. 2026-10-14 08:12 UTCComment

   i'd make a separate one-page pitch for each group, same product but the headline and examples only talk to devs, or only to PMs, and send each one to 20ish people in that group. whichever page gets people asking what it costs without you bringing it up is your answer, signups alone mostly tell you who thinks it's cool

2. 2026-10-12 19:37 UTCComment

   Free tier and open source are the two things that will kill you here and everyone keeps recommending them like they're a gift. You put your tool on github and now the guy who'd have paid is reading your code instead, and six months later his intern reimplemented 70% of it badly and now thats the internal standard, congrats. Same with the forever free tier. Sentry, Datadog, whatever, devs will happily run your free plan in prod for 4 years and then act surprised when you change the pricing. The thing that actually works is being in the path of something they already do every day so the integration is like 2 lines and no meeting. If adopting your tool requires a slack channel and a security review, you already lost, they'll go build the bad version internally because that costs them nothing politically. Nobody ever got fired for writing their own bad internal tool. And yeah the whole "how do I reduce adoption cost" framing, its not a cost problem, its a "is this on fire for them right now" problem

3. 2026-10-12 12:09 UTCComment

   The fastest signal I know: stop asking "would you use this" and look for people already hacking around the problem. Search Reddit and forums for "I keep forgetting..." posts and see what they use today (Notes, Keep, emailing themselves). If they're duct-taping something, there's real pain. On the bring-your-own-API-key model: it narrows your audience to devs, who are the least likely to pay. I'd try a small hosted tier with a hard monthly cap, put a price on it early, and see if even 5-10 strangers convert. Free users saying it's great is nice, but a card on file is the only validation that really counts.

4. 2026-10-11 14:53 UTCComment

   Yes, and agencies are an underrated first door: they will not hire you for clean backend architecture, but they always have a client screaming for a landing page, a dashboard, or an integration by Friday. That is how most devs I know learned to ship: someone else's deadline with real money attached. Pitch one narrow offer, like rebuilding slow sites in ten days, instead of 'I do backend'. What is one end-to-end thing you could ship this week that an agency could resell tomorrow?

5. 2026-10-09 07:58 UTCComment

   >There’s not really a viable in-between. There is, sort of, which can be found in understanding the nature of each working product or prototype. Because the problems only start to show up when you treat them as something they aren't. So, the viable in-between isn't of a technical nature, it's a business strategy. The one-off prototype is quickly thrown together and never ever touched again, it just is what it is and unless it burns down your office it is per hardcoded definition good enough. No bug fixes, no new features, no nothing. But even before that prototype is built you've started working on your version 2, which is a completely separate codebase. You barely even reuse anything from that first prototype, because you treat that mess as absolutely toxic. It's full on quarantine to not have it pollute the new codebase by the devs lazily using what's sort of already working. So on a technical level I'm agreeing with you that there's no real in-between, at least not without unreasonable tech debt and unnecessary delays and complications; but on a business level I'm saying that it's not as black/white. The important thing is that your CTO is using their business competency to enforce this technical black/white approach, to free up the business to get the benefits of both one-off prototypes and properly architecturally sound and scalable systems. And that's the viable in-between. **That's how the concept of a quick and dirty MVP isn't dead.** Through business competency.