How we built the wrong feature
In this technical retrospective (2014), @Jonovono shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Cloud & Mobile Era (2014–2019)
COMMUNITY SCORE 31 points
TOTAL DISCUSSIONS 4 comments
Everyone who builds anything needs to realize this: don't let your users dictate your features. They aren't inventors, they aren't designers, they aren't developers, they're just users. And they can lead you astray.
Don't let users send you problem reports in the form of unimplemented feature requests, if they do you need to retranslate them back into problem space before ingesting them. This is a special case of "satisficing". The amount of work that a user puts into figuring out what they "need" to solve their problem is often trivial, and insufficient compared to the amount of work that needs to actually go into feature development. More often than not users are just going to tell you the first idea that comes into their head on how to solve their problem. Sometimes that's fine, more often than not it's a mistake. And it's a much worse mistake to dump lots of implementation work into a feature that was designed based on a nanosecond of effort.
Take control of your own design, evaluate lots of options for solutions for problems, take the time and effort to figure out which ones are actually good, and then implement those. Don't become a marionette for user requests.
Been there, done that, got a T-shirt. The "talk to two" idea is the best one on the list. Find MULTIPLE people who want this product, get MULTIPLE use cases, and then build a tool that is abstract enough to cover a variety of use cases but solid enough to get the job done for them.
I can't tell you how much of my time has been wasted on toy features for clients that never came on board.