We've spent the last few months heads-down working on the future of e-commerce development: fast project setup, modular architecture, and complete transparency for developers at every layer of the stack.
We've rethought how developers interact with the platform from project initialization to deployment.
Here's what we've been working on and what's coming next.
From Storefront to Platform - Rethinking the Nimara
Traditionally, a storefront is just the frontend layer sitting on top of a backend like Saleor - and that's precisely how Nimara started. But we're rethinking that and moving toward a more platform-oriented architecture.
What began as a frontend is evolving into a complete foundation for launching a real, production-ready commerce setup. That means not just UI but all the integrations you need: payments, CMS, search, and more.
The Nimara Storefront is now a complex component: a composition of smaller frontend modules, infrastructure elements, and services. You may think of it less like a single app and more like a curated bundle of interoperable tools tailored for composable commerce projects.
The Nimara Storefront is no longer just a front but a system of reusable pieces. It gives you everything you need to set up a working online store. This unlocks real composability for projects of any size
Wojtek Oksiński, Principal Product Engineer at Mirumee
Modular Architecture with Submodules
We've broken Nimara down into reusable parts, so each service now lives in its own Git repo:
Nimara Mailer(notifications),Nimara Stripe(payments),Nimara Storefront(frontend),- ...and more to come.
Using Git submodules, you will be able to fork, plug in, and extend components without disrupting the platform.
And yes, we're aware that monorepos have their perks. However, submodules will give us finer control over versioning and dependencies, especially when different teams own different components.
Clean Starts with platform-init
A new starter repository, platform-init, will act as the foundation for every Nimara project going forward. It's minimal, clean, and structured for real-life use cases.
You can easily add components or features based on your project’s needs:
- A Next.js Storefront, ready to be themed and extended
- A Stripe backend written in Python, modular and isolated
- A transparent DevOps layer with tools and deployment scaffolding
This structure eliminates configuration guesswork and lets you launch projects in minutes instead of days.
Repeatable Integrations with the Recipe System
One of the most significant pain points in headless development is redoing the same setups over and over. So, we created something we called recipes.
A Nimara recipe is a self-contained integration package that includes:
- Clear setup instructions (manual and CLI-compatible)
- Required environment variables
- Dependencies and connection logic
- Git visibility rules (for public/private modules)
We're actively rolling out recipes for Stripe, ButterCMS, Sailor Engine, and more to dramatically simplify the onboarding of new projects (and developers).
Planned for the Future: The Nimara CLI
We plan to build a command-line tool tailored for Nimara projects to turn these workflows into real automation.
Early features will include:
nimara init: clone and prepare a clean project fromplatform-initnimara apply stripe: apply the Stripe backend recipe with all configs- Version and submodule handling under the hood
This will be powered by JSON or YAML manifest files describing each component’s behavior, dependencies, and integration needs.
Why We’re Going Modular (and Forkable)
We’ve chosen to keep our architecture decentralized. Instead of a bloated monorepo, we fork individual components per project.
Why?
- It gives teams more control over update cycles;
- reduces regression risk from shared code;
- and keeps integration testing isolated and focused.
It’s a more sustainable way to scale when you’re building tailored solutions across multiple clients or teams.
Infrastructure, But Transparent
We're also formalizing deployment across Nimara modules. That means each component will include:
- Terraform or Pulumi manifests
- Environment configuration guidelines
- Compatibility documentation
This ensures your infra isn’t a black box. You’ll know exactly what gets deployed and how.
Better ENV Management = Fewer Broken Setups
We’ve started embedding .env.example files and config validation into every recipe. For each environment variable, we also provide clear manuals on where to find the required values, so you’re never left guessing.
Eventually, the CLI will validate and set these up for you.
No more mystery bugs from missing variables. It's just a clean handoff from configuration to deployment.
Looking Ahead
You'll appreciate this shift if you've ever had to reverse-engineer someone else's dev environment just to get a storefront running.
Nimara is being shaped to:
- Remove hidden knowledge from the process,
- Encourage reuse across projects,
- Empower developers with predictable, scriptable workflows,
- And accelerate time to deployment.
Nimara is no longer just a storefront starter; it's becoming a complete framework for composable commerce. These updates are a step toward making composable commerce actually practical.
What’s Next?
Over the next few weeks, we’ll:
- Publish the
nimara-recipesrepository, - Test full project lifecycles in real conditions (including postmortems),
- Begin documenting standard setups for Saleor, Stripe, and Storefront,
- Increase end-to-end test coverage by adding more automated tests to ensure reliability and stability.
Stay Tuned
In the coming weeks, we'll publish more guides, recipes, and tooling, as well as a starter repo you can clone and use immediately.
Until then, if you're curious about what we're doing, want early access, or have ideas of your own:
Let’s make e-commerce development faster, cleaner, and genuinely fun to work with.
Have Questions or Ideas?
Drop us a message on Discord - we can’t wait to hear from you!
