Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This touches on an underrated problem: whatever stack you choose today for your new product is what you'll be locked into for years if your product is successful.

It is almost inevitable that after a few years you'll be dependent on deprecated or abandoned libraries and frameworks.



> whatever stack you choose today for your new product is what you'll be locked into for years if your product is successful.

For for-profit projects, that's less of a problem than it might seem when stated that way. If your project is successful, the means of getting off the platform (or getting the owner to adapt it to your evolving needs, or doing so yourself, including acquiring any necessary permissions, or solving it some other way) are provided by that success.

(Heck, that's true if people understand the business case and reserve resources from the savings for projects that aren't for-profit but are internal cost saving measures, as well.)


Use clean/hexagonal architecture. Keep APIs at arm’s length.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: