4 ms·

I missed the first time this post got on HN front page, but my main takeway is same comment from jiofih (https://news.ycombinator.com/item?id=25630241 https://n

I missed the first time this post got on HN front page, but my main takeway is same comment from jiofih (https://news.ycombinator.com/item?id=25630241 https://news.ycombinator.com/item?id=25630241): >> the project needed to be (almost) re-created from scratch >> the build system, Docker/docker-compose, continuous integration, authentication, internationalization, etc >> created a wiki, migrated the code to a monorepo, created/cleaned up the backlog, etc. >> created a story map, devised a roadmap, and clarified the scope of the MVP >> replaced Angular Material by Tailwind, created our own theme, refactored the data model > This is why. A year went by and no product work was done, none of this was necessary. The very first thing that should have been built is a MVP, that main screen that was only tackled 9 months in. Strongly recommend studying “The Lean Startup” and learning how to be stoic about tech. That’s how people deliver working products in three months. in addition to that, the author mentions, still in a Startup/MVP context: "The focus on took care of release automation, created the production infrastructure (switched to Kubernetes)", "The NoSQL database was making us lose a ton of time". None of this should matter at MVP stage!

jamil7 5y ago
I completely agree and had the same thoughts reading that. K8s for an MVP?! Throw that thing on a PaaS and forget about ops altogether until it's too expensive. I think it's really good advice for developers wanting to launch their own project to do at least one or two tiny projects first and try to release and sell them. It makes you much more aggressive with cutting fat at an early stage. It was an enjoyable read though and I imagine the author learned a whole lot regardless of the outcome.
fellowniusmonk 5y ago
There's a reason so many successful startups launched with some form of rails stack. Less time making decisions means more time to build customer value prop/interactions. An MVP for a web sass should be "core UI/UX value prop" for the main selling point (s) and what I call "marketing brutalism" for the rest. With the most boring and reduced use cases you can convince everyone else involved to agree to.
adampk 5y ago
It seems like the author was hit with a terrible case of bike shedding that lasted 2 years. https://thedecisionlab.com/biases/bikeshedding https://thedecisionlab.com/biases/bikeshedding Instead of tackling the hard problem (creating a "meeting screen" that actually delivers end user-value) the author tackled the easy problem (setting up infrastructure and documentation). The illusion of progress is hard to to give up.
- toss1 5y ago
  Yup, the distinction between keeping busy and making progress can be subtle or blatant, but it is critical.
  - abrookewood 5y ago
    It's not just keeping busy though ..., it's trying to avoid all of these shiny things that seem so important.

jamil7 5y ago

I completely agree and had the same thoughts reading that. K8s for an MVP?! Throw that thing on a PaaS and forget about ops altogether until it's too expensive. I think it's really good advice for developers wanting to launch their own project to do at least one or two tiny projects first and try to release and sell them. It makes you much more aggressive with cutting fat at an early stage. It was an enjoyable read though and I imagine the author learned a whole lot regardless of the outcome.

fellowniusmonk 5y ago

There's a reason so many successful startups launched with some form of rails stack. Less time making decisions means more time to build customer value prop/interactions. An MVP for a web sass should be "core UI/UX value prop" for the main selling point (s) and what I call "marketing brutalism" for the rest. With the most boring and reduced use cases you can convince everyone else involved to agree to.

adampk 5y ago

It seems like the author was hit with a terrible case of bike shedding that lasted 2 years. https://thedecisionlab.com/biases/bikeshedding https://thedecisionlab.com/biases/bikeshedding Instead of tackling the hard problem (creating a "meeting screen" that actually delivers end user-value) the author tackled the easy problem (setting up infrastructure and documentation). The illusion of progress is hard to to give up.

toss1 5y ago
Yup, the distinction between keeping busy and making progress can be subtle or blatant, but it is critical.
- abrookewood 5y ago
  It's not just keeping busy though ..., it's trying to avoid all of these shiny things that seem so important.