Shoppex

Shoppex began as a practical shortcut at Xappee.

We were building e-commerce products for companies while the wider business handled sourcing, inventory, shipping, marketing, support, and returns. Every new store needed the same operational center: products, orders, sales, content, and settings.

The idea was simple. Build that dashboard once, then connect each client to a custom storefront.

The simple idea did not stay simple for long.

Where it started

I kept developing Shoppex after Xappee and used it for freelance commerce projects in Egypt.

Two clients ran their own deployments on a VPS. Across three months, those stores processed about EGP 400,000 in sales through the system.

That mattered to me because Shoppex was not only architecture on paper. Real products, orders, payments, and customers passed through it.

But I never gave the project my full attention. It kept growing between work, client delivery, and everything else.

What I built

Shoppex became a pnpm monorepo with:

• an Express and MongoDB API
• a Next.js operations dashboard
• shared TypeScript and Zod packages
• products, variants, categories, specifications, and media
• orders, users, team roles, invites, and settings
• PayPal, email infrastructure, and TOTP 2FA
• a separate image service using Sharp and worker threads
• Docker and PM2 deployment paths

The catalog was the strongest area. Real commerce data gets complicated fast, and the product model had to handle more than a title, price, and image.

The architecture bet

I used a main database for platform data such as users, tenants, roles, invites, and integrations. Each store had its own MongoDB database selected at runtime.

I liked the clarity of the isolation.

Then the operational cost arrived. Connection pooling, tenant context, reporting, deployments, and security boundaries all became harder before the core buying loop was finished.

The architecture was not nonsense. It was just early for the problem I had actually proved.

When the vision grew

The dashboard became only the first layer.

I imagined a storefront builder and CMS, AI inside product and order workflows, an advertising hub using product data and public ad examples, and eventually a marketplace across stores.

The weird thing is that I still think parts of that vision are good.

But a good vision can still be too large for one person, especially when the first complete loop has not earned the expansion yet.

Real signal

I entered Shoppex into a hackathon and won third place.

The award was useful, but the more important result was seeing the project through a business lens. I learned about market research, positioning, pitching, and just how large the real scope was.

That was the point where the potential became clearer and the cost of pursuing all of it alone became harder to ignore.

What I would change

I would start with a shared database and a strict tenant ID, good indexes, explicit access checks, and a clear permission model. Physical isolation should be earned by a real requirement.

More importantly, I would finish one complete commerce loop before widening the platform:

1. tenant setup
2. catalog
3. storefront browse
4. cart and checkout
5. payment confirmation
6. order management
7. fulfillment communication

Everything else should have to prove that it makes this loop stronger.

Gallery

What stayed with me

Shoppex taught me that impressive architecture can outrun the product.

I carried that lesson directly into PufferPOS. I still like ambitious systems. I still enjoy thinking several layers ahead. But now I ask a harder question before adding the next layer:

Is the workflow underneath it already real?

Architecture should protect a working product loop. It should not become a substitute for one.