Most WordPress plugins don’t start with a grand roadmap.
They start with friction.
Mini Shop started that way too.
I wasn’t trying to build “another eCommerce platform.” I was trying to solve a very specific problem: selling simple products on WordPress without inheriting unnecessary complexity.
This post is a snapshot of the thinking, trade-offs, and lessons that shaped Mini Shop while it was being built.
The Problem That Triggered Everything
If you’ve built sites with WordPress long enough, you’ve probably felt this:
“I just need a small shop. Why does everything feel so heavy?”
WooCommerce is powerful. There’s no denying that.
But power comes with cost:
- More tables than you understand
- Dozens of hooks firing on every request
- Admin screens that feel slow even on good hosting
- Features you don’t need but can’t easily remove
For many sites — blogs, landing sites, product microsites — this felt like over-commitment.
I wanted something smaller.
A Simple Question That Changed the Direction
Instead of asking:
“How do I build a full eCommerce system?”
I asked:
“What is the minimum required to sell products well?”
The answer was surprisingly short:
- Products
- Cart
- Checkout
- Orders
- Payments
Everything else is optional.
That question became the foundation of Mini Shop.
WordPress-Native First (Always)
One rule guided every decision:
If WordPress already does something well, don’t replace it.
That meant:
- No custom framework on the frontend
- No unnecessary abstractions
- No fighting core WordPress behavior
What that looks like in practice
- Custom database tables, but still using
$wpdb - REST API, but with WordPress nonces and capability checks
- Shortcodes instead of forcing a page builder
- Templates that work with any theme
The goal wasn’t to be clever — it was to be predictable.
React Where It Makes Sense (Admin Only)
The admin experience matters.
Managing products and orders inside classic WordPress screens can feel dated and fragmented. React shines here, so Mini Shop uses:
- A React-powered admin dashboard
- REST-backed data
- Clear, focused screens for products and orders
But React stops at the admin.
The storefront stays framework-free on purpose.
Why?
Because:
- Themes already handle layout
- Users don’t want JS-heavy carts
- Performance matters more than fancy transitions
This separation keeps things fast and maintainable.
Payment Architecture: Small but Extensible
Payments are where plugins often get messy.
From day one, Mini Shop was built with:
- A gateway interface
- A registration system
- No hard-coded assumptions
That’s why adding Stripe, PayPal, or Cash on Delivery didn’t require rewriting core logic.
Even better: future gateways can plug in without touching existing code.
This matters — not just for features, but for trust.
What I Deliberately Didn’t Build
Just as important as what’s included is what’s missing.
Mini Shop does not try to be:
- A subscription engine
- A marketplace platform
- A multi-vendor system
- A replacement for WooCommerce
Those problems deserve dedicated tools.
Mini Shop focuses on one thing:
Selling products simply and reliably.
Building in Public (Without the Noise)
This plugin is being built quietly.
No launch hype.
No “ultimate alternative” claims.
No rushed features.
Every part exists because it’s needed — not because it looks good on a feature list.
Writing posts like this is part of that process.
It helps me:
- Clarify decisions
- Document trade-offs
- Share lessons honestly
If it helps others along the way, even better.
What Comes Next
Right now, the focus is simple:
- Make the free version solid
- Improve documentation
- Listen to real usage
- Keep things lightweight
There’s plenty of room to grow — but growth should feel natural, not forced.
Final Thought
Mini Shop isn’t trying to win a feature race.
It’s trying to respect:
- The site owner’s time
- The server’s resources
- The developer’s sanity
This post was written in the middle of building it — and that’s exactly how it’s meant to be read.