mcharawi

anyone have an archive link for this?

I used https://www.flow.club/ which i found very helpful, they do small groups rather than one on one, and you can sign up ahead of time or join spontaneously

This article didn't really say all too much, essentialy you can't differentiate your product with prompts alone, and you need deeper integrations with workflows, ok thats pretty clear - what else?

Changed the title only because i want to highlight the live stream of the flight today!

I'm also skeptical of people talking on behalf of others in situations like this. I'd like to hear what the migrant workers think

No congratulations is necessary the Laudspeaker project (https://github.com/laudspeaker/laudspeaker) is doing perfectly fine.

$75/mo is not particularly expensive, Braze's starter plan is close to $35k/year

Hey, happy to clear up the confusion! The software is similar to a CRM in that we message users/customers, though we don’t track things like the stage of a sales deal.

Our software and competitors like Braze are typically used in situations where you can’t have a personal connection, but still need to message users, often when they complete specific actions in your application, or if you want to send one-off promotions for example. E-commerce brands or a banking app might use us for example.

We do support replacement variables like you mentioned and are adding integrations actively.

If you're interested in an enterprise plan, we help you set up and scale self-hosting as part of the support contract for as long as you need. We have one-click infra-as-code to get you set up on multiple cloud providers with minimal devops intervention.

If you want to self host for free, the easiest way would be to run our docker compose on a compute instance-we're in the process of updating our docs for self hosting and I can email you with more info if you'd like.

We have support for twilio natively since that's one of the popular options, but we also support webhooks as a channel, so if your Asterisk server has an HTTP endpoint that can trigger messages it would be compatible.

It was fun writing this article, not only because it reminded me of problem sets from college, but also to see the potential of no-code tools to be just as powerful as a conventional programming language. Proving another tool, like Zapier for example, can simulate a finite automata, can be left an exercise for the reader.

I suspect some are much closer to simulating Turing machines than others. In theory, no automata can simulate a Turing machine unless it has access to unbounded (infinite) memory, which can't actually happen in the real world. If there's branching, for loops, and some proxy for memory like reusable registers, it can certainly approach a Turing machine. So maybe Zapier is? I don't recall many tools having a proxy for reusable memory though.

Hey, cofounder of laudspeaker here. If you want to try it out, you can deploy to render without having to really do any heavy lifting. We are just getting started with respect to the business model so we’re open to feedback on pricing. Email me at mahamad at laudspeaker dot com and we can chat!

Hey, cofounder of Laudspeaker here. At a high level, there are two main problems to solve for when it comes to scaling this type of system. One is the ability of your infrastructure to handle resource intensive customer requests (sending 10 million emails) that are instantiated at arbitrary unpredictable times—this sort of work is usually best handled using job queues and job processing threads that are horizontally scalable. The second is the channel specific failure modes that are common at higher message sending volumes, for example IP blacklisting by spam filters for email, or sending the same notifications repeatedly when dealing with mobile push. We’ve set up our architecture to tackle the first problem and are currently performing stress testing to find and fix any bottlenecks there; with respect to the second type of problem, we are actively experimenting with ways to mitigate these failure modes as our product matures.

thanks!

A couple of reasons, first of all we're passionate about open source and we've been seeing the rise of an open source SaaS ecosystem, companies like PostHog, Mattermost etc. We think the more companies here the better, there is a lower chance of vendor lock in, data transfer costs etc if you use an open source solution, and marketing automation software is no different. Secondly and we alluded to this, an omnichannel messaging platform needs a lot of channels, and integrations to be useful to the market, and it makes sense for other contributers to be able to add customize as needed - we are looking into how to make this easier for people to do. Thirdly customer messaging and marketing automation in general is getting more complex, and often touches developers at larger companies, we think most of the solutions out there today don't treat them as first class customers - we are looking to make their experience better as well. We have a few features in the works, like complex journey testing (where you can simulate events, time travel, etc) and wanted to make the self hosting aspect easy as well.

Do you think the 'professionals' were exploited?

Hey, thanks for your comment-you're right there aren't too many details on the protocol changes we made in part because we will follow up on that in another post. This blog post was getting too long as it is and we wanted to focus more on the need to simulate and test. Your comments on the hacker news post you link too actually partially served to inspire us!

At the moment we offer both options. We offer our own network with a pricing plan similar to massive.io (though 10c per gb vs 25c) Our licensing is cheaper but requires large volumes.