That's how CS Shop started.

We never planned to build an e-commerce platform.

In fact, for a long time, we actively avoided e-commerce projects.

There were already plenty of platforms for building online stores. WooCommerce, Magento, PrestaShop, Shopify and a growing list of others could get a store online quickly.

And that wasn't really the kind of work we wanted to do.

We were a small development company, still working out of a garage at the time, much more interested in building software than configuring somebody else's commerce platform.

We wanted to build systems.

Not install plugins.

So when e-commerce projects came up, our answer was usually simple:

there are already good tools for that. Use one of them.

Then one client wouldn't take that answer.

The client who insisted

They needed an e-commerce system.

And they wanted us to build it.

We suggested the obvious alternatives.

Use an existing platform. Customize it. Integrate whatever else the business needs. Don't spend money building something that already exists.

They still wanted us to do it.

The conversations continued for a while until we eventually agreed — but with a fairly unusual arrangement.

If we were going to invest the time into building an e-commerce system properly, we didn't want to build another one-off project that would belong to a single implementation and disappear there.

We wanted the underlying code and product to remain ours.

So we made a deal.

The client funded a relatively small part of the development.

We invested the rest.

In return, they would get the system they needed, while we would retain the product and the ability to continue developing it.

At the time, it seemed like a reasonable experiment.

It turned out to be the beginning of CS Shop.

We thought we were building a webshop

The first version had a fairly obvious scope.

Products.

Categories.

Customers.

Cart.

Checkout.

Orders.

Payments.

The usual things.

And if that had been where the problem ended, we probably wouldn't be writing about it today.

Because once the first version started becoming a real system for a real business, the requirements stopped looking like a list of webshop features.

Different customers needed different prices.

Business customers behaved differently from consumers.

Products had to arrive from external sources.

Orders had to leave the shop and continue through other business processes.

Invoices mattered.

Stock mattered.

Payments had to be reconciled.

Content needed to be managed.

Other systems needed to be integrated.

And exceptions appeared everywhere.

The simple model:

product → cart → checkout → order

started becoming something much closer to:

customer
   ├── B2C
   ├── B2B
   └── partner

product
   ├── catalog
   ├── pricing
   ├── availability
   └── supplier data

order
   ├── payment
   ├── invoice
   ├── fiscalization
   ├── stock
   ├── fulfillment
   ├── notifications
   └── accounting

At some point we had to admit something.

We weren't really building a webshop anymore.

We were building commerce software.

The storefront was the easy part

The part customers see is relatively straightforward.

Show products.

Let people find them.

Put something in a cart.

Pay.

The difficult part starts behind that.

A B2B customer doesn't necessarily have the same price as a consumer.

A company may have several users.

Somebody may be allowed to place an order but not manage the account.

A supplier might send product data in a CSV file that doesn't quite match yesterday's CSV file.

An order may need to produce an invoice, fiscal data, a warehouse action and an accounting entry.

A business may operate several storefronts but still want one operational system behind them.

These aren't unusual edge cases.

They're normal business.

And every time we solved one of them, CS Shop became a little less like the webshop we originally agreed to build and a little more like the platform underneath it.

Then another project needed the same thing

This is where the story started repeating itself.

Another project needed commerce.

Then another.

They weren't identical businesses, and we didn't want them to be.

But many of the underlying problems were familiar.

We already had customers and organizations.

We already had product models.

We already had pricing.

We already had order processing.

We had imports.

We had integrations.

And we had learned where some of the bad assumptions were in the first implementation.

So instead of starting again, we improved what we already had.

Some features became more general.

Some stayed specific to individual projects.

Some things we originally thought were reusable turned out not to be.

And some things we built for one customer eventually became useful to almost every commerce project that followed.

That process is still happening.

CS Shop was never designed on a whiteboard

There wasn't a meeting where we decided:

Let's build an e-commerce platform.

There wasn't a market analysis followed by a product roadmap.

We didn't look at WooCommerce or Shopify and decide that the world needed another alternative.

Quite the opposite.

We didn't want to build one.

CS Shop exists because a client insisted on solving a problem with us, and because we decided that if we were going to make that investment, the engineering should survive beyond a single project.

The client funded part of it.

We invested most of the development ourselves.

And production did the rest.

Real products, real orders, real integrations and real businesses gradually shaped what the platform became.

We still don't want to compete with WooCommerce

That's important.

If somebody needs a straightforward online store and an existing platform solves the problem well, they should probably use it.

We have no interest in rebuilding solved problems just so that everything runs on our code.

CS Shop becomes interesting when the shop is only one part of a larger system.

When B2C and B2B need to coexist.

When pricing isn't simple.

When products come from multiple sources.

When several sites share parts of the same operation.

When orders need to connect to invoicing, fiscalization, accounting or other internal systems.

When the business doesn't fit comfortably inside a collection of plugins.

That's the kind of problem that got us here in the first place.

From a client project to a product

Today, CS Shop is very different from that first implementation.

Some of its foundations now come from the same shared engineering capabilities we use across our other systems.

Other parts exist specifically because of years of commerce requirements.

And every new implementation still teaches us something.

That original deal also shaped something broader about how we build software.

Sometimes a client needs something specific enough that an off-the-shelf product isn't a good fit, but general enough that solving the underlying problem has value beyond one project.

When that happens, there can be a better model than simply billing every hour and handing over a pile of source code.

Sometimes we invest too.

That's effectively what happened with CS Shop.

A client got the system they needed.

We took a much larger part of the development risk.

And we kept building on what came out of it.

There was no grand plan to enter e-commerce.

There was a client who wouldn't let us say no, a small team working out of a garage, and a decision to invest most of the development ourselves rather than build the same thing once and throw the experience away.

That's how CS Shop started.

And, somewhat ironically, the e-commerce platform we never wanted to build became one of the systems we've spent the most time learning from.