CBlaze

That requirement shaped almost every decision that followed. A store that needs a code change and a redeploy to run a sale, adjust shipping, or restock an item isn't really self-service; it's a storefront with a developer standing behind it indefinitely. Three things had to be true from day one:

• Pricing had to live in the database, not the code. Every price a customer sees needed to trace back to a value an admin actually set, on every page, with no exceptions.
• Checkout had to survive the real world. Dropped connections, closed tabs, and slow mobile networks are normal, not edge cases, and a payment succeeding on Paystack's side had to reliably become a completed order regardless of what happened to the customer's browser afterward.
• Hosting couldn't add a new recurring cost. The business already pays for cPanel hosting for other purposes; running CBlaze there instead of on a metered platform was a real requirement, not a nice-to-have.

The build itself is a fairly conventional Next.js storefront over MongoDB. The more interesting engineering happened at the edges: getting pricing to a state where it genuinely couldn't disagree with itself, making checkout resilient to a customer's browser disappearing mid-flow, and then relocating the entire thing from Vercel - which had handled build, deploy, and runtime invisibly - onto shared hosting, where all three of those became this project's problem for the first time.

The pricing model went through two shapes. The first treated a sale price as a manually-set badge on individual products - a "was / now" pair applied to whichever items happened to be on sale. That didn't match how the business actually wanted to run promotions: any watch could go on sale at any time, and when it wasn't, the page should show nothing but its regular price. The fix collapsed both states into a single field and a single function - every product carries a discount (flat or percentage, defaulting to zero), and getEffectivePrice() is the only place in the codebase allowed to resolve what a customer actually pays. The homepage, the catalog grid, and the product detail page all call it instead of reading a price field directly.

An order is created in two steps, deliberately not one. createPendingOrder() first writes the order as pending, then calls Paystack to initialize the transaction; if that call fails, the pending order is deleted rather than left behind. A failed call to a third-party payment API should never leave an orphaned order sitting in the database as if a customer had started a checkout that, in fact, never got far enough to reach Paystack at all.

Confirming payment afterward is the more interesting half. finalizeOrder() is called from two independent places - the page Paystack redirects the customer back to, and Paystack's own webhook - because neither one alone is reliable. A customer can close the tab before the redirect completes; a webhook can be delayed or, in this project's case, isn't even reachable for every order (more on that below). Both triggers call the exact same function, and the function is written so that whichever one arrives first wins: it updates the order with a filter of paymentStatus: "pending", and only the update that actually matches that condition proceeds to decrement stock, update the customer record, and send the confirmation email. The second trigger to arrive finds the filter no longer matches and returns already_finalized - no double stock decrement, no duplicate email, no race.

The same function also declines to fail loudly when it probably shouldn't. If two customers finalize against the last unit of the same watch at nearly the same moment, the loser doesn't throw an error into a real transaction that already has the customer's money - the order is flagged [OVERSOLD: sku] in its notes instead, so the business finds out and can act, rather than the checkout appearing to break for a payment that already succeeded.

Shipping rates and tax were fixed constants in an early version of the code. They moved into a database-backed Settings document, editable from the dashboard, once it became clear those numbers change more often than the code around them does. Every stock mutation writes an InventoryLog row with a reason - sale, restock, manual correction - so stock history is an actual log to audit, not just a mutable integer sitting on the product. Upstash Redis backs rate limiting on the public API routes, so the storefront's own traffic can't be used to hammer the database.

Vercel had been handling build, deploy, and runtime without any of that being this project's concern. Moving to shared cPanel hosting under Phusion Passenger meant becoming responsible for all three at once. output: "standalone" turns the Next.js build into a self-contained Node process - straightforward to enable, but standalone output does not copy public/ or .next/static/ into the deploy folder by default, which is not obvious until the first deploy serves a site with no images and no styling. The admin middleware needed runtime: "nodejs" set explicitly, too: it uses a Node-only auth check that Vercel's edge runtime had been tolerating silently, and a plain Node process under Passenger will not.

Next's standalone output traces the exact dependencies a build needs at runtime and copies them into the deploy folder - except when a dependency has been hoisted to a shared node_modules folder by the monorepo's package manager, in which case Next records it as a symlink rather than copying it, on the assumption that the symlink will resolve on whatever machine runs the build. Zipping that folder with Windows' own archiver, and later re-transferring it with a plain tar, both preserve that as a link to an absolute path on the local Windows machine, not as the package itself. Nothing about that is visible until the app boots on the Linux server and fails to resolve mongoose, because what it actually has is a shortcut pointing at a folder that never existed anywhere but the machine that built it.

After a routine app restart, the site and SSH access both went fully unreachable at the same time - not a 500 page, an outright connection refusal on both ports, for several minutes. cPanel's own browser-based Terminal, which needs to fork a process the same way SSH does, surfaced the actual cause directly: cagefs_enter: Unable to fork, a CloudLinux LVE resource ceiling. The account's own Resource Usage panel narrowed it precisely - Physical Memory sat at 19%, nowhere near its limit, while Number of Processes read 80 / 80, pinned exactly at the account's ceiling, almost certainly orphaned Node worker processes from earlier restarts that had never been reaped.

The account genuinely could not fork a new process to diagnose itself, which meant the fix wasn't code - it was a support ticket, written with the specific saturated metric already isolated instead of a generic "the site is down."

Live payments needed to settle into CBlaze's own bank account, but the underlying Paystack account already runs live transactions for a separate business. Rather than open a second Paystack integration, CBlaze's proceeds route through a subaccount under the same account: the same live API keys, a subaccount code attached to every transaction, and percentage_charge: 100 so the full amount settles to CBlaze's own account while the parent account absorbs Paystack's processing fee. Before creating the subaccount, the destination bank account was resolved against Paystack's own name-lookup and checked to match exactly, rather than trusting a manually typed account number. The live credentials were then verified with a direct API call - a real transaction/initialize request against Paystack's live endpoint that returns a valid checkout URL - confirming the wiring worked before any real customer's card was involved.

The redirect Paystack sends a customer back to after payment isn't guaranteed to complete - a dropped connection or a closed tab leaves an order stuck pending even though Paystack already confirmed the charge. Normally the webhook would catch that case, but a Paystack account only supports one live webhook URL, and this one is already committed to the other business sharing the account. Rather than build a shared webhook router immediately for a gap that's rare in practice, a small script calls the exact same finalizeOrder() function production uses, directly, against a payment reference - the identical idempotency guarantee, just triggered by hand instead of by a network callback.

It found real use the same day it was written: a live-credentials test completed payment successfully, the redirect landed on localhost from a phone that could never reach it, and the script closed out the order correctly without ever touching the broken redirect.

CBlaze is live and taking real orders. The concrete outcomes, measured against what the brief actually asked for: