4 ms·

> You'd also be amazed at how long it takes to sign a contract I would not ;) > less eng-focused companies that would pay Actually, our experience has been t

by andrewyates2020 5y ago

> You'd also be amazed at how long it takes to sign a contract I would not ;) > less eng-focused companies that would pay Actually, our experience has been the opposite. The more sophisticated the engineering team, the more they recognize how big of a pain unified search ranking is to build and maintain, and the more they appreciate what we offer. On the forever "model-bakeoff": our approach is to include all existing models as features into an omni-model. If you are experienced in ML ops, you should be cringing, but we pull it off because from a customer development standpoint, we never want to be competing with some other new technique. Instead, we want to have a big ball of systems and progress is always "add more stuff." Then, the business and product teams can focus on how they want their product to work versus technical details of specific recommendation systems.

splonk 5y ago
>> You'd also be amazed at how long it takes to sign a contract > I would not ;) Ha, yeah, that was unclear. My comment was targeted more towards the general HN audience, because _I_ was pretty amazed when I got into that business. "Wait, so you've built the integration, you've built the metrics, you've run A/B tests at various levels for months and months that show beyond a shadow of a doubt that you'll make more money, and you don't want to sign...why?" >> less eng-focused companies that would pay > Actually, our experience has been the opposite. The more sophisticated the engineering team, the more they recognize how big of a pain unified search ranking is to build and maintain, and the more they appreciate what we offer. I see now from the other comments that you're targeting a higher point in the market than I originally thought. Still somewhat surprised that companies at that level would buy rather than build, but I suppose my view of the space is biased since I was only working at places that would want to build that in-house. > our approach is to include all existing models as features into an omni-model Makes sense to me if you're trying to be a generalized solution. I assume there's no crossover between any of your customers and you have to build a unique model for each of them?
- andrewyates2020 5y ago
  > buy rather than build Candidly, this is our biggest challenge. If we can surmount this, we'll be huge. This is also why care so much about "upmarket brand". Decisions aren't made by numbers alone. We need to show that we're the smarter way to grow faster because other top companies are doing it. This is a big bet. Is there a threshold for engineer TAC in search, discovery, and ads? $1M? 2? More? Hire a dozen? One hundred? I've seen these numbers. They happen because the potential value is there and the VC funding is there, but I haven't always seen the delivered engineering results. Us? We've been there, done that. We'd like to focus on delivering the results, and we know from experience that's going to happen better from the outside. > no crossover between any of your customers The model architecture and infra are the same, but the literal weights in memory are totally independent. Most of the heavy customization is in allocation rules and blender, and we have a DSL for that. https://github.com/promotedai/schema/blob/main/proto/delivery/blender.proto https://github.com/promotedai/schema/blob/main/proto/deliver...

splonk 5y ago

>> You'd also be amazed at how long it takes to sign a contract > I would not ;) Ha, yeah, that was unclear. My comment was targeted more towards the general HN audience, because _I_ was pretty amazed when I got into that business. "Wait, so you've built the integration, you've built the metrics, you've run A/B tests at various levels for months and months that show beyond a shadow of a doubt that you'll make more money, and you don't want to sign...why?" >> less eng-focused companies that would pay > Actually, our experience has been the opposite. The more sophisticated the engineering team, the more they recognize how big of a pain unified search ranking is to build and maintain, and the more they appreciate what we offer. I see now from the other comments that you're targeting a higher point in the market than I originally thought. Still somewhat surprised that companies at that level would buy rather than build, but I suppose my view of the space is biased since I was only working at places that would want to build that in-house. > our approach is to include all existing models as features into an omni-model Makes sense to me if you're trying to be a generalized solution. I assume there's no crossover between any of your customers and you have to build a unique model for each of them?

andrewyates2020 5y ago
> buy rather than build Candidly, this is our biggest challenge. If we can surmount this, we'll be huge. This is also why care so much about "upmarket brand". Decisions aren't made by numbers alone. We need to show that we're the smarter way to grow faster because other top companies are doing it. This is a big bet. Is there a threshold for engineer TAC in search, discovery, and ads? $1M? 2? More? Hire a dozen? One hundred? I've seen these numbers. They happen because the potential value is there and the VC funding is there, but I haven't always seen the delivered engineering results. Us? We've been there, done that. We'd like to focus on delivering the results, and we know from experience that's going to happen better from the outside. > no crossover between any of your customers The model architecture and infra are the same, but the literal weights in memory are totally independent. Most of the heavy customization is in allocation rules and blender, and we have a DSL for that. https://github.com/promotedai/schema/blob/main/proto/delivery/blender.proto https://github.com/promotedai/schema/blob/main/proto/deliver...