SellPrime

The core

A valuation engine where pricing is data, not code

Every purchasable variant of a device, a model at a given storage and RAM, is one row in the catalogue, and that row carries both its base price and its own complete set of depreciation values. Nothing about how a particular model loses value is written in a source file. It lives in the database, which means the team can retune any single model from the admin panel without a deploy, and two models can behave completely differently from one another.

The order the deductions apply in is the part that actually matters. Age resolves first and produces an age-adjusted base; every condition deduction after that is a percentage of the adjusted figure rather than of the original price. Depreciation compounds the way it does in reality instead of stacking additively onto a number the device stopped being worth months ago.

Because the questions themselves are per-variant flags, a cellular tablet is asked about its network and a wifi-only one never is, out of the same code path.

Operations

An admin panel that runs the business, not just the database

The back office is the product for everyone who works there. It covers fifteen distinct areas, and most of them replace a tool the business would otherwise be paying for separately, which is why it ended up serving as the company's CRM rather than sitting next to one.

Access control

Per-admin permissions down to the individual action

Every admin carries a permission map, and every protected route declares the module and the action it requires. There is no single staff role that unlocks the panel: an account can be given read access to orders, write access to devices, and nothing else at all.

Privilege escalation is closed off deliberately. Promoting somebody to developer sits behind its own separate guard, so a full administrator still cannot mint an account more powerful than themselves unless that specific capability was granted to them.

Every mutation writes to an activity log with the acting admin, the affected user, a severity, a detail payload, the IP, and the user agent, filterable by security, orders, users, devices, agents, quotes, reviews, or bans.

Trust

Reviews only real customers can leave

Completing an order generates a single-use token and emails the customer a review link tied to that specific order. There is no open review form anywhere on the site, so a review cannot exist without a transaction behind it.

The link stays valid for seven days after the order finishes, and a cleanup job clears expired tokens on the same schedule the link itself checks against, so the two can never disagree. Submitted reviews land in a moderation queue; only once approved from the panel do they appear on the public site.

Orders completed before the finish timestamp was recorded have nothing to measure a deadline from, so their links deliberately stay open rather than expiring retroactively.

Security

Making the price list expensive to scrape

The valuation model is the business. Anybody able to enumerate quotes across the catalogue would walk away with the pricing strategy for every device the company buys, so quoting is treated as the sensitive operation rather than the harmless one.

Two thresholds run over every quote request. A rapid burst is blocked outright; a slower but still abnormal volume is allowed through and flagged for a human to look at. Anonymous traffic is tracked by session and IP and results in an automatic IP ban, while a signed-in account is suspended instead. Either way a report is filed with the count, the window, and the identifier, so nothing is banned silently.

The economics are what actually stop it. Reaching the useful data requires an account, an account requires a verified mobile number, and the threshold trips long before a single number has paid for itself, so enumerating the catalogue costs roughly one SIM per handful of devices.

Architecture

Four clients, one API, no exposed backend

The three web apps never reach the Express API from the browser. Each proxies through its own Next.js route handlers, so the backend URL stays server-side and the browser only ever calls its own origin. The mobile app, which has no such intermediary, talks to the API directly and is treated as an untrusted client accordingly.

The API groups its routes by audience rather than by resource: public, staff, and agent surfaces are separated at the router level before any handler runs. That makes the boundary between them something you can see rather than something you have to remember.