sessy

There is a simpler preparedness framework. It was postulated by Isaac Asimov. https://en.wikipedia.org/wiki/Three_Laws_of_Robotics

Probably time to bring this up again: The internet is an SEO landfill. https://news.ycombinator.com/item?id=20256764

May be they deserve a Toohey Award: https://tooheys.org/

Comparable AWS Version: https://aws.amazon.com/secrets-manager/

Pricing: AWS: $0.40 per secret per month. GCP: $0.06 per active secret version per regional replica per month.

i don't understand the GCP pricing correctly. Can someone shine a light here ...

Unlike English, the Sanskrit words do not change over time. Because in Sanskrit what you speak is what you write and what you write is what you speak.

Just wondering: Why not simply share your https://cv.me/ link (or any similar) instead of a link to your resume document. Makes it easier for HR to scan.

It's a recurring theme: Media outlets publish whatever they 'want' to believe with little due diligence and the product makers have to scramble to put up clarifiers.

WE are heavy users of AWS. SQS is the only service where we have had zero downtime. The only downside we have about SQS is you can pull out only 10 messages at a time (without batching). You can have parallel readers but they result in some duplicates. There is SQS FIFO but it is throttled.

TLDR: The huge bill was a result of an improper way the application was coded. They contacted Google/Firebase who were gracious enough to waive off the bill.

1. Be fair to your company. They are paying you to make their product succeed. Imagine a future situation where you are running a succesful company. Would you want your employees taking your money while working on their own pet projects?

2. An hour or two every day and code marathons on weekends can get your a basic version of product out in a few months.

3. Never give in to temptation to steal office hours to work on your project.

Just about a decade ago Microsoft faced similar charges for bundling IE with Windows OS. By the time the dust settled on all litigations, the competition was decimated or attenuated to stay in business.

“All plans include all features.”

We arrived at this after many years building multiple products. In all products we built we have just 3-4 plans. All features are included in all plans (including the trial plan). Only the usage amount differs from plan to plan. This makes it so easy to explain to end customers and leaves your engineering team with valuable time to deal with improving product. Further the number of billing related support requests decrease drastically. Your support staff also need less training.

The advantages are many to keep billing simple. This has been our experience. YMMV.

What i like is how simple and easy it is to read the documentation :)

Hey, thanks for the points. Will be sure to factor these in.

Could you write to [email protected] with a screenshot. Im curious to look into whats happening here. Thanks.

A valid business email is one where you should be able to receive and send mails. If you have a 'catch all' email id, the system does not accept that.

Having said that i must say our algorithm is deliberately a bit aggressive (so as to prevent spam).

Your email could very well be a false positive. Could you write to [email protected] from the business email in question. I'll be happy to look into it and whitelist it.

SESS is tightly wired to use SES (AWS). We do a bunch of algorithmic checks to validate email/domain validity plus assessing the risk-factor of uploaded email list. If you have a clean list deliverability is closer to 100%.

Edit: Thanks for the note. I will make a mention of the deliverability on the site.

Hi, im one of the engineers that built SESS.

We knew we could become a potential spam magnet. Like ive been mentioning in other comments here, we have an algorithm that does checks at multiple levels before a campaign is sent. If the algorithm deems the list as risky it triggers an automatic payment refund. The algorithm is also self learning. Over time its designed to assess the risk-function of an email list. (I'm from a data science background and SESS is a side project which uses learnings we get from elsewhere).

Like i mentioned in an earlier comment, we have a nifty little program that checks both the validity of the business email as well as the domain. Then a sampling of the list is done to weed out troublemakers. We do a little bit more. Unfortunately i can't get into specifics here :)

I must agree that we have not given particular thought to making this work on mobile. We made the assumption that people composing newsletters would mostly be working on desktops than on mobiles.

Hi, im one of the engineers that built SESS. I can't get into specifics but we have a nifty little algorithm that works at multiple levels right from checking whether you have a valid business email to email list scanning to match bounces from a master bounce list etc. etc. Finally if it deems the list is risky it triggers an automatic payment refund.