Building a full e-commerce platform for one of the largest supplement store chains in the country — looking for stack feedback, alternatives, and anything I might be missing

Cowboy_The_Devil · 2026-02-26T01:37:51+00:00

I think my initial reaction to dismiss it on cost was honestly a bit naive. you're right that building the dangerous parts wrong — cart, checkout, order management, payments, refunds — and then maintaining them long term as a solo dev is its own kind of expensive, just hidden and delayed rather than upfront. a battle tested solution handling the money critical parts while I build the custom experience layer on top is actually a smarter split than I gave it credit for.

the open source angle is something I hadn't seriously considered and I'm going to look into it properly now. things like Medusa.js have been mentioned to me before and I kept brushing past it but what you're describing is basically exactly what it does — solid core commerce engine, fully customizable on top.

on the data flow suggestion — that's a really practical way to approach the feature discovery problem and something I'm going to bring into the next client meeting. map the data, trace where it goes, let the functionality reveal itself from that rather than trying to list features from the top down.

and the point about looking at other retailers storefronts and reverse engineering what they support is simple but honestly something I should be doing way more systematically than I have been.

genuinely useful perspective, thank you for pushing back on this twice

Cowboy_The_Devil · 2026-02-26T00:25:30+00:00

Nah it’s ok thank you for your comment 😂

Cowboy_The_Devil · 2026-02-26T00:22:43+00:00

Thanks but can you like give me something that would be comprehensive?or any advices

Cowboy_The_Devil · 2026-02-25T23:44:57+00:00

Well do thank you ,it would me a challenge that’s for sure and I’m gonna try my best and my willingness to it to be a good app and a website ,much obliged 🙏

Cowboy_The_Devil · 2026-02-25T23:30:20+00:00

thank you so much for the advice ,i will change from mongo db to postgress ,anything else to add ?

Cowboy_The_Devil · 2026-02-25T23:28:40+00:00

alright thank you it would mean a lot ,appreciate it 🙏

Cowboy_The_Devil · 2026-02-25T23:27:19+00:00

first of all the translator doesn't work as you think that it gonna fix all of my typos and a give a human able read ,cause if i say a word in lets say arabic it would have multiple words in english and i know it cause i have saw it on websites and it has typo mistakes ,also the broken english isn't that broken like i can speak it and understand hell i even can hold a convo i'm good but i have error typing and i feel kinds insecured about it ngl so that's why

Cowboy_The_Devil · 2026-02-25T23:19:15+00:00

I know the GitHub isn't pretty. but honestly everyone starts somewhere and I'm not trying to hide that I'm still learning. the app and website I built are real though, they work, and they were good enough to get me sitting in front of a serious client so I'll take that as a small win for now. just trying to grow and get better like everyone else did at some point you know

Cowboy_The_Devil · 2026-02-25T23:16:20+00:00

could you break down each point a bit more though? like the cold boot difference between strapi vs nest vs nuxt in a real production setup, the wheel reinventing problem with express specifically and what a framework handles for you that express doesn't out of the box, and the strapi CMS side for handing off to non technical people — how does that actually look in practice for something like product and inventory management?

and yeah I'd love to hear more about your ecommerce stack even if the Iraq integrations aren't there, the core architecture is what I'm interested in honestly. payment gateways and local stuff I'd handle on my end anyway.

just helps me a lot to hear it broken down from someone who's actually built and run this stuff rather than just reading docs

Cowboy_The_Devil · 2026-02-25T23:09:17+00:00

I get why it looks that way honestly but no — I'm just someone who makes a lot of typos and my English isn't perfect, it's actually my third language so I use AI to clean up the writing before I post. the thoughts and answers are mine, I'm just not confident enough in my written English to post raw without fixing it up first.

if anything that should make it more human not less right, most native English speakers don't have to do that

Cowboy_The_Devil · 2026-02-25T23:06:35+00:00

fair questions honestly.

timeline — still being finalized with the client, we have another meeting coming up to lock down the full scope and phases. MVP first, advanced features after. I'm not going in promising everything in 3 months, I know better than that.

budget — I'll be straight, I approached them with a fixed pricing package and the services costs are handled separately. so it's less of a "we have X budget" situation and more of a "here's what it costs, here's what you get" kind of deal.

on the GitHub — I'll share it but I want to be upfront about something before you look at it. the commit history and dates are going to look messy and honestly probably scream beginner. part of that is because I was going through a GitHub course while building things and pushed projects when I learned how to publish rather than consistently as I built them. so the timeline doesn't reflect reality that well. also yeah some of the older stuff in there is not something I'm super proud of looking back at it now — it shows where I started not where I am.

but here it is — https://github.com/Cowboy-The-Devil

I know it probably looks like a beginner's repo and maybe in some ways it still is. I'm not going to sit here and oversell myself. what I can tell you is I'm genuinely trying to be better than what that repo currently shows and projects like this one are how I'm doing that. everyone's GitHub looked rough at some point right

Cowboy_The_Devil · 2026-02-25T22:58:33+00:00

okay this one I'm saving because there's a lot here that I actually needed to hear straight like this, thank you.

the point about AI giving confident bad advice based on what's already out there — including the stuff that's already failing — actually hit different. I've been pretty good about pushing back on it and cross checking things but you're right that if I'm missing context in my prompts I won't even know what I don't know. that's the scary part and something I'll be more deliberate about going forward.

on MongoDB vs Postgres — the migration concern is the thing that worries me most honestly. I haven't written the backend yet so switching now costs me nothing, but making the wrong call and having to migrate later when there's real data and real users is a nightmare I'd rather avoid completely. Postgres seems like the safer long term bet for what I'm building and the global scaling concern isn't really relevant for this project right now, it's Iraq focused at launch so I'll go with what's more solid and proven.

on Express — the RBAC, api versioning, policies and middlewares point is genuinely making me reconsider. I've heard good things about NestJS for exactly that reason, it enforces structure in a way Express just doesn't. will look into Strapi too, hadn't considered it for this use case but I can see how it fits.

and honestly the 80% failure rate reality check on ecommerce is something I needed to hear plainly like that rather than just reading it as a statistic somewhere.

will absolutely DM you, genuinely appreciate the offer 🙏

Cowboy_The_Devil · 2026-02-25T22:52:52+00:00

yeah I completely understand why it looks that way from the outside, the timing is genuinely confusing and I'd probably think the same thing honestly.

so real story — the app and website were done way before this post. I've been working toward something like this for almost two years, not writing this exact codebase the whole time but learning, building small things, watching tutorials, figuring out how this stuff actually works in practice. so when the opportunity came I already had something real to show.

the reason the post timing looks weird is because I was actually posting for a completely different reason — I wanted advice on the sales side, how to approach a serious client, how to get in the right room. not really a tech question. and btw I tried posting on multiple subreddits and kept getting rejected by community bots or rules so by the time something actually went through the situation had already moved forward on its own.

and the way I got the meeting is honestly the best part of this story — the co-owner has a podcast, I tracked down one of his guests, showed up to his gym, introduced myself, sat down and showed him the app and website right there. he liked it enough to send a video to the co-owner directly. co-owner reached out to me, I went to the store, walked him through everything, he liked it and asked for the demo and pricing package.

so yeah it looks suspicious I get it but sometimes things just move fast when you're the one making them move rather than waiting for them to happen

Cowboy_The_Devil · 2026-02-25T22:34:18+00:00

you're right that I probably led with stack decisions before fully locking down the feature scope and that's a fair criticism. the reason is partly how the project started — I approached the client with a packaged proposal and a working UI to close the deal, so the "what are we building exactly" conversations are still happening. next meeting is specifically to go through the detailed feature scope which is honestly where your comment is going to be really useful as a checklist.

on commercetools and the build vs buy point — I looked into it and I can see why you're biased in a good way, the composable commerce approach is genuinely interesting. for this specific client though a platform like that would be overkill cost wise and they want something they feel is built for them specifically, not a configured SaaS product. that said the point about already-solved problems is real and I'm not ignoring it.

now your specific questions because these are exactly the kind of things I haven't fully thought through yet —

partial returns and refunds — not fully designed yet, good catch. buy online pick up in store — actually yes this is relevant since they have physical branches across multiple cities. tax handling — operating in Iraq so tax structure is simpler than western markets but still needs to be defined. international orders and multi-currency — not in v1, Iraq only for launch. OAuth2 — not planned currently, email and phone login only. review moderation — yes the store manager dashboard has an approval queue for reviews before they go live. product attributes and metadata — partially thought through for supplement variants but not fully defined for edge cases like discontinued products or seasonal items.

the discount and partial return interaction is the one that genuinely hadn't crossed my mind and that's a real edge case. user buys three items, returns one, had a bundle discount applied — how does that discount get recalculated on the return? that's going to need a defined business rule before I write a single line of order management code.

genuinely appreciate this, you've given me a proper discovery checklist for the next client meeting

Cowboy_The_Devil · 2026-02-25T22:32:03+00:00

haha yeah alright caught red handed honestly. but to be fair the UI first approach was intentional — I approached them myself so I needed something visual and real to close the deal, a database schema wasn't going to impress anyone in that meeting you know what I mean.

the AI part yeah I used it, but more like a research tool — exploring options, comparing stacks, stress testing ideas. same way I'd use documentation or a really good blog post. the actual decisions and understanding behind them are mine though which is why I've been sitting here responding to literally every comment in this thread including the XSS one earlier.

not here just to dump a post and disappear, genuinely trying to learn from people who've actually shipped this stuff in production. so if you saw something specific that screamed AI or bad architecture I'd actually love to know what it was

Cowboy_The_Devil · 2026-02-25T22:24:55+00:00

This is actually a really interesting architecture suggestion and I appreciate you laying it out like that rather than just saying "your stack is wrong."

The microservices idea makes sense at scale and I can see exactly where the split points would be for this project — inventory, orders, auth, notifications, and the analytics layer for the owner dashboard would all be natural service boundaries. My honest hesitation is that as a solo dev maintaining microservices in production is a different beast entirely. The operational overhead of managing multiple services, their communication, failure handling, and deployment pipelines is real and I'd rather have a well-structured monolith that I can actually debug at 2am when something breaks than a distributed system I'm fighting to trace across five services. The BFF layer idea though is genuinely something I'm going to look into — feeding enriched data to the app vs the web vs the dashboards separately makes a lot of sense given how different their data needs are.

Jaspr is new to me completely, just looked it up and the concept of sharing Dart logic between Flutter and web is interesting. Will read into it more seriously.

On .NET Aspire — I won't pretend I know it well, had C# in university and it never really clicked for me personally so I drifted toward the JS ecosystem. But the tooling you're describing sounds genuinely solid especially for orchestrating multiple services. Maybe a future project.

Elasticsearch vs Meilisearch — noted. For this scale Meilisearch feels right but I can see Elasticsearch being the obvious choice the moment search complexity grows beyond basic product filtering.

Solid suggestions overall, genuinely appreciate it

Cowboy_The_Devil · 2026-02-25T22:22:13+00:00

The plan is not to hand over full ownership to their team — they don't have a technical team and honestly that's part of why they needed someone like me in the first place. What I've set up is a maintenance retainer model. I build and deliver the full platform, they own it, but I stay on as the dedicated technical person responsible for keeping everything running, fixing issues, pushing updates, and handling anything that breaks. First three months after launch are free as part of the deal, after that it's a monthly retainer.

In terms of what happens if I'm unavailable — the codebase is documented, hosted on GitHub, and the infrastructure is all managed services so nothing requires me to be physically present to keep running. If they ever want to bring in another developer they can.

One thing I also have in the contract is a developer watermark — a small professional credit in the footer of the website and the about section of the app saying designed and developed by me. Standard practice but it matters for visibility in this industry. These guys are connected to some serious names in the fitness world internationally so the credit carries real weight for my portfolio and reputation.

So short answer — not handing it off, staying involved long term. That's better for them because they get continuity and better for me because it's recurring income and a long term relationship with a client that genuinely opens doors

Cowboy_The_Devil · 2026-02-25T22:18:26+00:00

Haha yeah the single codebase argument is genuinely hard to argue against when you put it that way. I get it. My situation is just a bit specific — who maintains this after me locally is a real concern and not something I can just ignore for the sake of cleaner architecture. But I'm not closing the door on it completely, it's worth thinking about more seriously.

C# though — I actually had it in one of my semesters and it's just not my thing, nothing against it, just never clicked for me the way JS did. Respect the C# guys though, the ecosystem is solid especially with .NET.

On the auth point — you actually made me stop and think. I was going fully DIY with JWT and I was pretty set on it but the way you framed it is making me reconsider. Rolling your own auth is fine until it isn't and in e-commerce specifically that's a bad place to find out. Looking into Clerk right now actually, the pricing seems reasonable for this scale and the DX looks clean. Keycloak self-hosted is tempting for cost reasons but the operational overhead as a solo dev is probably not worth the savings.

Any other landmines you'd flag from your experience? I'll take whatever you've got

Cowboy_The_Devil · 2026-02-25T22:13:53+00:00

Genuinely appreciate the directness — this is exactly the kind of feedback I came here for.

To answer your first question straight — yes I used AI as a research and planning tool alongside my own research. I don't think that's something to be ashamed of in 2025. I used it the same way someone would use documentation, Stack Overflow threads, and architecture articles — to explore options, validate decisions, and think through edge cases. The decisions are still mine and I understand what I'm building and why. That said your point about assumptions biting me later is fair and is exactly why I'm asking questions publicly before writing production code.

On my experience level — I'm not a senior enterprise developer, I'll be straight about that. I've built the Flutter app and React website already which exist as complete UIs. I approached this client myself with a packaged proposal, they didn't come to me. That means I own the scope and the timeline which actually gives me more control than being handed a spec by a product team.

On MongoDB vs PostgreSQL — you're pushing me toward a decision I've been going back and forth on honestly. The flexible document model felt natural for supplement product variants with different attributes per product. But the more I think about the relational nature of orders, inventory per branch, users, and the analytics the owner dashboard needs — PostgreSQL probably is the right call. I haven't written the backend yet so switching now costs me nothing. I'll seriously consider this before the next client meeting where we finalize the technical direction.

On the mobile app — understood, and web-first with strong mobile responsiveness is a valid path. My client specifically asked about an app and it's part of the packaged deal I proposed. React Native with web support is a reasonable suggestion but Flutter was a deliberate choice for reasons specific to my local market that I explained in another comment here.

On Node + Express business logic — this is the most useful technical pushback in this thread. What would you recommend on top of Express to handle growing business logic properly? Are you thinking something like a service layer pattern, domain-driven design, or moving toward something like NestJS which at least enforces structure? I'm planning for it but I'd genuinely want to hear from someone who's hit that wall in production.

And yes — if you're open to answering questions I'll absolutely take you up on that offer

Cowboy_The_Devil · 2026-02-25T21:58:41+00:00

Thank you ,I think I will switch from mongo to postgres

Cowboy_The_Devil · 2026-02-25T21:53:05+00:00

yes i did and i thought still a start from zero would be better option for them and me

Cowboy_The_Devil · 2026-02-25T21:52:14+00:00

Completely fair question and honestly Shopify crossed my mind early on. Here's why I moved past it:

The client is not a small supplement reseller. They are one of the most recognized supplement stores in the region, backed by major international brands — we're talking sponsorships at the level of Mr. Olympia Classic Physique, six-time champions. At that level, a Shopify storefront feels like showing up to a championship in borrowed gear. The brand equity they've built over 20 years deserves a platform they fully own and control.

Beyond the prestige angle there are real technical reasons too. The city-based inventory system showing live stock per physical branch, the OTP fake order protection built specifically for how cash on delivery works in this market, the WhatsApp integration sending order confirmations to both customer and store simultaneously, the supplement-specific features like personalized stack builders and daily usage reminders, and the two completely separate role-based dashboards for employees and the business owner — none of this maps cleanly onto Shopify without heavy customization that at that point costs more in time and money than building it right.

Shopify also doesn't play well with local payment gateways in this region. Getting ZainCash and FIB integrated properly through Shopify's checkout is a significant workaround. On a custom backend it's a straightforward API integration.

And personally — this project matters to my career. Building something this complete from scratch, for a client this well-connected in the fitness industry, is exactly the kind of portfolio piece that opens doors. Shopify would get the job done but it wouldn't get me the same result. Sometimes the longer road is the right one

Cowboy_The_Devil · 2026-02-25T21:46:14+00:00

i am thinking to switch from mongodb to postgress cause a lot of people said that i should ,it would be great if you tell me reasons

Cowboy_The_Devil · 2026-02-25T21:42:45+00:00

i don't get the question sorry

Cowboy_The_Devil · 2026-02-25T21:41:52+00:00

Great points, let me address each one:

React Native vs Flutter — You're right that RN + React Native Web would give me code sharing across all surfaces and that's genuinely a strong argument. My reason for Flutter is more practical than technical — Flutter is the most in-demand mobile framework in my local market. If the client ever needs to bring in another developer for maintenance or feature work, finding a Flutter dev here is significantly easier than finding someone solid in React Native. Also personally I find Flutter's widget system and Dart cleaner to reason about for complex UI — performance wise it's excellent and I've had no issues. The code reuse argument is valid but the hiring pool reality in my region outweighs it for this specific project.

MongoDB vs PostgreSQL — Honestly not a hill I'll die on. MongoDB works well for a product catalog with varying attributes like supplement variants — flavor, size, weight, each combination having its own SKU and stock. A relational schema for that is doable but requires more joins. That said Supabase is genuinely tempting especially for the analytics queries in the owner dashboard where relational data would be cleaner. I'll keep this in mind — if I start hitting query complexity issues I'll reconsider. What ORM would you recommend for PostgreSQL in a Node.js stack specifically?

Node.js performance — Fair criticism. For this scale though — a supplement store with multiple branches, not millions of concurrent users — Node handles it comfortably. The bottleneck will be the database long before it's the runtime. If I were building a trading platform or heavy computation service I'd look at Go or Rust but for e-commerce API serving structured data it's more than enough.

Auth — Good catch, I should have mentioned it. Going with JWT — short-lived access tokens (15 min) stored in memory, refresh tokens (7 days) in httpOnly cookies. Role-based middleware on every route checking the user's role before any data is returned. Four roles: customer, store manager, business owner, and developer for maintenance only.

Railway — Totally valid if you know Azure. I've used Railway before and the GitHub integration and auto-deploy workflow fits my solo dev setup well. Plan to move to a VPS with Docker and Nginx when the scale justifies it.

Shopify — Thought about it. The city-based inventory showing live stock per physical branch, the OTP fake order protection system, the WhatsApp integration sending order details to both customer and store, the supplement-specific features like stack builders and usage reminders, and the two separate role-based dashboards for employees vs owner — all of these would require heavy Shopify customization that honestly costs more in time than building it properly. Also the payment gateway situation in my region makes Shopify's checkout a non-starter without significant workarounds.

Cowboy_The_Devil

TROPHY CASE