3 ms·
Pick one stack and don't think about the stack when launching a product. I see a lot of people get an idea and then start exploring a new framework or library "
by Jugurtha 5y ago
Pick one stack and don't think about the stack when launching a product. I see a lot of people get an idea and then start exploring a new framework or library "to be more efficient".
Do you want to ship something or learn a framework ? Nothing wrong with either, but you must know the answer. Nothing is wring with learning a framework by building something either, but here you're using the product to learn a framework/stack, and not using the framework/stack to build the product. Grosso modo: don't lie to yourself about what you're doing.
Strip everything that does not invalidate your idea. Spend zero time on password reset flows or automated emails. Do things manually. Just get the email address and get into a conversation.
Doing more projects to gain skills so building the prototype is not the bottleneck because you're efficient. Do things better.
Doing fewer projects by validating with the minimal thing you can ship so building the prototype is not the bottleneck because you're effective. Do better things. Validate beforehand. Talk with people earlier. All these don't require you to build things.
- prohobo 5y agoI'd say research different stacks before you start the prototype, pick the best one from your initial perspective, and if it's not working then branch to an alternative and see if it's better for your use case. If you don't do this, then you might end up ramming a square peg through a round hole and will need to rewrite later. Basically, stick to your core competencies, but don't be afraid to try new things that will clearly (hopefully) improve your product. Fail hard and fast instead of dragging it out 6 months :) This isn't about learning a framework at the expense of the product, it's about building something new that you might not have experience creating solutions for yet.