Ask HN: Resources to learn about early startups engineering decision?
5 comments
Just really learn to internalize "Off the shelf solution", "We can fix it later" and "Minimum viable" and you'll be fine (or, statistically probably not, but that's usually unrelated to technical decisionmaking).
Database schema: the minimum viable database schema that we can fix later
Product analytics: What off the shelf solution can we find to satisfy a minimum viable analytics setup
I've worked with countless engineers at startups that are addicted to building overly complex solutions in-house. They're just wasting time and money (aka runway). The thing many devs don't seem to internalize is that lots of startup development (outside of "hard" tech, where the tech _is_ the startup) is very very unsexy/unflashy. Configuring cheap SaaS products to satisfy your need as fast as possible. Anything that keeps you in business is good enough, and if you continue to exist you can fix it later. Literally everything other than your secret sauce should be answered by 1-3 of the above mentioned mantras.
Database schema: the minimum viable database schema that we can fix later
Product analytics: What off the shelf solution can we find to satisfy a minimum viable analytics setup
I've worked with countless engineers at startups that are addicted to building overly complex solutions in-house. They're just wasting time and money (aka runway). The thing many devs don't seem to internalize is that lots of startup development (outside of "hard" tech, where the tech _is_ the startup) is very very unsexy/unflashy. Configuring cheap SaaS products to satisfy your need as fast as possible. Anything that keeps you in business is good enough, and if you continue to exist you can fix it later. Literally everything other than your secret sauce should be answered by 1-3 of the above mentioned mantras.
I'm an engineer and talking from experience here.
1. keep the db schema simple. remember you are startup things change, so does the db schema so does your architecture.
2. One piece of advice from personal experience, Microservices usually don't work well for startups try building your solution as a modularized monolith.
3. always make decisions that are reversible (2 way door) and make sure coming back is also easy.
4. for any features you release have qualitative and quantitative metrics and more importantly guard rail metrics.
5. where ever you can use the an off the shelf solution like feature flags (launchdarkly), product analytics (amplitude) use them. These are solutions used by countless startups do not reinvent the wheel.
6. prioritize customer feedback, that is going to get you money and they are going to help make your product better. Instead of "failing fast" prioritize on "learning fast".
7. Be focussed on solving the problem don't romanticize the solution.
1. keep the db schema simple. remember you are startup things change, so does the db schema so does your architecture.
2. One piece of advice from personal experience, Microservices usually don't work well for startups try building your solution as a modularized monolith.
3. always make decisions that are reversible (2 way door) and make sure coming back is also easy.
4. for any features you release have qualitative and quantitative metrics and more importantly guard rail metrics.
5. where ever you can use the an off the shelf solution like feature flags (launchdarkly), product analytics (amplitude) use them. These are solutions used by countless startups do not reinvent the wheel.
6. prioritize customer feedback, that is going to get you money and they are going to help make your product better. Instead of "failing fast" prioritize on "learning fast".
7. Be focussed on solving the problem don't romanticize the solution.
Can you expand on some good guard rail metrics you've used/seen please?
The 2 metrics I've used in the past is
1. Bounce rate combined with Session length
- Bounce rate can be defined as % of users who leave only after viewing one or few pages. The reason at least I coupled bounce rate with session length is atleast in the app we work there are few personas that prefer to stay in one page for a long period of time and do some interactions. Bounce rate combined with Session length always give us a good picture are folks using the feature(s) as intended. One thing we did was set a baseline metric where we first measured session length on the app as well as per page basis, and after that we could build the bounce rate. Amplitude works well for this case
2. Churn Rate - number of users who stop using the app over a given period. This should be easy to do by querying db if you maintain some session duration information.
1. Bounce rate combined with Session length
- Bounce rate can be defined as % of users who leave only after viewing one or few pages. The reason at least I coupled bounce rate with session length is atleast in the app we work there are few personas that prefer to stay in one page for a long period of time and do some interactions. Bounce rate combined with Session length always give us a good picture are folks using the feature(s) as intended. One thing we did was set a baseline metric where we first measured session length on the app as well as per page basis, and after that we could build the bounce rate. Amplitude works well for this case
2. Churn Rate - number of users who stop using the app over a given period. This should be easy to do by querying db if you maintain some session duration information.
YAGNI
You aren't gonna need it (yet).
That and learn what minimally viable means like another poster said.
You aren't gonna need it (yet).
That and learn what minimally viable means like another poster said.
I am looking for something a scrappy team of 4 people pull together within 2 years of company inception. ie question like 1) what early day database schema looks like 2) what do we use for simple product analytics ...