Building higher-touch AI products that are applicable across the entire customer base of an existing enterprise SaaS provider on release does feel impossible.
It's very obvious when you look at the AI companies that have 'exit-velocity' in this space that they are playing in that they are either one of the following:
1. Targeting a need within that org that's narrow enough to be MVP-able enough across a diverse customer base
2. Targeting IC work directly
As we add more complexity here, it's going to be a long, long slog to market - even with model advancements.
We recently released our On-call product, and as part of that, had to think a lot about redundancy and 'failing safety'.
Here's how we achieve it - and how we're thinking about it. Interested if any other examples of this exist in the wild - I'd love to know more about how eg: Datadog achieve this.
We recently released our On-call product, and as part of that, had to build a mobile app.
We'd noticed there's been some debate recently regarding React Native, and if you can build 'native tier' apps using it. We'd seen a lot of this but as part of an initial hackathon tried Explo / RN / Nativewind and were completely blown away by both the quality of app we could produce and the developer experience that let us do this quickly.
If anyone's in this space / thinking about making a technical decision here I couldn't recommend this stack strongly enough!
Snowflake as destination is very very easy to work with on fivetran. Fivetran didn't have S3 as destination till late 2022. So it literally forces you to use one of BQ, Snowflake, redshift as destination.
So fivetran CEO's defence is pretty stupid.
Were Prequel using RaabitMQ to stay cloud platform agnostic when spinning up new environments? Always wondered how companies that offer managed services on the customers cloud like this manage infrastructure in this regard. Do you maintain an environment on each cloud platform with a relatively standard configuration, or do you have a central cluster hosted in one cloud provider which the other deployments phone home to?
Low effort post on my part, but I sure won't be buying or taking any advice from this company that publicly advertises this kind of mess in such a "proud" manner. Not only that but it's like the SASS-equivalent of the recipe blog post meme.
This is what you get when you hire using leet code exercises and dump all your design thinking to "Senior" developers that have 1-3 years under their belt.
Having the type system this complicated is mostly for library builders, makes the developer experience of tools like tRPC, Zod and Prisma possible. An engineer writing business logic in TypeScript will probably never have to learn how to write (or even read tbh) complex TypeScript signatures, but benefit significantly from the solutions the type system complexity is a necessary precursor for.
I think it makes sense in the context of the poential of plain old SQL (and additions such as dbt) winning out vs Python or other general purpose programming solutions as the analytics workbench (although this is controversial, there's a school of thought that backs it).
Totally agree - in fact from the issues pages it seemed like there had been a conscious decision from Airbyte not to support a Terraform provider and instead build out Octavia, which as you say leaves a lot to be desired. Deploying Airbyte is still far too hard, I'd be happy to pay for an 'on prem' version like Gitlab where it's a bit more managed. I also think the failure modes for Airbyte on prem are too hard to debug in comparison to other data 'MDS' tools.
Switched to Fivetran after experiences with Airbyte, operating Airbyte was extremely tedious, even primetime connectors had bugs that I personally had to fix, we keep Airbyte around for the "long tail" of SaaS tools that Fivetran doesn't have a connector for but managing an Airbyte deployment in a stable manner for the long term was not easy.
It's very obvious when you look at the AI companies that have 'exit-velocity' in this space that they are playing in that they are either one of the following:
1. Targeting a need within that org that's narrow enough to be MVP-able enough across a diverse customer base
2. Targeting IC work directly
As we add more complexity here, it's going to be a long, long slog to market - even with model advancements.