Comment by tristor

Comment by tristor 2 months ago

3 replies

I would have liked to see a bit more of 5 Whys here. It seems like a consistent lesson that startups have to learn over and over is how to manage external dependencies, and particularly the dangers of having Google as a dependency. This is new Chrom(e|ium) behavior, and it has a real cost, both for this company and for users, which may or may not be worth the ROI, but this is what happens when you have a large scale external dependency: stuff moves without your knowledge, consent, or control.

Instead of Always. Be. Closing. it should be Always. Be. Mitigating. Dependencies. for startups.

suchintan 2 months ago

This is a great callout.

We had an internal discussion about how to manage dependencies effectively, and we made the decision accept the risk that comes with blindly relying on Chrome for now, instead of investing heavily in mitigating that risk today.

The main motivator was for us to continue moving fast, and accept that we have a few hard dependencies in our business.

The goal is to find product market fit, then allocate time to de-risk some of these hard dependencies. If we fail to find product market fit, this may not matter at all

  • tristor 2 months ago

    I think that's a fair strategy. Strong PMF generally overcomes weak execution, the challenge is that when you have hard dependencies on entities like Google or Apple it can easily become existential. Even if you choose to move forward with this dependency you should establish guard rails within your system to ensure you catch shifts faster that may be impactful and have a plan for mitigation. For instance, you should identify key points of integration and possible alternatives even if you choose not to migrate now, so that a future migration is better understood and can be discussed intelligently in the heat of the moment. Even internal documentation can assist as a mitigation for dependency risk.

    • suchintan 2 months ago

      Yeah exactly. One action item from this is that we need to add anomaly detection to our proxy usage metrics so we can catch this in 15 minutes instead of 6 hours :)