Endora Commerce from the inside – why I decided to build our own B2B platform

For over a decade we implemented e-commerce platforms for other companies. Magento, Shopware, Sylius — we know these systems very well, with all their strengths and limitations. At some point I came to the conclusion that the most honest thing we could do for potential clients was to show a working system instead of yet another set of slides. This was not a “let’s build our own product” project. It was a “stop telling, start showing” project.

---

The moment I decided to change something

I remember a specific meeting. A client from the industrial distribution sector, a serious company, four hours of workshops. We knew what to build: a pricing engine, RFQ, a multi-warehouse management panel, ERP integration. We had good references, a solid quote, a well-thought-out roadmap.

At the end came the question: can we see this somewhere? Something that actually works?

I showed screenshots from previous implementations. A demo video from YouTube. An architecture overview.

And I could see it wasn’t enough. Not because the client didn’t trust us. But they couldn’t picture, based on those materials, how their sales reps would place orders, how an administrator would update a price list, how a buyer would see their individual prices. That meeting didn’t end with a contract. It ended with a month of emails, an additional workshop and a project with another agency.

For the next year I got the same question in different forms. And every time I answered with the same thing: promises and references.

At some point I told myself: enough.

---

Why not Magento or Shopware

When I decided we were building our own platform — a real one, not a presentation prototype — the first decision came surprisingly fast: we’re not building on Magento or Shopware.

Not because they’re bad platforms. We’ve implemented dozens of them. But each carries a decade and a half of architectural decisions, not all of them sound. Plugins, configurations, cache, indexers. Before you write the first line of business code, you spend three days setting up the environment.

I wanted the demo to be live. I wanted a settings change in the admin panel to be visible immediately on the storefront. I wanted the path “change the price list for a customer group, go to storefront, price is different” to take two seconds, not thirty.

I went with Next.js on the frontend and an API-first architecture on the backend. Zero off-the-shelf solutions where we want full control. Ready-made libraries where control is not critical.

That was a good decision and one of the few I had no doubts about from the start.

---

How we built it

Spec-Driven Development — the methodology we use in client projects — starts with a specification. Before you write code, you write functional requirements: what the system does, how it behaves in edge cases, what constitutes a passing test.

I assumed it would be easier for our own product. I know the industry, I know B2B client needs, I know what I want.

I was wrong.

Being both the client and the project team at the same time is a strange experience. There is no one to ask “why this way?” There is no external pressure forcing priorities. Everything seems equally important.

The first version of the pricing module specification was fifteen pages and covered every possible edge case. It was perfect and completely useless as a starting point — because I didn’t know what I needed to build this week in order to have anything to show. The lesson: the better you know a domain, the harder it is to choose the minimum.

I gave myself a concrete constraint: the MVP must work as a demo for an industrial distributor. One scenario, one user type, one product type. Everything else later. That unblocked the work.

---

AI as a pair programmer

I’m not writing about Endora Commerce as an “AI-assisted project” because it’s a trendy phrase. I’m writing it because without AI this project would have taken twice as long.

I worked with Claude as a pair programmer. I wrote a module specification in natural language, Claude wrote unit and integration tests, then the implementation against those tests. My contribution was code review and correcting business logic where AI made mistakes in understanding the domain.

This is a different experience from “please write me some code.” AI that sees the full context of a specification writes sensibly. AI that gets a standalone “write me a pricing module” writes something that looks like a pricing module but behaves like a random idea generator.

Spec-Driven Development and AI are a natural pair: AI is only as good as the question you ask it. A good specification is a good question.

One of the platform’s features is an AI assistant controlled by natural language — you open the command palette ⌘K, type in plain English “assign product X to category Y and set the price to £450 for the wholesale customer group”, the system shows a plan and waits for confirmation. I built this feature to have it in the product, but also because I wanted to use it myself during the build. Dog fooding in real time.

---

The moment it worked

At the end of the fourth week I logged into the storefront as buyer@demo-org.example. I saw a catalogue with prices. I added products to the cart. I placed an order through RFQ.

Then I logged into the admin panel. I saw the order. I changed the status.

I went back to the storefront. The status was updated.

That sounds trivial. But after weeks of building module by module, where each one worked separately, seeing them together as a coherent flow is something else. I took a screenshot and sent it to three people. “It works.”

---

Being your own first client

Endora Commerce handles our internal processes: configuring demos for prospects, managing environments, change history. And that is the most valuable part of the entire project. Not any feature, not the architecture, not the AI.

When you use a system you authored, you discover things that were invisible during the build.

Example: the AI assistant in the panel is excellent when you know exactly what you want. When you want to “somehow” modify a product but don’t know how to phrase the command to get what you have in mind — that’s not a software bug. It’s information: deploying an AI assistant requires time to learn how to talk to it. Clients need to be told this.

If I had learned this from a client after deployment, it would have been a red flag in the retrospective. I learned it myself before it went to anyone. I fixed the onboarding.

That’s why it’s worth being the first client of your own product. Not because “every startup guru says so.” Because the pain points you feel yourself, you fix in an hour. The pain points your client feels, you fix after a week for the ticket and a week for the deployment.

---

What surprised me

I expected four weeks to MVP to be an aggressive target. It turned out to be achievable. AI reduced implementation time on well-specified modules by 30–40%. That was enough to fit within the window.

I expected the pricing engine to be the hardest part. It turned out to be one of the faster modules, because the requirements were precise and the business logic, though complex, was well described. The hardest was the sales channel module — because “what does it mean” differed every time I thought about it.

The hardest thing turned out to be being both client and agency at the same time. With a client project there is external pressure, deadlines, someone saying “I need to present this to the board in three weeks.” With your own project you have to create that pressure yourself. That is harder than I thought.

And then there was the moment when the demo went into its first sales meeting. The client looked at it, sat down at the laptop and spent twenty minutes testing without asking me questions, without asking for explanations. Just checking. It was different from every previous meeting.

---

Where it is now

Endora Commerce is available — not as a SaaS package you install, but as a platform we build together with the client on its architecture and modules, tailored to a specific industry and processes.

A working demo is available without registration and without a sales call as a prerequisite:

Demo storefront → — log in as buyer@demo-org.example / ChangeMe!123 and walk through the B2B purchase path

Demo admin panel → — log in as admin@demo.local / ChangeMe!123 and see what managing the platform looks like from the inside

If you’re interested in the whole process from the agency side — how the demo shortens the B2B sales cycle, what the workshop → prototype → decision flow looks like — I described it in detail in the Endora Commerce case study.

---

One last thing

I didn’t build Endora Commerce to sell it. I built it to have something real to show.

Paradoxically, that makes it better than if I had built it with selling in mind. I build it with usage in mind. And that is, as I discovered over these months, the only measure that makes sense when building anything.

A client who tests the demo themselves before signing anything understands what they’re buying. They don’t imagine it. They know.

That changes the dynamic of the sales conversation — from “trust us” to “try it yourself.” And for several years that was the only thing I was missing.

---

Endora specialises in B2B e-commerce platforms — both implementations on Magento, Shopware and Sylius, and dedicated solutions such as Endora Commerce. If you’re considering a B2B platform for your company — book a free consultation.