Atlas
Market.

01 / THE BUILDThree roles, one shared order

Atlas Market is a marketplace for a GTA/FiveM roleplay economy. Buyers place orders and negotiate, suppliers fulfill them, and staff moderate the activity. Those are different jobs, but they all depend on the same order making sense.

My work covered the marketplace, API, realtime features, and deployment. The interesting part is not the listing grid by itself. It is how the system keeps the order, its line items, and its conversation connected.

This is community software, not a real-money commerce case study. The website helps coordinate roleplay; the material here does not establish automated in-game payments or a server integration.

02 / THE BUILDAn order needs a defined next step

The implementation account describes an order state machine rather than independent status flags. It names PENDING → ACCEPTED → … and says illegal transitions return a 400 response.

That is enough to explain the design choice, but not enough to reconstruct every state or permission. A complete diagram would need the actual transition definition. Instead, the interactive explanation below focuses on a sequence the source does show: creating an order and publishing its notification.

03 / THE BUILDSave the work before announcing it

Creating an order writes the order itself, its items, and a message thread. Those writes belong to one database transaction. If an insert fails, they do not become a partially created order.

The notification happens afterward. A messaging failure should not undo a transaction that already committed.

The distinction is useful to inspect rather than merely describe. Try the item-write failure, then the notification failure. The outcomes differ because the failures occur on different sides of the commit.

04 / THE BUILDThe application behind the workflow

Next.js handles the pages and bridges API requests to a standalone Hono app. Neon provides Postgres storage; Clerk handles authentication with a Discord-guild allowlist gate; Ably supplies realtime messaging; R2 holds images.

The pricing calculations also have a defined boundary. The account describes totals rounded to cents with integer math, rather than allowing floating-point drift to decide the amount displayed to a buyer. The precise calculation is not reproduced in the supplied excerpt.

05 / THE BUILDWhat was checked, and what remains

The June 2026 write-up reports 377 tests across unit, integration, and Playwright end-to-end checks, covering an API with 97 endpoints. It specifically describes coverage of the order lifecycle and illegal transitions. These are historical reported figures, not tests rerun for this portfolio update.

The same account leaves several improvements open: shared validation at the API boundary, clearer alignment between realtime event names and REST operations, and a package name left over from the scaffold.

The related security articles describe a search-query remediation. Their code uses an Express-style handler while the architecture article describes Hono. The supplied files do not establish how those revisions fit together, so that connection needs a repository check before publication.

06 / THE BUILDWhat to inspect next

The order-lifecycle article examines the transaction boundary in code. The testing essay explains the regression-first approach. The search-query case study separates the injection fix from a second change that also needs review: a new result limit.