5 ms·

The thing is if a developer whose core task is not to be build these services can build it. Not just build it, build it robustly, I am guessing that threshold f

The thing is if a developer whose core task is not to be build these services can build it. Not just build it, build it robustly, I am guessing that threshold for people to start replicating your services is not that high. In that case, I would question whether is a product or a feature. Because the threshold to build something like this is low, your focus would be more on customer acquisition. You might even acquire alot of customer and tell me you have traction, but I would question what true value it really adds and then I would question long term viability of this company. On a side note, I have lately started seeing various companies graduating from YC that make me question whether they are product or feature. Not sure what the strategy behind them is. Either they end up going on product hunt, get a decent upvotes and then kind of disappear or are in space that slowly starts seeing other people replicate that. In devtool space, I have seen YC invest in companies that pretty much do the same thing. In my opinion, it is not fair for the operators of a startup if you have a backer that backs your competitor too as it dilutes your orgs value.

tasn 5y ago
Developers can build things, this is what we all do. The question is not can we do it, but rather should we do it. Developer time and focus is a scarce resource, and you want to invest it in moving the needle for you business, not reinventing the wheel. Especially when the wheel is actually harder than it first seems. I can't attest to the YC investment strategy or the whole "product vs feature" trend you are witnessing. Though I think what you are seeing is more of a trend in the industry towards not reinventing the wheel and using external services for many things (e.g. Auth0) rather than a trend led by YC/VCs.
- debarshri 5y ago
  For a startup and smaller orgs whose real goal is to survive, yes you are right resources are scarce and they shouldn't invest their time and effort on that front. But I think beyond that it is, if you go to larger orgs, if you have engineers who can't write services/client implementations like this. Then you have made bad hires. Don't get me wrong, it is my opinion that you need more defensibility in the product. I do not think it is re-inventing the wheel, you are abstracting the wheel for me, because now I have to implement your client. If you take a step back and objectively look at it, your product is service-of-a-service, which I think is a problematic approach. On your comparison with Auth0, it is very naive to generalise that argument. You have to look at them in isolation. At the time, when Auth0 came into existance, state of security was bad. In general, multi-factor authentication, machine-to-machine authentication, implementing oauth/oauth2 correctly was a really big pain in the industry. I can actually bet you that only a handful of engineer even today can do it right and cost of doing it wrong is much higher.

tasn 5y ago

Developers can build things, this is what we all do. The question is not can we do it, but rather should we do it. Developer time and focus is a scarce resource, and you want to invest it in moving the needle for you business, not reinventing the wheel. Especially when the wheel is actually harder than it first seems. I can't attest to the YC investment strategy or the whole "product vs feature" trend you are witnessing. Though I think what you are seeing is more of a trend in the industry towards not reinventing the wheel and using external services for many things (e.g. Auth0) rather than a trend led by YC/VCs.

debarshri 5y ago
For a startup and smaller orgs whose real goal is to survive, yes you are right resources are scarce and they shouldn't invest their time and effort on that front. But I think beyond that it is, if you go to larger orgs, if you have engineers who can't write services/client implementations like this. Then you have made bad hires. Don't get me wrong, it is my opinion that you need more defensibility in the product. I do not think it is re-inventing the wheel, you are abstracting the wheel for me, because now I have to implement your client. If you take a step back and objectively look at it, your product is service-of-a-service, which I think is a problematic approach. On your comparison with Auth0, it is very naive to generalise that argument. You have to look at them in isolation. At the time, when Auth0 came into existance, state of security was bad. In general, multi-factor authentication, machine-to-machine authentication, implementing oauth/oauth2 correctly was a really big pain in the industry. I can actually bet you that only a handful of engineer even today can do it right and cost of doing it wrong is much higher.