What is our primary use case?
Our main use case is integrating SendGrid with Sentinel, and we use the .NET API.
For SendGrid with the .NET API, any use case can work. We can accomplish anything, but for example, contact forms with some Lambda functions. We are using it for more simple sites.
When a user submits a form, it is a perfect use case because when you create an account, there are very well-defined instructions on how to integrate with the API using your specific language that you have a project in. When a user submits the form, it uses the SendGrid client and secret token. It sends a request to SendGrid backend, and there the magic happens.
I do not have anything specific to add about my main use case or anything unique about how my team uses SendGrid.
What is most valuable?
In my experience, the best features SendGrid offers include the dashboard, which is very nice to review if emails were delivered or if something was wrong. For example, I did not know that they have templates, but we made our own. We used to send full HTML through our API. We just input the user message into the template, and then it looks beautiful when the email arrives.
I find the dashboard useful because it is very extensible. You can slice and dice data. You can have a quick peek at the latest information, so you can use it for quick checks but also for deeper investigations if you want to gain more insights.
SendGrid has positively impacted my organization as we moved to it from our own email servers, though it also gives us less control over everything.
What needs improvement?
I think SendGrid is great already as it is. If they keep developing it, that would be beneficial. If I were a power user, then I would probably have some ideas, but it is perfect for my use case.
SendGrid can be improved with better user interface design. By default, there is a white, hard-for-the-eyes background. A dark mode by default would be nice. I have not visited the dashboard in quite a while, but I think they do not follow the system color preference. That would be a nice addition. Otherwise, I think they are pretty good, and they are popular for a reason.
I do not have more to add about needed improvements. If there was something significant, I would create a ticket, so my use case appears to be covered.
For how long have I used the solution?
I have been working in my current field for almost four years.
What do I think about the stability of the solution?
In my experience, SendGrid is stable. I do not recall any issues with it.
What do I think about the scalability of the solution?
I am sure SendGrid's scalability is good; however, we did not need this feature. Of course, I would imagine any large email service is able to handle that. It should be, of course. SendGrid is designed for both small businesses and large ones, so I cannot provide feedback, but I imagine it is covered.
How are customer service and support?
I never had to contact SendGrid's customer support. There is nice documentation that answers a lot of questions, as well as frequently asked questions and a lot of examples outside of the documentation. Usually, everything is covered.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
I used an on-premises solution before SendGrid.
What was our ROI?
I cannot speak to the return on investment from using SendGrid because I am not involved in that. It is also very hard to see the effect of implementing it. SendGrid gives us some business opportunities sometimes if someone reaches out to us through emails sent through SendGrid. It is really hard to estimate.
Which other solutions did I evaluate?
I was not the person choosing the tech stack, but at least to me, SendGrid is the option I would choose. There are also others, such as Twilio. In our company, we search for multiple options and spend some days to evaluate which one is better for our team and which covers our needs the most.
What other advice do I have?
My advice to others looking into using SendGrid is to think about whether you actually need to use it or if you can use something different. Spend time researching other options. Then, if you are sure you need SendGrid, spend time designing the code architecture so that it is easy to send emails from anywhere in the code and it is not hard-coded. Consider integrating with templates, as they are available. Make sure that everything is configured correctly. Spend time reading the documentation and learning the tool properly before attempting to do something, because it can cost you money and time later to refactor.
I think SendGrid is also useful for solo developers or people who want to learn web development and need a tool to allow them to send emails without setting up their own server, which can be difficult and also be spam-filtered. There is also a free tier for people like that, so it is great to learn it. I would be happy if another company that I join in the future will be using it. I give this product a rating of nine out of ten.
Which deployment model are you using for this solution?
Private Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Other
Disclosure: My company does not have a business relationship with this vendor other than being a customer.
