Someone smart left me a comment months ago: the killer feature isn't the citations, it's page-level citations. NotebookLM hands you a chunk of a PD...
For further actions, you may consider blocking this person and/or reporting abuse
Proving a feature is a bad idea is a huge time-saver, especially when it comes to page-level rendering or complex data fetching where the technical debt would outweigh the user value. It reminds me of the classic trap of over-engineering a solution for a niche use case instead of shipping the core MVP. I actually had to pivot our initial architecture for a similar reason when putting together our Next.js and Supabase SaaS starter, realizing that keeping the data layer simple was way more valuable than building a custom page-level caching system. It is exactly why we kept the boilerplate at PubliFlow so lean, focusing on shipping fast rather than adding complex features that might not survive contact with real users. How did your team handle the transition after you killed that feature, and did it free up bandwidth for something that actually moved the needle?
ha, "team" is just me — so the transition was basically me closing 30 browser tabs and exhaling. but honestly the passage-level version was already 90% there while i was chasing pages, so shipping it took a couple days, not a rewrite. the real thing it freed up wasn't hours, it was headspace — i stopped treating "someday page numbers" as a debt hanging over every decision. wrote the full autopsy into the roadmap and let it go. that lean-boilerplate instinct you're describing is exactly it: the discipline isn't building fast, it's not building the thing nobody asked for yet.
Reclaiming headspace over raw hours is the ultimate ROI, especially when you are flying solo and carrying all the cognitive load. Dropping that mental debt probably doubled your actual coding velocity since you no longer have to context-switch out of guilt. Did writing the autopsy help you formalize a checklist for evaluating future features, or was it mostly just for your own closure?
started as closure, honestly. but one line of it stuck and became a rule i actually use now: before i build anything, "can i really get the data, and did anyone ask for this yet?" the page-number thing failed both — the data wasn't in the DOM, and nobody had asked, i just wanted it to exist. it's not a fancy checklist, more a gut-check i can't unsee anymore. that's the sneaky part of writing the autopsy down — you think you're closing a door and you end up with a filter.
That two-part gut check is brilliant because it attacks both technical feasibility and actual user demand before a single line of code is written. Writing things down really does force that clarity, turning a fleeting realization into a permanent mental filter for future work. Do you find yourself applying this same data and demand check to refactoring existing features, or strictly to new builds?
i use it on refactors too, but the second question flips. for a new build it's "did anyone ask for this." for a refactor it's "is anything actually broken, or am i just bored with the code." that one catches me way more often — the itch to rewrite something that works fine because a cleaner version lives in my head. so refactors get a third question stapled on: "will a user ever feel this change." if the answer's no, it's not a refactor, it's me procrastinating with extra steps. honestly the demand check is even more useful there — nobody files a bug asking you to make your code prettier.