Custom commerce, from platform evaluation to operational handover
Bessarabian Cigar Studio is a premium cigar brand selling in a regulated U.S. market. AG Systems took its commerce platform from the initial brief through product definition, engineering, launch, training, and transfer of operational ownership.
- client
- Bessarabian Cigar Studio
- sector
- Premium cigars · regulated U.S. commerce
- role
- Founder-led product and engineering delivery
- platform
- Edge storefront · Kotlin/Spring commerce backend · React administration · AWS
- delivery
- Platform evaluation · product definition · build · launch · handover
- status
- Live · training complete · ownership transferred
Why the project became a custom build
The work began with a business brief and a platform decision.
Bessarabian Cigar Studio needed a strong visual identity for each product, along with catalog, fulfilment, integration, and operating workflows specific to the business. Its team also needed direct control over routine catalog, order, shipping, customer, and publishing work.
AG Systems compared mainstream commerce platforms with a custom approach. The evaluation covered practical fit, limitations, cost estimates, integration control, and the work required to operate each option. A standard platform would have required the customer experience and internal workflows to bend around assumptions that didn't fit this business.
The custom route gave the client control over the product experience, system integrations, and day-to-day operation. It also implied accepting responsibility for owning and operating a custom platform. That trade-off was made explicitly before implementation began.
The platform implements the category-specific safeguards and operating rules supplied by the client. Regulatory decisions remained with Bessarabian Cigar Studio and its advisers.
What AG Systems delivered
AG Systems led the engagement from product definition through operational transfer. The delivered platform includes:
- 01A mobile-first storefront with product-specific presentation.
- 02A Kotlin/Spring commerce backend covering catalog, pricing, availability, checkout, orders, payments, refunds, shipping, publishing, and customer communication.
- 03A React administration console for the client’s routine commercial work.
- 04AWS infrastructure delivered as code, deployment workflows, monitoring, and alerts.
- 05Product requirements, architecture and decision records, specifications, tests, operator guides, and runbooks.
- 06Client training and the signed transfer of operational ownership.
The storefront, backend, administration console, and infrastructure have different responsibilities and release paths. Together they form one operating platform.
Architecture follows system behavior
Product and editorial pages change less often than price, availability, cart state, and checkout data. The architecture treats those paths differently.
Product presentation is generated ahead of time and deployed to an edge network. Thus, a storefront request can be served without asking the commerce backend to render the page. After the page loads, browser-side hydration fetches current commercial data where freshness matters.
The Kotlin/Spring backend remains authoritative for pricing, availability, shipping, totals, orders, and payment state. Background jobs, queues, and scheduled work handle asynchronous tasks. The React administration console uses the same application boundaries through an interface designed for operators rather than around database structure.
The administration console communicates with the backend through authenticated APIs with role-based access control. Notification settings can be tailored to different operating roles, so teams receive events relevant to their responsibilities.
Edge storefront with live commerce paths
Stable presentation is published to the edge. Current commercial data remains live, while the administration console exposes publication state and recovery controls.
Price, availability, shipping, and totals are checked again before an order is created. The deployed catalog is never the final authority for a transaction.
Operating an edge storefront
Drift and transaction safety
Edge delivery introduces a second version of the catalog: the version currently deployed to the storefront. It can fall behind after a product or editorial change, so content freshness has to be visible and manageable.
Product presentation follows the publication lifecycle, while current price and availability are hydrated from the backend. Cart and checkout paths revalidate the inputs used to create an order, so a stale storefront snapshot can't set details relevant to checkout.
Freshness and operator control
Catalog versioning records the relationship between the current catalog and the version deployed to the edge.
The administration dashboard shows catalog freshness and publication status. Operators can publish changes on demand, inspect an incomplete publication, and intervene manually when automation does not finish.
Read the engineering note: Static, edge, or live: decided per path →
Three decisions that shaped the platform
Decision 01
Model catalog state around business behavior
Products can be current, sold out, retained as past releases, unavailable for purchase, or absent from the public catalog. Those states affect both the customer experience and the work performed by operators.
The catalog represents them explicitly. The storefront and administration console can then produce consistent results from one business state instead of requiring operators to coordinate several unrelated controls.
Decision 02
Keep transaction boundaries explicit
External providers handle concerns such as card processing. The commerce backend remains authoritative for products, prices, shipping, totals, orders, and their state.
Retries and incomplete provider outcomes are treated as normal failure cases. The administration console exposes them for investigation and recovery while protecting against duplicate commercial actions.
Decision 03
Build operations into the product
The administration console supports the work required to run the business: product and catalog management, orders and refunds, shipping configuration, users, customer communication, and storefront publication.
This gives the operating team a view of the current system state, safe controls for routine changes, and a clear place to investigate work that needs attention.
Read the product-engineering note: Availability is a decision, not a property →
From brief to launch
- 01Clarify the business goal and compare viable platform approaches.
- 02Define product requirements, operating roles, constraints, and acceptance criteria.
- 03Explore and review visual directions with the client.
- 04Record consequential architecture decisions before implementation made them expensive to change.
- 05Build and integrate the storefront, backend, administration console, infrastructure, and deployment workflows.
- 06Demonstrate milestone outcomes, incorporate feedback, test, deploy, document, and train.
- 07Launch the platform and transfer operational ownership.
Automated tests covered domain rules, integrations, storefront behavior, and the primary commercial paths.
Measurements changed the delivered system
Finding 01
Baseline computeReduced by 50% after load testing
The backend was first provisioned at a container size typical for this stack. Before launch, stepped synthetic load tests measured the request rate each size sustained within the agreed latency and error limits. A container with half the CPU and memory carried the expected peak with headroom, so that size shipped, with autoscaling added for sustained load. The test exercised catalog reads, not image resizing, which is why the second finding came later.
Finding 02
Image deliveryBounded through a fixed rendition contract
Extensive pre-launch testing of the production deployment found that every uncached image request decoded and resized the original on the small backend task. An edge cache rule removed the repeat cost; a fixed set of rendition widths, decoded once per image, bounded the origin work that remained.
The architecture and product design remained unchanged. The measurements informed implementation-level optimizations that reduced operating cost and improved delivery performance.
measurement note: The load test was synthetic load against a single instance of the deployed backend. It is not a concurrent-user figure or a measure of end-user latency.
Launch and operational handover
- LiveStore launched
- CompleteClient training
- TransferredOperational ownership
Handover
The handover included role-specific operator guides, annotated interface instructions, deployment and infrastructure documentation, monitoring alerts, and runbooks written for readers who had not built the system. AG Systems trained the client’s team, and Bessarabian Cigar Studio signed the completed handover.
What the client can operate
The client now operates a custom commerce platform shaped around its product presentation, workflows, integrations, and operating model. Its team can manage routine catalog, order, refund, user, shipping, and publishing work through the administration console. The supporting infrastructure, deployment workflows, guides, and runbooks were transferred with the software.
Read the delivery note: Handover is part of the product →
Need software shaped around your business?
Describe what needs to work. The founder will review the brief and suggest a practical next step.