I would reconsider the "Unlimited Emails" offering for the "Ultimate" $100/mo plan. Assuming you're using SES, a customer sending 1,065,000 emails would cost ~$100. All it takes is one person to abuse it before it's costing you big money.
On the surface, "Unlimited" sounds great, but your target market is developers that know the cost of sending emails. This may result in the opposite effect as it signals your model may not be scalable if there's not enough low usage accounts to subsidize the additional costs of sending emails.
The even greater problem with sending email is that your platform will immediately and comprehensively be abused by spammers.
To make your email woes go away, I would recommend using MailChannels [1] rather than SES or SendGrid because MailChannels has a built-in anti-abuse layer that will send you a webhook whenever a bad user is detected. SES will just terminate your account, which probably isn't what you want. Also, at high volume, MailChannels costs less.
Seems like policies around data and privacy would be paramount here. As someone who has developed a couple backends I always struggle to see the value add of a system like this. For me, it always seems like this is something I'll have to do later and back tracking would be more work. Very clean site though, the mint technology piece was pretty interesting as well. Good synergy to market both at once!
I'm the author of Mint, so it was the obvious choice :)
I choose Crystal because I had experience using Ruby and I absolutely loved the syntax, also Mint is built with Crystal. I really like it because it easy to read (even with type annotations) and compiles to a fast binary.
Edit: If you have specific questions let me have it :D
One interesting aspect is that it takes a lot of energy building the whole compile-to-js frontend framework, yet you are also building your own service. Kudos!
I'm using Elixir and Elm, and understand why Mint happens. I'm keeping eyes on Mint, would love see a build-with-Mint page. This app is the first one!
"You will provide us the right to reproduce, modify or create derivative works from your Content. Obviously we won’t be modifying your Content, we need these rights for example to be able to share your designs with other users. You will also provide us a right to publicly perform or display your Content to allow us to display the material on other users’ monitors.
Base does not claim any ownership on your Content. You hereby grant Base a worldwide, non-exclusive, revocable, royalty-free, fully paid, sublicensable and transferable license to use, host, store, reproduce, modify, create derivative works, publicly perform, display, distribute and transmit your Content."
I am not sure I read it right, but does it say that you are allowed to share my content with whomever you like?
And also create new versions of my work?
That's almost a standard disclaimer by now. If this API let's you upload an image and by request (of yourself or a user) it returns a resized version of that image, that might already be a derivative work and distribution of that content.
Looks nice. I’m uncomfortable pushing the password in plaintext to an unknown entity. I can always bcrypt the password locally before sending it through the API, but it would be great to see examples of this, to prevent deva from pushing secrets outside their zone of control.
Otherwise, I can see myself using this in some side-projects. Good work!
Looks great, but I have been bitten badly before by vendor lock-in using a SaaS and they either go out of business or jack up their prices exponentially. The only mitigation I know of is to make Base open source, so if needed users can host their own instance. What are your thoughts on this?
I use firebase for authentication and have been quite happy with it, but if this provides better integration with mailing lists out of the box, that would be compelling to me. Although I use firebase for authenticated users, I also have a mailing list sign up form with just an email field. I ended up creating my own confirmation email flow because I needed it to work for both people who created an account and people who just used the email form. It would've been nice not to have to do that.
This is pretty interesting and useful. This would be immensely useful for prototypes and a great entry point for developers. Kind of reminds me of Firebase how it tries to be a one-stop-shop. it also seems much more approachable than Firebase which is nice.
I completely agree on this being a lot more approachable than Firebase. The premise of Firebase is so nice, but the amount of information when starting to look into it are overwhelming.
Why should I link myself so heavily to a provider like you? Not wanting to troll, as a dev, I know that the problems you try to solve are common, but still wondering what happens "if..."
By "if..." I assume you mean by going out of business? In that case the service would be released as open source and you would continue as normal.
What I would like feedback on is how people would like to use a service like this? Self hosted with a license? SaaS? some other way I'm not thinking of?
For me, as an early stage startup founder, I'd prefer SaaS. At this stage I don't want to have to think about anything that could've been handled for me. At a later stage I might prefer self-hosted, but not sure.
The sign-up button for the developer plan doesn't work (Firefox 68.0.1). Nice idea though. It'd be neat to be able to host it ourselves, if you ever plan to release it as OSS.
Thanks for the bug report! It should be fixed now.
> It'd be neat to be able to host it ourselves, if you ever plan to release it as OSS.
The pricing is just a placeholder at this point, it is possible that there will be a self hosted plan, since it can be easily compiled to a single binary.
This looks awesome! What backend framework are you using? I'm the author Lucky and was wondering if you happened to use it on the backend since you are using Crystal
Like usual with Ruby/Crystal apps the api uses snake case for its keys.
The js default is usually camel case.
It can be rather ugly to have it mixed if one uses this in a js/node app.
On the surface, "Unlimited" sounds great, but your target market is developers that know the cost of sending emails. This may result in the opposite effect as it signals your model may not be scalable if there's not enough low usage accounts to subsidize the additional costs of sending emails.