Full disclosure: I work at commercetools, another player in the space.
The movement towards "headless", API-first platforms has a lot of steam. So much so that older platforms (e.g. Salesforce) are jumping on the bandwagon to stay relevant in the market.
That said, I know there are a lot of startup-focussed readers on HN. This trend is for larger companies who want to really own their customer experience, including their own frontend. You'll have more flexibility, and using an API-first platform will be a lot less work than writing your own backend, but... it's still more work.
If you are small, you need a quick MVP etc. going with a Shopify or BigCommerce is the faster way to start selling. Once you've got a good stream of revenue and you're feeling these platforms are too rigid, looking for an API-first platform is a good idea!
I find myself regularly trying to talk my clients out of going headless on Shopify. The benefits are so hyped (and potentially real) but the cost/maintenance is significant.
I’ve come into working on multiple different headless sites developed by others who then walked away and left an entirely non-technical team to sort it out.
A well-built Shopify theme works great and plenty fast for even medium sized companies.
I worked with a smaller but decent-sized player in this space and the API components (while difficult) are the easier piece of the puzzle. Micro-front-ends seem really cool but you don't have to dig very deep before your spidey sense starts to tingle. We built on top of CT and others, and the front-end composition was a nightmare, so if you think backend microservices are tough to get right you haven't seen anything yet. In our experience you typically jumped through a lot of hoops to build a custom UI in someone else's walled garden against APIs that had great promise but never got you as far as "API-first" should in terms of custom, sophisticated work flows.
I'm going to have to disagree. While basic startups may be best served by shopify anything with complexity should consider an API-First platform. B2B2C, Multi, etc. all benefit from the flexibility it provides. What is important is finding a SaaS with a true multi-tenant infrastructure so they can price based on usage instead of having a large yearly minimum contract value.
Startups can have great success going API-First, but it's contingent on working with the right company.
Tools at the Shopify level solve customer problems for companies and then layer-on solutions to the merchants’ own problems (inventory, marketing, fulfillment etc)
Tools at the CommerceTools level address “large company” problems first and foremost, some of which are real and others imaginary, often to the detriment of the customer experience.
This isn’t a criticism of anyone’s technology but more of an observation of how things are very different when the customer is a billion dollar enterprise.
When I worked in a LARGE eCommerce company maybe 6 years ago, everything was driven by CSV files dropped in an FTP folder. There were a few exceptions where companies had API's. Still even those were GET requests initiated by us, and we didn't want to overload them so it wasn't super up-to-date, but that was the norm. I tried to break out to do my own thing, and I realized those automated systems were only for the big guys.
If you were small, you don't even get the privlidge of an inventory file. Vendors don't have time to deal with small guys, and it can be super difficult to get started.
Playing with crypto, and NFT's, I realized this was what I wish was the norm. The indexers were close to real-time. The chain I was using (AVAX) had a finality of 4 seconds, and gas is cents.
What i'm going to describe isn't a solution to a problem the big guys have. They had enough sway with their vendors to get good systems. But for small guys like me, open access to automated systems would have been a god send. My dream system would be something like this:
Think of this happening in a subnet (an app specific blockchain that doesn't share space with other apps, so scale is not affected by other apps)
1. A Trusted supplier mints a NFT for each of their SKU's (yeah trust and crypto don't go together ideologically, that's a purity problem crypto needs to get over itself, sometimes trust is useful... if you try to build the whole thing trustless, it's not better than traditional systems).
2. These NFT's are listed in any NFT marketplace that cares to list them. (with subnet-to-subnet messaging, you don't need to duplicate the contracts... so shouldn't have major scale issue. This is a brand new feature, so i'm not super sure though.)
3. I as a small scale vendor list a sku on my normal site. I can take payment as normal, but then I can call the NFT's index to get real-time inventory (even though I have no preexisting relationship with the vendor)
4. I get an order, I buy the NFT off the marketplace, and burn the NFT. My customers details are provided in the NFT burn contract. An app specific precompile let's me transmit those details to the vendor without making it public on the block chain (with proof it received it correctly).
5. After the NFT is burned, an ERC20 token is dropped in my stores wallet. After I get enough of these, I can trade them in for a volme rebate. This let's the small vendors get access to effectively what is a volume discount.
I suppose this could be a SaSS app, but there's a bunch of side benefits to crypto, such as defi, tooling etc. But mainly vendors can customize their own terms if they own the full contract chain.
I'm one of the maintainers of MageOS (a fork of Magento) as well as a maintainer of Daffodil (a monolithic Angular PWA framework - not Microfrontends yet).
APIS are definitely the way to go but, while that's a great next step, what we're really facing is a standards issues.
Some have tried.
Schema.org as a standard is overly complex and each platform has their own API definition.
Microfrontends can be great as well, but ecommerce has a particularly special problem of requiring extremely performant SSR, so that's always a critical and complex piece to get correct.
Former M1/M2 Dev here. The benefits of headless to me are that it's far easier to find javascript developers than to ruin someone with learning the Magento architecture.
I haven't seen Magento - under Ebay, under Adobe, under anyone address what I think is the biggest issue facing them - total cost of ownership in comparison to the competition.
Is mageOS mostly just a maintainence mode, keep this alive till everyone can switch off (like the M1 forks that exist) or do you actually envision trying to solve some of the challenges magento is facing as a community and platform?
As someone who works in the commerce space day-to-day, the trend is interesting and definitely something you will hear a lot of ecommerce managers and businesses discuss.
Aside from the frontend flexibility, one major advantage of building API-first in an ecommerce context is that it can allow different parts of the system to be developed and maintained independently. This can make it easier to update and extend individual components without affecting the overall system - which is often a headache with current systems such as Shopify, Magento etc.
IMO, One of the most interesting nuances in the space is the focus shift between OS and closed-source solutions in this space. The problem for larger companies (+$50M) is that they seek to build something their tech teams can take full ownership of and easily inject custom logic into. This is not as easy with proprietary solutions even if they are headless and API-first. Instead these businesses end up looking into either building something fully custom or seek out open source solutions like Medusa (JS/TS), Sylius (PHP) or Spree (Ruby) to use as a foundation to build a custom setup from.
In general though, the headless / API-first trend definitely seem to be something that a lot of companies are exploring at the moment.
There's not a lot of ecom discussion on hackernews which is weird to me since that's the line of business I am in.
The trend I see continuing is the commidification and standardization of ecommerce platforms, with Shopify and BigCommerce continuing to chomp away at former giants like Magento (now Adobe Commerce). For most companies, the TCO of an ecommerce platform is an important driver in the decision making process. Companies often balk at the demands of shopify (around what you can and can't do) but then come to terms with it and select shopify as their platform.
For anyone with real budgets (like Nike.com) - totally custom, or building on a practically custom (Adobe) site, there may be moves towards the headless trends, but for the most part, the people (SMB) I deal with do not care about the technology, they just want a short time to launch and a low cost. So for me, I've seen a shift towards to low/no-code platforms and low cost. In the headless space I think fabric is particularly interesting, though I do think Adobe has a chance to do it correctly, but overall, I've sat in on several pitches for going headless and the total cost in just doesn't seem to be worth it.
Shopify is excellent from a micro business point of view. Even coming from the perspective of a Python dev with limited FE experience, it’s so much easier for the client/business owner to administrate. I have a friend who was a Wordpress developer for 10+ years who couldn’t see from a client perspective that the technical limitations of shopify were irrelevant when compared with the hassle of Wordpress ( and it’s e-commerce plugins).
One of the interesting struggles I see in the space comes from companies that managed to grow on Shopify or BigCommerce, but then reach the limits of those platforms, and looking out into the enterprise space, they get hit with sticker shock, because there's a notable chasm between a Shopify Plus and something like Adobe Commerce or Salesforce Commerce Cloud. It's a little different when you're using those at an enterprise scale, where the cost and performance hits that come with 30+ Shopify Apps, or having to gaze into a crystal ball and give Adobe your best guess at how much infrastructure you'll need next quarter, but if you're a digitally native brand that's grown up on SaaS ecommerce, getting out of the kiddie pool usually means a big change in tech investment.
Of course, everyone in the space is scrambling to say they're headless, because commercetools has absolutely changed the conversation in the ecommerce space, but it's not some magic bullet. It's an architectural decision that should be informed by business needs, e.g. supporting multiple regions, multiple brands, or sharing one backend between your website, app, and in-store experiences. Handily, it does serve as a salve to front-end issues inherent to the all-in-one approach that was so dominant a decade ago. By decoupling the frontend from platforms like Shopify Plus or Salesforce, you get a taste of the speed and freedom that comes with a modern front-end, but also quickly run into no-go zones where even in 2022, there's no API access to important backend features - because there never will be, because that messes with the business model of these platforms.
On the bright side, even taking legacy monolithic platforms like that headless will make it easier to migrate to a more robust API-first backend solution when the time comes.
It certainly makes the most sense with the Nikes and the AT&Ts of the world. Substituting something like commercetools in for their in-house ecommerce systems offsets a huge amount of technical debt, and lets internal teams focus on being more effective at doing whatever makes Nike different from Puma. And while a digital transformation to a MACH approach sometimes has a higher up front cost, companies are clamoring to get away from the millions they spend in maintenance on versioned legacy stacks like Hybris and Salesforce.
I deal with ecom a lot at work, in which we build out ecomm systems for large(er) companies.
Just about everything is going to AEM with elastic path/ some other ecomm apis and headless frontends (mostly React, namely NextJS, some unfortunately on Gatsby).
I'm not sure what is happening with all the old Magento platforms since Adobe took it over, but I don't think we do much work in Magento any more.
Not even a submarine ad when it literally says SPONSORED BY COMMERCE LAYER at the top!
To that point though - there's no transcript for the podcast. I try to at least describe some technical merit whenever I write a comment like this on HN, perhaps because I would hope that others would do the same if I were to arrange for sponsored content!
But I'm not going to sit through an hour of content and transcribe a quote vs. skimming a transcript to find something cool to highlight. And this isn't even getting into how the lack of a transcript signals how little the brand prioritizes accessibility!
Brands - there's no excuse not to have a machine-initiated human-edited transcript of any corporate podcast when things like OpenAI Whisper exist. Make sure the partners publishing your content are incentivized to do this as well.
We started building a marketplace startup earlier this year. Back then we were naive and weren't familiar with e-commerce stack (and headless commerce API), so we built everything in house (user management, inventory management, database schema, API, auctions etc.). We have a team of 7 covering across backend, web, iOS, and Android.
Are we making a big mistake re-inventing the wheel here? Would love to have some advice on this. When to build vs when to buy when it comes to e-commerce api
My biggest learning from time in the eCommerce world: trivial-sounding things are very, very difficult to get right, and the edge-cases in api-based solutions are entry-level features.
Take a single one of your items: inventory management. There's SOOO much going on here, people look and say "What's the big deal? decrement an integer!" How do you handle payment failures and dunning management? Subscriptions? Bundles? Incomplete carts? Buy online; pick-up in store? blended inventories? multiple locations? The list goes on and the number of interconnected components makes this really hard to solve.
You're building all this, a marketplace and front ends for web & mobile? With a team of 7? I had a team of 23 and struggled to stay on top of all the nuances in just subscriptions, so you're (a) missing important use-cases or (b) way more effective than my former team. Chances are it's somewhere in between.
There's a real "it depends" flavor to any answer you'll get. If your feature set could be handled by off-the-shelf Magento with a couple of plugins, then, sure, you probably should have gone that way. But if you have unusual needs -- and Magento's rigidity means it's not hard to hit that wall -- then either you create massive technical debt kitbashing Magento or similar, or you go with one of the high-end headless systems, which are both expensive and still require you to build front- and backend solutions around them.
In turn, depending on your needs and the regulatory regimes you're working under, you may find that you could have saved time and money going with an industrial-grade solution that can seamlessly handle taxes, accounting and revenue recognition, multi-vendor logistics, credit/refunds, reverse logistics, etc. (there's a lot of etc.!), but that could be overkill for your requirements. I've seen SMBs with small digital teams build and run bespoke e-comm solutions handling all their needs (and more effectively than trying to fit a commercial square peg into a round hole), but the more complex and general their use cases, the more trouble they tend to have, especially when they get into multi-stakeholder retail scenarios (e.g., things like splitting a net-90 invoiced order between multiple future dates, vendors and warehouses, and logistics providers, while acting as a subledger that can handle revenue and income recognition properly).
It's worth considering a composable commerce SaaS. Many let you pick and choose the pieces you need, so you can fill out the remaining components and only replace what you built if their version brings significant value.
At this point, the answer is always buy and then build later if necessary. Just as we once questioned building a server vs using the cloud, using pre-built flexible components gets you to market faster.
Just be careful as the market right now has many monoliths and old systems claiming to be "headless" and "composable", but in reality Magento, Salesforce, Oracle, etc. are all expensive to work with and should only be considered for basic needs.
Looking at a marketplace you can consider marketplace specific vendors like mirakl and convictional, but being niche they can be very expensive. I would instead look at composable commerce solutions that are very flexible and can meet your marketplace needs.
If you're building a marketplace, your SaaS offerings are more limited because the functionality diverges from B2C Retail... as you've probably (re)discovered, content moderation and approval for catalog information from your third-party sellers is crucial[0] and you'll need to solve interesting problems in promoting and suppressing search results when the business asks you to support paid partnerships with some third-party sellers as "official resellers" or sponsored listings.
Right now Mirakl is the big incumbent in marketplace APIs, but whether that's the right answer will depend on your company's scale, technical capabilities, and margins.
I feel like this really is for like a small percentage of companies. If you're already significantly investing in developers to build out a customized front end and infrastructure dev ops, eventually you might move to invest in the back end as well.
I will likely always advocate for Shopify as long as they continue to strive to make commerce better for everyone.
As a developer, hosted Shopify is extremely powerful and enables the ability for merchants to create awesome personalized commerce experiences for their customers.
Shopify is great and if you want to start selling in minutes (literally) or do not have complex back-end requirements I highly recommend you use it. (In fact, I believe they have a sale on their plans as of the time of this comment in case you are interested in checking it out.)
Headless e-commerce has been growing lately. See the MACH Alliance [1] to find out about closed-source platforms in this space. One thing to note is that we can see more and more specialization, new categories, such as headless loyalty/PIM/search etc., appeared on the market. Earlier this year, I wrote a short article [2] explaining what problems these APIs try to solve (sorry for the clickbait title).
I've been following https://www.shopware.com/en/ for a couple years. Awesome to see how they've grown in the space. Since it's written in PHP, I feel like it's a great replacement for Magento, especially as Adobe's catered more towards enterprise customers.
Nacelle is another. This is a very industry/salesy website, but they recommend a load of the most mature headless software platforms and integrators for stuff like ecomm and CMS:
Saleor.io is a good start. Consider Medusa and Vendure if you want to stay open-source.
If you are interested in SaaS, look at Elastic Path.
I see a lot of people recommending the MACH Alliance. That is a marketing organization where members pay in to push their products. Nothing wrong with MACH technology, but worth understanding what it is before going down that road.
Does someone have a good introduction do micro-frontends? All I see is third-party widgets implemented using iframes or Web Components, and that is usually a nightmare for front-end performance.
Your understanding is one approach, but the composition can occur anywhere in the pipeline from SSR to client runtime composition, or in-between (example: at a CDN). eCommerce CAN be a good example, as things like the shopping cart, product catalog and recommendations split nicely on the front end without (typically) sharing backend or state. It helps to look at examples, some notable ones being the Spotify "adventure" and Dazn, as well as Ikea's overall philosophy & motivation for a variant on micro front ends (vertically segmented systems).
Came here to say Magento is NOT now called "Adobe Commerce". Magento Commerce is now called Adobe Commerce. "Magento Community" is now called Magento. That's all. That's the comment.
Amazon.com and other major online commerce players are also headless. Different, evolving front ends (think native or web views on iOS or Android, React, vanilla JS, angular, …) have a direct endpoint, which integrates with different services like product catalog, cart, checkout, recommendations).
[+] [-] cnj|3 years ago|reply
The movement towards "headless", API-first platforms has a lot of steam. So much so that older platforms (e.g. Salesforce) are jumping on the bandwagon to stay relevant in the market.
That said, I know there are a lot of startup-focussed readers on HN. This trend is for larger companies who want to really own their customer experience, including their own frontend. You'll have more flexibility, and using an API-first platform will be a lot less work than writing your own backend, but... it's still more work.
If you are small, you need a quick MVP etc. going with a Shopify or BigCommerce is the faster way to start selling. Once you've got a good stream of revenue and you're feeling these platforms are too rigid, looking for an API-first platform is a good idea!
[+] [-] disantlor|3 years ago|reply
I’ve come into working on multiple different headless sites developed by others who then walked away and left an entirely non-technical team to sort it out.
A well-built Shopify theme works great and plenty fast for even medium sized companies.
[+] [-] softfalcon|3 years ago|reply
It’s important to not just choose the correct tool for the job, but also be aware of the scale of tool you need.
There are hammers, and then there are pneumatic powered nail guns, which one do YOU need?
[+] [-] wintogreen74|3 years ago|reply
[+] [-] jebronie|3 years ago|reply
[+] [-] JLuterek|3 years ago|reply
Startups can have great success going API-First, but it's contingent on working with the right company.
[+] [-] subpixel|3 years ago|reply
Tools at the CommerceTools level address “large company” problems first and foremost, some of which are real and others imaginary, often to the detriment of the customer experience.
This isn’t a criticism of anyone’s technology but more of an observation of how things are very different when the customer is a billion dollar enterprise.
[+] [-] swalsh|3 years ago|reply
If you were small, you don't even get the privlidge of an inventory file. Vendors don't have time to deal with small guys, and it can be super difficult to get started.
Playing with crypto, and NFT's, I realized this was what I wish was the norm. The indexers were close to real-time. The chain I was using (AVAX) had a finality of 4 seconds, and gas is cents.
What i'm going to describe isn't a solution to a problem the big guys have. They had enough sway with their vendors to get good systems. But for small guys like me, open access to automated systems would have been a god send. My dream system would be something like this:
Think of this happening in a subnet (an app specific blockchain that doesn't share space with other apps, so scale is not affected by other apps)
1. A Trusted supplier mints a NFT for each of their SKU's (yeah trust and crypto don't go together ideologically, that's a purity problem crypto needs to get over itself, sometimes trust is useful... if you try to build the whole thing trustless, it's not better than traditional systems).
2. These NFT's are listed in any NFT marketplace that cares to list them. (with subnet-to-subnet messaging, you don't need to duplicate the contracts... so shouldn't have major scale issue. This is a brand new feature, so i'm not super sure though.)
3. I as a small scale vendor list a sku on my normal site. I can take payment as normal, but then I can call the NFT's index to get real-time inventory (even though I have no preexisting relationship with the vendor)
4. I get an order, I buy the NFT off the marketplace, and burn the NFT. My customers details are provided in the NFT burn contract. An app specific precompile let's me transmit those details to the vendor without making it public on the block chain (with proof it received it correctly).
5. After the NFT is burned, an ERC20 token is dropped in my stores wallet. After I get enough of these, I can trade them in for a volme rebate. This let's the small vendors get access to effectively what is a volume discount.
I suppose this could be a SaSS app, but there's a bunch of side benefits to crypto, such as defi, tooling etc. But mainly vendors can customize their own terms if they own the full contract chain.
[+] [-] damienwebdev|3 years ago|reply
I'm one of the maintainers of MageOS (a fork of Magento) as well as a maintainer of Daffodil (a monolithic Angular PWA framework - not Microfrontends yet).
APIS are definitely the way to go but, while that's a great next step, what we're really facing is a standards issues.
Some have tried.
Schema.org as a standard is overly complex and each platform has their own API definition.
Microfrontends can be great as well, but ecommerce has a particularly special problem of requiring extremely performant SSR, so that's always a critical and complex piece to get correct.
However, this article is clearly an ad.
[+] [-] calvinmorrison|3 years ago|reply
I haven't seen Magento - under Ebay, under Adobe, under anyone address what I think is the biggest issue facing them - total cost of ownership in comparison to the competition.
Is mageOS mostly just a maintainence mode, keep this alive till everyone can switch off (like the M1 forks that exist) or do you actually envision trying to solve some of the challenges magento is facing as a community and platform?
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] amoopa|3 years ago|reply
Aside from the frontend flexibility, one major advantage of building API-first in an ecommerce context is that it can allow different parts of the system to be developed and maintained independently. This can make it easier to update and extend individual components without affecting the overall system - which is often a headache with current systems such as Shopify, Magento etc.
IMO, One of the most interesting nuances in the space is the focus shift between OS and closed-source solutions in this space. The problem for larger companies (+$50M) is that they seek to build something their tech teams can take full ownership of and easily inject custom logic into. This is not as easy with proprietary solutions even if they are headless and API-first. Instead these businesses end up looking into either building something fully custom or seek out open source solutions like Medusa (JS/TS), Sylius (PHP) or Spree (Ruby) to use as a foundation to build a custom setup from.
In general though, the headless / API-first trend definitely seem to be something that a lot of companies are exploring at the moment.
[+] [-] calvinmorrison|3 years ago|reply
The trend I see continuing is the commidification and standardization of ecommerce platforms, with Shopify and BigCommerce continuing to chomp away at former giants like Magento (now Adobe Commerce). For most companies, the TCO of an ecommerce platform is an important driver in the decision making process. Companies often balk at the demands of shopify (around what you can and can't do) but then come to terms with it and select shopify as their platform.
For anyone with real budgets (like Nike.com) - totally custom, or building on a practically custom (Adobe) site, there may be moves towards the headless trends, but for the most part, the people (SMB) I deal with do not care about the technology, they just want a short time to launch and a low cost. So for me, I've seen a shift towards to low/no-code platforms and low cost. In the headless space I think fabric is particularly interesting, though I do think Adobe has a chance to do it correctly, but overall, I've sat in on several pitches for going headless and the total cost in just doesn't seem to be worth it.
[+] [-] coastermug|3 years ago|reply
[+] [-] leviathant|3 years ago|reply
Of course, everyone in the space is scrambling to say they're headless, because commercetools has absolutely changed the conversation in the ecommerce space, but it's not some magic bullet. It's an architectural decision that should be informed by business needs, e.g. supporting multiple regions, multiple brands, or sharing one backend between your website, app, and in-store experiences. Handily, it does serve as a salve to front-end issues inherent to the all-in-one approach that was so dominant a decade ago. By decoupling the frontend from platforms like Shopify Plus or Salesforce, you get a taste of the speed and freedom that comes with a modern front-end, but also quickly run into no-go zones where even in 2022, there's no API access to important backend features - because there never will be, because that messes with the business model of these platforms.
On the bright side, even taking legacy monolithic platforms like that headless will make it easier to migrate to a more robust API-first backend solution when the time comes.
It certainly makes the most sense with the Nikes and the AT&Ts of the world. Substituting something like commercetools in for their in-house ecommerce systems offsets a huge amount of technical debt, and lets internal teams focus on being more effective at doing whatever makes Nike different from Puma. And while a digital transformation to a MACH approach sometimes has a higher up front cost, companies are clamoring to get away from the millions they spend in maintenance on versioned legacy stacks like Hybris and Salesforce.
[+] [-] fein|3 years ago|reply
Just about everything is going to AEM with elastic path/ some other ecomm apis and headless frontends (mostly React, namely NextJS, some unfortunately on Gatsby).
I'm not sure what is happening with all the old Magento platforms since Adobe took it over, but I don't think we do much work in Magento any more.
[+] [-] moneywoes|3 years ago|reply
Wondering where to focus
[+] [-] hn_throwaway_99|3 years ago|reply
[+] [-] btown|3 years ago|reply
To that point though - there's no transcript for the podcast. I try to at least describe some technical merit whenever I write a comment like this on HN, perhaps because I would hope that others would do the same if I were to arrange for sponsored content!
But I'm not going to sit through an hour of content and transcribe a quote vs. skimming a transcript to find something cool to highlight. And this isn't even getting into how the lack of a transcript signals how little the brand prioritizes accessibility!
Brands - there's no excuse not to have a machine-initiated human-edited transcript of any corporate podcast when things like OpenAI Whisper exist. Make sure the partners publishing your content are incentivized to do this as well.
[+] [-] JLCarveth|3 years ago|reply
[+] [-] ta3411|3 years ago|reply
[+] [-] wintogreen74|3 years ago|reply
Take a single one of your items: inventory management. There's SOOO much going on here, people look and say "What's the big deal? decrement an integer!" How do you handle payment failures and dunning management? Subscriptions? Bundles? Incomplete carts? Buy online; pick-up in store? blended inventories? multiple locations? The list goes on and the number of interconnected components makes this really hard to solve.
You're building all this, a marketplace and front ends for web & mobile? With a team of 7? I had a team of 23 and struggled to stay on top of all the nuances in just subscriptions, so you're (a) missing important use-cases or (b) way more effective than my former team. Chances are it's somewhere in between.
[+] [-] HillRat|3 years ago|reply
In turn, depending on your needs and the regulatory regimes you're working under, you may find that you could have saved time and money going with an industrial-grade solution that can seamlessly handle taxes, accounting and revenue recognition, multi-vendor logistics, credit/refunds, reverse logistics, etc. (there's a lot of etc.!), but that could be overkill for your requirements. I've seen SMBs with small digital teams build and run bespoke e-comm solutions handling all their needs (and more effectively than trying to fit a commercial square peg into a round hole), but the more complex and general their use cases, the more trouble they tend to have, especially when they get into multi-stakeholder retail scenarios (e.g., things like splitting a net-90 invoiced order between multiple future dates, vendors and warehouses, and logistics providers, while acting as a subledger that can handle revenue and income recognition properly).
[+] [-] JLuterek|3 years ago|reply
At this point, the answer is always buy and then build later if necessary. Just as we once questioned building a server vs using the cloud, using pre-built flexible components gets you to market faster.
Just be careful as the market right now has many monoliths and old systems claiming to be "headless" and "composable", but in reality Magento, Salesforce, Oracle, etc. are all expensive to work with and should only be considered for basic needs.
Looking at a marketplace you can consider marketplace specific vendors like mirakl and convictional, but being niche they can be very expensive. I would instead look at composable commerce solutions that are very flexible and can meet your marketplace needs.
[+] [-] eastbayjake|3 years ago|reply
Right now Mirakl is the big incumbent in marketplace APIs, but whether that's the right answer will depend on your company's scale, technical capabilities, and margins.
[0] I keep a folder of examples of unmoderated third-party seller content embarrassing large companies running marketplaces, this one is my go-to example: https://www.independent.co.uk/news/world/americas/ashli-babb...
[+] [-] angryasian|3 years ago|reply
[+] [-] RobDukarski|3 years ago|reply
As a developer, hosted Shopify is extremely powerful and enables the ability for merchants to create awesome personalized commerce experiences for their customers.
Shopify is great and if you want to start selling in minutes (literally) or do not have complex back-end requirements I highly recommend you use it. (In fact, I believe they have a sale on their plans as of the time of this comment in case you are interested in checking it out.)
[+] [-] lagrange77|3 years ago|reply
[+] [-] ssharp|3 years ago|reply
https://hydrogen.shopify.dev
[+] [-] sedzia|3 years ago|reply
[1] https://www.machalliance.com/members
[2] https://dev.to/voucherify/whats-mach-and-how-it-can-make-you...
[+] [-] intrasight|3 years ago|reply
[+] [-] dotty-|3 years ago|reply
[+] [-] tootie|3 years ago|reply
https://machalliance.org/
[+] [-] amoopa|3 years ago|reply
Of proprietary solutions Commercetools & Fabric are often mentioned among larger commerce businesses.
[+] [-] JLuterek|3 years ago|reply
If you are interested in SaaS, look at Elastic Path.
I see a lot of people recommending the MACH Alliance. That is a marketing organization where members pay in to push their products. Nothing wrong with MACH technology, but worth understanding what it is before going down that road.
[+] [-] pwillia7|3 years ago|reply
[+] [-] sebrindom|3 years ago|reply
[+] [-] tmnvix|3 years ago|reply
https://snipcart.com/
[+] [-] tbassetto|3 years ago|reply
[+] [-] wintogreen74|3 years ago|reply
[+] [-] buttersbrian|3 years ago|reply
[+] [-] subtledigital|3 years ago|reply
The cost to implement and maintain a headless ecomm site is leagues away from a monolithic store.
Plugins that just worked with your Shopify store no longer work and require custom api dev/integration.
Want a new section built or a small thing changed? That’s going to require design and dev.
I’ve spoken to a few larger brands that have actually went back to their old monolithic store after spending hundreds of thousands switching.
The future is headless but not just yet.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] s1k3s|3 years ago|reply
[+] [-] peterjaap|3 years ago|reply
[+] [-] ushakov|3 years ago|reply
[+] [-] birdhouse|3 years ago|reply
[+] [-] jebronie|3 years ago|reply