About5 min read
Ecommerce Development: Four Different Jobs, One Phrase
The phrase covers four jobs priced between a few hundred dollars and a few hundred thousand, and nobody selling it has an incentive to tell you which one you are buying. Two questions decide it, and both are about your business.
By Juan Molina
On this page
Ecommerce development is one of those phrases that covers four completely different jobs, priced between a few hundred dollars and a few hundred thousand, and the agencies who use the phrase have no incentive to tell you which one you are buying.
So this is the version that separates them. Which of the four you need is decided by two questions, and both are about your business rather than about technology.
The four jobs that all get called ecommerce development
1. Setting up a hosted store
Someone configures Shopify or BigCommerce, picks a theme, adjusts colours and fonts, loads your products, connects payments and shipping, installs the apps you need.
This is a real job done well or badly, and it is not programming. If somebody quotes you forty thousand dollars for it, you are paying for project management and taste, which can be worth it, but you should know that is what you are buying.
2. Theme and template work
Modifying a hosted platform's theme beyond what its settings allow. Real code, in the platform's own template language, inside the platform's constraints.
The thing to understand here is the ceiling. Some requests are a small change to a template. Others are impossible because the platform does not expose the data or the hook, and no budget changes that. A developer who tells you which of the two your request is has done you a favour.
3. Building a storefront against an API
A separate front end application, written in a normal framework, talking to a commerce backend over HTTP. The backend holds the catalog, orders and payments; the storefront is yours.
This is headless commerce, and it is the shape most people mean when they say custom without meaning from scratch. You own the customer-facing half and rent the transactional half.
4. Building the whole thing
Storefront and backend, both written for you. Catalog, cart, checkout, payments, tax, shipping, orders, refunds, admin.
Occasionally correct, usually not. Most businesses that reach for this need one unusual thing sitting on top of a completely ordinary catalog and checkout, which is job three with a custom feature attached.
Question one: who owns the storefront afterwards
This decides more than anything else and almost nobody asks it during the quote.
If the answer is that your team maintains it, jobs three and four are fine and the code should be in your repository under your account, not the agency's. If the answer is nobody, meaning you will change things through an interface, then jobs one and two are what you want, and buying job three leaves you with an application you cannot edit and a dependency on whoever wrote it.
There is no wrong answer. There is only the mismatch, and the mismatch is where most bad ecommerce projects come from.
Question two: what do you sell
Two things about your catalog change the answer.
How complicated a product is. A t-shirt in four sizes and three colours fits every platform's model. Per-customer pricing, quantity breaks, a configurator, subscriptions with proration, or one backend serving several brands do not, and you will spend the project fighting the data model rather than building.
Whether anyone will refuse you. Hemp, THCA, kratom, vape, firearms accessories, certain supplements. Each platform draws its own line and payment processing draws another line behind it. If you are near one of those lines, this question outranks every feature comparison, because the best-built store in the world is worthless if the platform closes your account.
What the quotes do not include
Roughly in order of how often they are forgotten.
Content. Product photography, descriptions, category copy. Frequently more work than the build, and almost always yours.
Migration. Moving an existing store means your URLs change. Get the redirects wrong and you lose rankings you spent years earning. This is a real workstream, not an afternoon.
Integrations. Accounting, email, ERP, a supplier feed. Each is its own small project and each one is usually scoped as a line item that says integration.
Everything after launch. Dependencies age, platforms change their APIs, browsers change. A store is not a thing you buy once, and a quote with no answer for month seven is incomplete.
Questions worth asking any agency
Who owns the code and the accounts when we are done. What happens if we stop working together in a year. Which of the four jobs above is this quote for. What is explicitly not included. And, if you sell anything near a line: have you read this platform's acceptable use policy for our category, on their site, this month.
The answers matter less than whether they are direct.
Where we fit, and where we do not
dashfordevs is the backend half of job three. Catalog, carts, checkout, orders, customers, inventory and shipping behind an API, so your developer or agency writes the storefront and does not rebuild the transactional core. We also take the categories hosted platforms decline, which is why a lot of people find us.
Where we are the wrong answer: if you need job one, a hosted platform is genuinely better and cheaper and you should take it. If nobody will be writing front end code, our model does not fit at all. And if your catalog is simple and your category is uncontroversial, the standard advice is the right advice.
If you are scoping job three and want to know what the backend half actually gives you, the docs are open.
