6 ms·

Show HN: Moltin – eCommerce Back End as a Service

116 points by AJSturrock 12y ago

bsbechtel 12y ago
Interesting. Don't most of the ecommerce-as-a-service companies offer an API these days, or am I mistaken? How would this be different if they do? The pricing model?
- jHoldroyd 12y ago
  Hi there, co-founder here. A few of them do have an API offering, but there's a few issues with them - Firstly they’re bolted on the side, and aren’t usually functional enough to actually power a full store - generally they’re designed for add-ons. Secondly you’re locked into their whole platform just to get access to the API even if you’re not looking to build a website, or use all of their services. We’re making a product that gives you the ability to pick and choose exactly which parts of e-commerce you need, in a way that doesn’t lock you into the product.
  - Spone 12y ago
    Hi, could you elaborate on how you prevent lock-in? We are interested in moving away from TicTail for our own shop, but do not want to reinvent the wheel so we can focus on developing a few custom features.
    - jHoldroyd 12y ago
      Because we’re an API, you can retrieve, remove, destroy your data at will. When you incorporate us into your app or site, you have a very loose relationship with our system. That means its very easy for you to stop using our product without having to rebuild from scratch. In the future we’ll be making it even easier to migrate to and from Moltin with tools to import and export data.
bsbechtel 12y ago
Also, your close button on the signup popup doesn't seem to work on Firefox.
- jHoldroyd 12y ago
  Sorry about that, I'll take a look at the issue now.
jtchang 12y ago
How do you handle the case of a product that you get to select different options? I don't see it in the API.
- jHoldroyd 12y ago
  We have support for modifiers (size, colour, etc.), singles (gift wrapping, etc), input (custom options or labels). We’re working hard to make sure our new docs platform has all of this in it, but you can find it in the API reference and use these via our dashboard (forge). If you ever have any problems we’re always available on email or live chat :)
base 12y ago
If someone is going to integrate with your API in PHP as an example, why not use a full open source shopping cart where they have more control?
- jHoldroyd 12y ago
  Because we’re quicker and easier to implement. That gives the developer much more freedom to be creative with their application, especially if they’re working within a budget or short timeframe. Our API also allows you to pick and choose the components you want, you can build more than just a website, your data is accessible on mobile or at a physical retail store all from the same platform.
kposehn 12y ago
Question - are you planning on making a ruby gem for it?
- jHoldroyd 12y ago
  We are yes, we started with what we knew and now are allowing the community to vote on what they want us to release next - https://moltin.com/getting-started#vote https://moltin.com/getting-started#vote
karambahh 12y ago
Nice! Do you plan on adding modules? Would you be willing to add features via partnerships? Your "full" ecommerce stack lacks a few things that could be added either into your core or via external tools.
- jHoldroyd 12y ago
  In short, Yes! But perhaps not soon. We have a really strong community ethos at Moltin, and we’re trying hard to open up as much of our platform as possible, both in open source and community modules. We know there is still work to be done and we have a pretty lengthy set of features and updates going forward.
thecatspaw 12y ago
This looks nice, but very limited. Is there any support for: - Vouchers - Promotions - Categories - Classifications ? These all are features a successfull webshop needs. I have to admit I only took a brief look at the API, but all this seems to be missing. Am I mistaken? edit: seems like Categories at least exist. I didnt find the docs at first. I suggest putting the Documentation link into the "more" dropdown in the navigation
krmmalik 12y ago
Is this for inventory based sites inky or would it work for digital products too?
- jHoldroyd 12y ago
  The beauty of an API approach is the features we don’t quite fully support can be easily created by you within your application, and then work alongside our product. We don’t explicitly advertise support for digital products at the moment, however, we can support it to some degree. Reach out to us on livechat or email and we’ll be happy to help.
jordanlev 12y ago
2 questions: How does this compare to existing eCommerce back-ends like SnipCart, Ecwid, Foxycart? And: I presume your service requires javascript to function (as all of the similar services do)... any chance of providing a non-javascript fallback such as a generic-looking checkout page hosted on your own servers (like when you use a paypal button to send users to their site to complete the final step of the transaction)? Please don't tell me that "everyone uses javascript yay" or that I shouldn't be concerned -- I know who my clients and their users are and I know what their accessibility requirements are :) (I always have to say this when I ask eCommerce services this question because usually they dismiss it out of hand and it's very frustrating when you have requirements that sites work even without javascript). Thanks, and best of luck!
- thasmin 12y ago
  The website has PHP and curl examples.
  - jordanlev 12y ago
    Ah, I see... so actually this is a big distinguishing factor that separates this from the other services I mentioned! Looking forward to playing around with this.
    - jHoldroyd 12y ago
      Great, if you need anything or have any feedback we're always available on livechat or support@moltin.com
- AJSturrock 12y ago
  Firstly we’ve looked at all of these options and as developers got pretty excited by their potential. The problem was that we found them to all be lacking in some degree, Snipcart is only for the most basic ecommerce, Ecwid is focused more on widgets, and Foxycart requires you to use their hosted checkout. Secondly every member of our team has been in a position at some point in their working lives where we’ve had to build applications that support all manor of strange legacy requests. We completely understand. Yes, if you use our javascript SDK with the API, you would require javascript for it to work. That said, you could take the backend approach and then there would be no issues with supporting older clients or applications as it would all be handled by the servers. We have been thinking about adding a hosted checkout page for exactly the reason you describe. it would probably be an option so that you can either use a hosted checkout page quickly, or if you want more control you can use one of our SDKs and build your own checkout. Thanks for wishing us luck!
ngoel36 12y ago
The pricing confuses me a bit - as a user, I would have very little sense as to how many API requests or how much storage I would need for an eCommerce app. Why not price simply as a percentage of all processed transactions (in addition to the payment gateway commission, of course)
- AJSturrock 12y ago
  There’s two reasons behind the way we’ve structured our pricing: Firstly you can very easily circumvent our checkout flow as we don’t lock you into using the entire system, we could therefore be supporting a large store and never receive a payment. Secondly we see transaction fees as penalising you for selling well. It’s tough to push a product when gateways already charge for payments. A combined total of 5%+ for every order would be difficult for store owners to swallow. We decided that offering a free tier and flat monthly fees for our paid users would be more acceptable. As a user you know exactly what you will be charged for each month. Thanks for the feedback though, we’ll see what we can do to explain API requests and storage better.
  - michaelmior 12y ago
    The parent commenter's concern was that the pricing is difficult to understand. But you said one of the reasons you selected your pricing structure is so that users now exactly what they will be charged for. I agree that it's much easier to estimate sales then the number of API calls that will be used. Another point to consider is that users have a monetary incentive not to use any new features you may come up with in the future. (Unless of course, they have strong reason to believe that implementing these features will provide a significant boost in sales.)
    - jHoldroyd 12y ago
      We also felt that it meant the people building the sites also had an incentive to be more careful about the way they did it - like sharing resources across a session and limiting the calls per page, or implementing caching. All of which actually improve the user experience due to slightly faster page loads, which in eCommerce is crucial.
Svenstaro 12y ago
How about a Python SDK? :D
- jHoldroyd 12y ago
  Again, on the list - but if someone were to do one we'd be happy promote it ;)
  - curiously 12y ago
    I'd definitely be interested in this as a Flask user.
bikamonki 12y ago
Do you support non-US businesses? Payments in particular. For example: send all collected payments to a Paypal account.
- jHoldroyd 12y ago
  Yes we do, we support over 50 payment gateways with more on the way. You can see the complete list here - https://moltin.com/faq#gateways https://moltin.com/faq#gateways
cyri 12y ago
How do you compare to: http://www.commercetools.com/en/pricing/ http://www.commercetools.com/en/pricing/ (I'm not affiliated with them.) They are expensive ... but why should I choose you?
- jHoldroyd 12y ago
  Commercetools is a good platform and one of our closest competitors. The key differences are that our pricing scales a lot better, we don’t lock you into a single gateway or charge transaction fees. We also don’t arbitrarily limit the number of products you can store, or the bandwidth you can use. We’re also more flexible, we have an EAV system (Flows) that allows you to modify and store custom data sets in a structured way. This allows you to use Moltin as a much bigger part of your product than just what we currently offer. They do have a few more features right now but we’re pushing hard on the development front to reach feature parity with the major platforms.
curiously 12y ago
so why should a developer use this vs building their own? if open source back end tools exist why not self host those? looks like a great product, curious to know what stack you are running, are each backend hosted on amazon?
- outrunthewolf 12y ago
  Hey, another co-founder here. There is no reason why you couldn’t do that! we’ve even open-sourced a bunch of our components to help people do it - https://github.com/moltin https://github.com/moltin The reason we created Moltin was to speed up this process, bring it up to modern standards, and give developers the creative freedom to use the tools they’re comfortable with. By not going down the self-hosting route you also no longer have to manage the installation, keep the codebase secure or worry about scaling. Our main stack utilises nginx, php, postgres, redis and a few other things in-between, we’re built on top of AWS purely for the flexibility it gives us.
  - curiously 12y ago
    so basically the benefit here is saved time and reduced operating costs by outsourcing the ecommerce infrastructure. How did you decide that ecommerce would benefit the most by outsourcing the infrastructure? I'm definitely interested in using this to see if I can host a shop since I most certainly end up creating a lot of it from scratch. From a developer point of view, it looks like an SDK/API for building ecommerce websites. How would you differentiate yourself from shopify like solutions? Are you targeting the developer market vs non-technical users?
    - outrunthewolf 12y ago
      Correct. As a developer you know the amount of time you can put into building your own solution to a problem. That approach is fun and a great way to learn, but at some point the benefits can often outweigh the actual costs. We all spent years building eCommerce websites on a range of platforms and grew more disenfranchised with them over time, we knew there had to be a better way. We started to discuss the concept of building JS only stores. We loved what Stripe were doing for payments and wanted to bring it to the rest of eCommerce, so we ended up settling on our API approach. Exactly, We're building for developers, Shopify (typically) supports quick stores for non-technical users, but as developers it greatly limits the flexibility we have.
Immortalin 12y ago
What benefit does Moltin offer over CMS backed ecommerce service such as Drupal commerce and Woocommerce? Your website seem to emphasize rapid application development yet this is not too different from the CMS backed alternatives.
- AJSturrock 12y ago
  If you want a basic site quickly, then going with a platform like WooCommerce and an off-the-shelf theme may work well for you. Once you start customising themes and adding advanced functionality, complicated folder structures and functional programming styles can cause no end of problems for many developers. API based means you’re not locked into a specific CMS or blog platform, you’re not even locked into a specific language or device. All we care about is data transfer and logic, leaving you free to do anything with the frontend. If you want to know more about what our platform provides apart from rapid development, we’ve touched on them in our other comments.

116 points by AJSturrock 12y ago

Interesting. Don't most of the ecommerce-as-a-service companies offer an API these days, or am I mistaken? How would this be different if they do? The pricing model?

jHoldroyd 12y ago
Hi there, co-founder here. A few of them do have an API offering, but there's a few issues with them - Firstly they’re bolted on the side, and aren’t usually functional enough to actually power a full store - generally they’re designed for add-ons. Secondly you’re locked into their whole platform just to get access to the API even if you’re not looking to build a website, or use all of their services. We’re making a product that gives you the ability to pick and choose exactly which parts of e-commerce you need, in a way that doesn’t lock you into the product.
- Spone 12y ago
  Hi, could you elaborate on how you prevent lock-in? We are interested in moving away from TicTail for our own shop, but do not want to reinvent the wheel so we can focus on developing a few custom features.
  - jHoldroyd 12y ago
    Because we’re an API, you can retrieve, remove, destroy your data at will. When you incorporate us into your app or site, you have a very loose relationship with our system. That means its very easy for you to stop using our product without having to rebuild from scratch. In the future we’ll be making it even easier to migrate to and from Moltin with tools to import and export data.

bsbechtel 12y ago

Also, your close button on the signup popup doesn't seem to work on Firefox.

jHoldroyd 12y ago
Sorry about that, I'll take a look at the issue now.

jtchang 12y ago

How do you handle the case of a product that you get to select different options? I don't see it in the API.

jHoldroyd 12y ago
We have support for modifiers (size, colour, etc.), singles (gift wrapping, etc), input (custom options or labels). We’re working hard to make sure our new docs platform has all of this in it, but you can find it in the API reference and use these via our dashboard (forge). If you ever have any problems we’re always available on email or live chat :)

base 12y ago

If someone is going to integrate with your API in PHP as an example, why not use a full open source shopping cart where they have more control?

jHoldroyd 12y ago
Because we’re quicker and easier to implement. That gives the developer much more freedom to be creative with their application, especially if they’re working within a budget or short timeframe. Our API also allows you to pick and choose the components you want, you can build more than just a website, your data is accessible on mobile or at a physical retail store all from the same platform.

kposehn 12y ago

Question - are you planning on making a ruby gem for it?

jHoldroyd 12y ago
We are yes, we started with what we knew and now are allowing the community to vote on what they want us to release next - https://moltin.com/getting-started#vote https://moltin.com/getting-started#vote

karambahh 12y ago

Nice! Do you plan on adding modules? Would you be willing to add features via partnerships? Your "full" ecommerce stack lacks a few things that could be added either into your core or via external tools.

jHoldroyd 12y ago
In short, Yes! But perhaps not soon. We have a really strong community ethos at Moltin, and we’re trying hard to open up as much of our platform as possible, both in open source and community modules. We know there is still work to be done and we have a pretty lengthy set of features and updates going forward.

thecatspaw 12y ago

This looks nice, but very limited. Is there any support for: - Vouchers - Promotions - Categories - Classifications ? These all are features a successfull webshop needs. I have to admit I only took a brief look at the API, but all this seems to be missing. Am I mistaken? edit: seems like Categories at least exist. I didnt find the docs at first. I suggest putting the Documentation link into the "more" dropdown in the navigation

krmmalik 12y ago

Is this for inventory based sites inky or would it work for digital products too?

jHoldroyd 12y ago
The beauty of an API approach is the features we don’t quite fully support can be easily created by you within your application, and then work alongside our product. We don’t explicitly advertise support for digital products at the moment, however, we can support it to some degree. Reach out to us on livechat or email and we’ll be happy to help.

jordanlev 12y ago

2 questions: How does this compare to existing eCommerce back-ends like SnipCart, Ecwid, Foxycart? And: I presume your service requires javascript to function (as all of the similar services do)... any chance of providing a non-javascript fallback such as a generic-looking checkout page hosted on your own servers (like when you use a paypal button to send users to their site to complete the final step of the transaction)? Please don't tell me that "everyone uses javascript yay" or that I shouldn't be concerned -- I know who my clients and their users are and I know what their accessibility requirements are :) (I always have to say this when I ask eCommerce services this question because usually they dismiss it out of hand and it's very frustrating when you have requirements that sites work even without javascript). Thanks, and best of luck!

thasmin 12y ago
The website has PHP and curl examples.
- jordanlev 12y ago
  Ah, I see... so actually this is a big distinguishing factor that separates this from the other services I mentioned! Looking forward to playing around with this.
  - jHoldroyd 12y ago
    Great, if you need anything or have any feedback we're always available on livechat or support@moltin.com
AJSturrock 12y ago
Firstly we’ve looked at all of these options and as developers got pretty excited by their potential. The problem was that we found them to all be lacking in some degree, Snipcart is only for the most basic ecommerce, Ecwid is focused more on widgets, and Foxycart requires you to use their hosted checkout. Secondly every member of our team has been in a position at some point in their working lives where we’ve had to build applications that support all manor of strange legacy requests. We completely understand. Yes, if you use our javascript SDK with the API, you would require javascript for it to work. That said, you could take the backend approach and then there would be no issues with supporting older clients or applications as it would all be handled by the servers. We have been thinking about adding a hosted checkout page for exactly the reason you describe. it would probably be an option so that you can either use a hosted checkout page quickly, or if you want more control you can use one of our SDKs and build your own checkout. Thanks for wishing us luck!

ngoel36 12y ago

The pricing confuses me a bit - as a user, I would have very little sense as to how many API requests or how much storage I would need for an eCommerce app. Why not price simply as a percentage of all processed transactions (in addition to the payment gateway commission, of course)

AJSturrock 12y ago
There’s two reasons behind the way we’ve structured our pricing: Firstly you can very easily circumvent our checkout flow as we don’t lock you into using the entire system, we could therefore be supporting a large store and never receive a payment. Secondly we see transaction fees as penalising you for selling well. It’s tough to push a product when gateways already charge for payments. A combined total of 5%+ for every order would be difficult for store owners to swallow. We decided that offering a free tier and flat monthly fees for our paid users would be more acceptable. As a user you know exactly what you will be charged for each month. Thanks for the feedback though, we’ll see what we can do to explain API requests and storage better.
- michaelmior 12y ago
  The parent commenter's concern was that the pricing is difficult to understand. But you said one of the reasons you selected your pricing structure is so that users now exactly what they will be charged for. I agree that it's much easier to estimate sales then the number of API calls that will be used. Another point to consider is that users have a monetary incentive not to use any new features you may come up with in the future. (Unless of course, they have strong reason to believe that implementing these features will provide a significant boost in sales.)
  - jHoldroyd 12y ago
    We also felt that it meant the people building the sites also had an incentive to be more careful about the way they did it - like sharing resources across a session and limiting the calls per page, or implementing caching. All of which actually improve the user experience due to slightly faster page loads, which in eCommerce is crucial.

Svenstaro 12y ago

How about a Python SDK? :D

jHoldroyd 12y ago
Again, on the list - but if someone were to do one we'd be happy promote it ;)
- curiously 12y ago
  I'd definitely be interested in this as a Flask user.

bikamonki 12y ago

Do you support non-US businesses? Payments in particular. For example: send all collected payments to a Paypal account.

jHoldroyd 12y ago
Yes we do, we support over 50 payment gateways with more on the way. You can see the complete list here - https://moltin.com/faq#gateways https://moltin.com/faq#gateways

cyri 12y ago

How do you compare to: http://www.commercetools.com/en/pricing/ http://www.commercetools.com/en/pricing/ (I'm not affiliated with them.) They are expensive ... but why should I choose you?

jHoldroyd 12y ago
Commercetools is a good platform and one of our closest competitors. The key differences are that our pricing scales a lot better, we don’t lock you into a single gateway or charge transaction fees. We also don’t arbitrarily limit the number of products you can store, or the bandwidth you can use. We’re also more flexible, we have an EAV system (Flows) that allows you to modify and store custom data sets in a structured way. This allows you to use Moltin as a much bigger part of your product than just what we currently offer. They do have a few more features right now but we’re pushing hard on the development front to reach feature parity with the major platforms.

curiously 12y ago

so why should a developer use this vs building their own? if open source back end tools exist why not self host those? looks like a great product, curious to know what stack you are running, are each backend hosted on amazon?

outrunthewolf 12y ago
Hey, another co-founder here. There is no reason why you couldn’t do that! we’ve even open-sourced a bunch of our components to help people do it - https://github.com/moltin https://github.com/moltin The reason we created Moltin was to speed up this process, bring it up to modern standards, and give developers the creative freedom to use the tools they’re comfortable with. By not going down the self-hosting route you also no longer have to manage the installation, keep the codebase secure or worry about scaling. Our main stack utilises nginx, php, postgres, redis and a few other things in-between, we’re built on top of AWS purely for the flexibility it gives us.
- curiously 12y ago
  so basically the benefit here is saved time and reduced operating costs by outsourcing the ecommerce infrastructure. How did you decide that ecommerce would benefit the most by outsourcing the infrastructure? I'm definitely interested in using this to see if I can host a shop since I most certainly end up creating a lot of it from scratch. From a developer point of view, it looks like an SDK/API for building ecommerce websites. How would you differentiate yourself from shopify like solutions? Are you targeting the developer market vs non-technical users?
  - outrunthewolf 12y ago
    Correct. As a developer you know the amount of time you can put into building your own solution to a problem. That approach is fun and a great way to learn, but at some point the benefits can often outweigh the actual costs. We all spent years building eCommerce websites on a range of platforms and grew more disenfranchised with them over time, we knew there had to be a better way. We started to discuss the concept of building JS only stores. We loved what Stripe were doing for payments and wanted to bring it to the rest of eCommerce, so we ended up settling on our API approach. Exactly, We're building for developers, Shopify (typically) supports quick stores for non-technical users, but as developers it greatly limits the flexibility we have.

Immortalin 12y ago

What benefit does Moltin offer over CMS backed ecommerce service such as Drupal commerce and Woocommerce? Your website seem to emphasize rapid application development yet this is not too different from the CMS backed alternatives.

AJSturrock 12y ago
If you want a basic site quickly, then going with a platform like WooCommerce and an off-the-shelf theme may work well for you. Once you start customising themes and adding advanced functionality, complicated folder structures and functional programming styles can cause no end of problems for many developers. API based means you’re not locked into a specific CMS or blog platform, you’re not even locked into a specific language or device. All we care about is data transfer and logic, leaving you free to do anything with the frontend. If you want to know more about what our platform provides apart from rapid development, we’ve touched on them in our other comments.