SG SHEHAB GINEM

SHEHAB GINEM  /  SENIOR SOFTWARE ENGINEER  ·  AI SYSTEMS

I design systems that ship — and scale in production.

Full-stack engineer building production software across web, mobile, and back-end systems — with AI and LLM workflows embedded as native infrastructure. Five years shipping code that actually runs the business.

View Selected Work Get in Touch
[ A ] PORTFOLIO — SELECTED WORK 2020 — PRESENT [ B ] SCROLL TO BEGIN
§ 01 About / Practice

“Production software is a discipline of tradeoffs — reliability, maintainability, and the cost of being wrong.”

I’m a software engineer based in Memphis, Tennessee, currently completing my Computer Science degree at The University of Memphis. For the past five years I’ve been the sole engineer behind the entire digital stack at Valabasas — designing relational schemas, building REST and GraphQL APIs, shipping React and React Native applications, and maintaining a custom ERP system that runs core business operations across multiple Shopify storefronts.

My work spans the full stack: PostgreSQL data modeling, Node.js / Express services, React and Next.js front-ends, native mobile via React Native, Python for data and computer vision tooling, and infrastructure decisions from caching strategies to deployment pipelines. I write code that’s meant to be read, tested, and extended — not just shipped.

On top of that foundation, I architect AI systems — LLM-powered workflows, RAG pipelines, prompt evaluation harnesses, computer vision prototypes, and intelligent internal tooling. I treat AI the way I treat any other production dependency: with versioning, observability, evaluation, and a clear understanding of failure modes.

§ 02 Selected Work 07 PROJECTS / 2020 — PRESENT
No. 01
VLBS / STACK SHOPIFY · ERP · APP · API
98% CRASH-FREE
5+ SUB-SYSTEMS
∞ SKUS HANDLED

Valabasas Digital Stack

2023 — Present

Sole engineer across an entire e-commerce platform: a Shopify-headless storefront, a React Native mobile application with a 98% crash-free rate, a custom PostgreSQL-backed ERP, and a Node.js service layer that synchronizes inventory, orders, and customer data across multiple stores in real time.

Role
Sole Software Engineer · Architecture, implementation, deployment
Stack
React · React Native · Node.js / Express · PostgreSQL · Shopify Storefront & Admin APIs · Liquid · GraphQL
Scale
Multiple Shopify stores · Thousands of SKUs · High-volume drop traffic
Reliability
98% crash-free mobile sessions · Idempotent sync layer · Automated error monitoring
Read case study

The problem

A growing streetwear brand operating multiple Shopify storefronts had fragmented operations: spreadsheet-driven inventory, manual order reconciliation, no unified customer view, and no native mobile experience. Every drop created days of manual work and reconciliation errors.

Architecture decisions

I designed a service-oriented architecture with PostgreSQL as the source of truth, an Express-based API layer, and Shopify treated as one consumer among several. This let the ERP, mobile app, and storefront all read from the same canonical data model rather than fighting Shopify’s eventual-consistency quirks. Inventory and order sync were built as idempotent jobs with retry and backoff, which eliminated the duplicate-write bugs we’d seen with naive webhook handlers.

Mobile reliability

The React Native app uses Flutter and native iOS components for performance-critical flows. I added crash reporting, automated memory profiling, and an over-the-air update pipeline. The result was a 98% crash-free rate sustained across releases — measured continuously, not anecdotally.

What I’d do differently

Earlier introduction of a typed contract between the API and mobile client (we adopted TypeScript later than ideal), and a proper schema migration tool from day one rather than retrofitting one at month six.

No. 02
INPUT PRODUCT DATA
→
LLM GPT · CLAUDE
→
OUTPUT COPY · EMAIL · ASSETS
VERSIONED PROMPTS EVAL TESTED BRAND VOICE LOCKED

LLM Content Pipeline

2024 — Present

A production LLM workflow built as a typed Node.js service: it ingests structured product data from PostgreSQL, runs versioned prompt templates through OpenAI and Anthropic APIs, validates outputs against a brand voice eval suite, and writes results back to Shopify via the Admin API. Treats prompts as code: versioned in git, evaluated against a held-out test set, and monitored in production.

Stack
Node.js / TypeScript · OpenAI & Anthropic SDKs · PostgreSQL · Shopify Admin API · Custom eval harness
Patterns
Structured output (JSON Schema) · Retrieval-augmented prompts · Output validation · Cost & latency budgeting
Reliability
Retry with exponential backoff · Token-budget guards · Provider failover · Eval gate before publish
Outcome
Hours of manual copywriting reduced to minutes per drop · Consistent brand voice across hundreds of SKUs
Read case study

Why a pipeline, not a chatbot

The naive approach is “let merchandisers paste prompts into ChatGPT.” That fails three ways: inconsistent voice across operators, no way to evaluate quality at scale, and no audit trail. I built it as a deterministic pipeline with prompts under version control, structured input/output contracts, and an eval step that catches regressions before anything reaches the storefront.

Structured output enforcement

Each prompt template returns a JSON object with a defined schema (title, short description, long description, tags, alt text). The schema is validated before write, and any schema mismatch is logged and routed to a human review queue rather than failing silently or guessing.

The eval harness

I maintain a curated set of input/output pairs representing the brand’s voice. New prompt versions run against this set before being promoted. Outputs are scored on adherence to voice guidelines, factual correctness against the source product data, and length constraints. This is the same idea as a unit test suite, applied to language model outputs.

Cost & latency engineering

Each request is bounded by a token budget and has a fallback provider configured. Tier selection happens dynamically: shorter tasks route to faster, cheaper models; long-form generation routes to the higher-tier model. Cost per generation is logged and aggregated.

No. 03
⌬ ⌬ ⌬ ⌬ ⌬ ⌬
[VLBS-9341] SCANNED
[VLBS-9342] SCANNED
[VLBS-9343] SYNCING

RFID Inventory System

2025

Designed the full technical architecture for a real-time RFID inventory management system: Chainway UHF handheld readers feed scan events through a React Native operator app to a Node.js / Express service, which reconciles against a PostgreSQL canonical inventory table and pushes deltas to Shopify via the Admin API. Includes anomaly detection for mismatches between physical and system counts.

Stack
React Native · Node.js / Express · PostgreSQL · Chainway UHF SDK · Shopify Admin API
Architecture
Event-driven scan ingestion · Reconciliation engine · Anomaly detection · Bidirectional sync
Engineering challenges
Hardware integration · Latency-tolerant UI · Conflict resolution between physical and system state
Read case study

The reconciliation problem

RFID inventory at retail scale is fundamentally a state-reconciliation problem: the warehouse, the storefront app, and Shopify each believe slightly different things at any given moment. The naive approach — treating each scan as authoritative — produces phantom inventory and angry customers when the storefront sells something that physically isn’t there.

Design

I treated the PostgreSQL inventory table as the canonical state machine. Scans from the React Native app are ingested as events with operator ID, timestamp, location, and signal strength. A reconciliation worker compares aggregated scan events against expected state and flags discrepancies above a configurable threshold for human review rather than auto-correcting.

Vendor & hardware integration

I sourced and evaluated UHF reader vendors (Chainway via BSN Group) and prototyped against their SDK to validate read range, scan speed, and tag compatibility before committing to the architecture. The native module bridge exposes scan events to the React Native layer with sub-50ms latency.

No. 04
MODULE STATUS AI
Orders ● Active ✓
Inventory ● Active ✓
Fulfillment ● Active ✓
Customers ● Active ✓
Reporting ● Active ✓

Custom ERP Platform

2023 — Present

A bespoke ERP built from scratch to replace fragmented SaaS tools. Modular architecture with separate services for orders, inventory, fulfillment, customer data, and reporting. Authenticated React admin UI, role-based access control, audit logging on every mutation, and a reporting layer that joins data across modules without breaking the single-responsibility boundary.

Stack
React · Node.js / Express · PostgreSQL · Shopify Admin API · OpenAI (assistive features)
Modules
Orders · Inventory · Fulfillment · Customers · Reporting · AI assistants
Engineering
Role-based access control · Audit logging · Database migrations · Backup & restore
Read case study

Why build instead of buy

We evaluated NetSuite, Brightpearl, and several mid-market ERPs. Each required us to bend operations around their data model, and none integrated cleanly with the multi-store Shopify topology we already had. The cost of fighting their assumptions was higher than the cost of building exactly what we needed against our own schema.

Schema-first design

I started by modeling the data: orders, line items, inventory movements, fulfillment events, customers, addresses. Every table has created/updated timestamps, soft-delete columns, and an audit log table that records every mutation with operator ID and diff. This means the system is debuggable in production: every state change is reproducible and traceable.

Access control & safety

Role-based permissions are enforced at the API layer, not the UI. Destructive operations require confirmation tokens and are logged. Database backups run nightly with point-in-time recovery tested quarterly — because production data integrity is the entire point of an ERP.

No. 05
MEDIAPIPE · 21 LANDMARKS · 60FPS

Hand-Tracking Vision Engine

2024

A real-time computer vision application in Python using OpenCV and MediaPipe’s 21-landmark hand model. Captures webcam frames, runs inference on each frame, applies gesture-classification heuristics, and renders interactive visual effects at 60 frames per second on consumer hardware.

Stack
Python · OpenCV · MediaPipe · NumPy
Performance
60 FPS on consumer hardware · 21-landmark inference per frame · Sub-frame gesture classification
Engineering
Frame buffering · Coordinate-space transforms · Real-time render loop
No. 06
14:00 CUTOFF
DELIVERED TOMORROW
MEMPHIS, TN NEXT-DAY MARKETPLACE

Local Marketplace MVP

2024

A full-stack Next.js marketplace built end-to-end: server-side-rendered product pages, real-time inventory using PostgreSQL row-level locks, a Stripe-backed checkout with webhook-driven order state, scheduled cutoff-time logic implemented as cron-style background jobs, and a brand-facing dashboard with role-based authentication.

Stack
Next.js · React · TailwindCSS · PostgreSQL · Stripe · Vercel
Engineering
Server-side rendering · Row-level locking · Webhook handlers · Scheduled jobs · Auth
Features
Cutoff-time order windows · Real-time inventory · Stripe checkout · Brand dashboard
No. 07
SUFYAN  ·  ENCRYPTED  ·  EPHEMERAL
YOU

What did we talk about yesterday?

SUFYAN

No record exists. By design.

ZERO RETENTION NO LOGS STREAMING

Sufyan — Privacy-First AI Assistant

2023

A personal AI assistant built on a Node.js / Express backend with OpenAI integration, designed around privacy as a first-class engineering constraint rather than a marketing line. No conversation logging, ephemeral in-process session memory, no database, and no third-party analytics. Streaming responses pass straight through the server to the client without capture.

Stack
Node.js · Express · OpenAI API · Vanilla JS / HTML / CSS
Privacy
Zero conversation logging · Ephemeral session state · No database · No third-party trackers · Rotating hashed-IP rate limits
Engineering
Streaming token responses · Server-side prompt assembly · Graceful timeout handling · Token-budget enforcement
Design
Warm, type-first interface that pushes back against the standard tech-blue chatbot aesthetic
Read case study

The constraint

The default architecture of an LLM-powered chatbot is: log everything, store conversations indefinitely, ship analytics. That is the path of least resistance, and most products take it. Sufyan was built around the opposite default — nothing is retained, nothing is logged, and the only state that exists is what’s needed for the current request.

Implementation

The Express server holds session memory only in-process, scoped to the active connection. When the connection closes, the data is gone. There is no database, no Redis cache, no analytics pixel. Rate limiting is enforced via in-memory token buckets keyed on hashed IPs that themselves rotate daily. Server logs capture only error states, never request bodies or response content.

OpenAI integration

Streaming responses are forwarded straight from the OpenAI API to the client through the Node.js server without server-side capture. The integration uses the API tier configured for no data retention, and prompts are assembled server-side so they are never exposed in client code.

Why this matters

The exercise was less about the chatbot itself and more about practicing privacy as a first-class engineering constraint — the same way I’d treat performance or reliability. Any system handling sensitive personal information benefits from this default, and the muscle of designing around it is worth building.

§ 03 Engineering Approach PRINCIPLES & PRACTICE
01

Schema-first design

Production systems live or die by their data model. I start with the relational schema — entities, relationships, constraints, indexes — before writing application code. Soft deletes, audit columns, and idempotency keys are part of the design from day one, not retrofitted later.

02

Idempotency & retries

Distributed systems fail. Webhooks deliver twice. Networks drop. Every write path I build assumes it will run more than once and produce the same result. This single discipline eliminated an entire class of duplicate-order and inventory-drift bugs at Valabasas.

03

Observability before features

Logging, metrics, and traceable error paths are not afterthoughts. If a system goes wrong in production at 2 AM, the only thing that matters is whether you can see what happened. I instrument first, build features second.

04

Treat AI as a dependency

LLM calls are network requests with quirks: variable latency, occasional nonsense, cost per call. I wrap them with timeouts, fallbacks, output validation, and eval harnesses — the same hygiene I’d apply to any third-party API. The model is a component, not a magic wand.

05

Code that reads cleanly

I write with the next engineer in mind — small functions, named intermediates, comments that explain why and not what. As the sole engineer on a complex stack, I’ve experienced first-hand the cost of code that’s clever rather than clear.

06

Ship, measure, iterate

I prefer a working v1 in production over a polished v2 in a branch. Once it’s live, real usage tells you what matters. Every system I run has metrics I check — not because I have to, but because the feedback loop is the work.

§ 04 Capabilities SPEC SHEET / 2026

Software Engineering

  • 01 Python · JavaScript · TypeScript · SQL
  • 02 React · React Native · Next.js · Three.js
  • 03 Node.js · Express · REST & GraphQL APIs
  • 04 PostgreSQL · Schema design · Query tuning
  • 05 System Architecture & Integration
  • 06 Authentication · RBAC · Audit Logging
  • 07 Webhooks · Event-driven Systems

AI & Machine Learning

  • 01 Large Language Models (GPT, Claude, Open-Source)
  • 02 Prompt Engineering & Eval Harnesses
  • 03 Retrieval-Augmented Generation
  • 04 Structured Output & JSON Schema Enforcement
  • 05 Computer Vision (OpenCV / MediaPipe)
  • 06 Image Generation Pipelines
  • 07 AI Agents & Workflow Automation

Practice & Domain

  • 01 End-to-End Product Ownership
  • 02 Shopify Platform & E-Commerce Systems
  • 03 ERP & Internal Tooling
  • 04 Mobile Application Development
  • 05 Vendor & Hardware Integration
  • 06 Technical Leadership & Mentorship
  • 07 Computer Science (B.S. in progress)
§ 05 Now UPDATED Q2 / 2026
Building

Valabasas Platform Hardening

Migrating internal services to TypeScript end-to-end, adding contract tests between API and mobile client, and tightening the deployment pipeline with automated rollback on failed health checks.

Studying

Computer Science at U of Memphis

Continuing my B.S. in Computer Science. Currently focused on systems, algorithms, and distributed computing — the formal foundations behind the engineering work I do daily.

Researching

Production AI Reliability

Tracking the gap between AI demos and AI in production: evaluation harnesses, observability for non-deterministic systems, and the operational discipline of running models at scale.

Open To

Senior Engineering Roles

Particularly interested in healthcare, fintech, and enterprise software in the Memphis area. Open to remote and hybrid. Comfortable as an individual contributor or technical lead.

§ 06 Contact

LET’S BUILD SOMETHING

Hiring a senior engineer worth keeping?

I’m open to senior software engineering roles in Memphis — healthcare, fintech, enterprise, or product — on-site, hybrid, or remote. Five years of full-stack production experience plus deep AI implementation work.

LinkedIn /in/shehab-ginem ↗
Based Memphis, Tennessee
Availability Q2 2026 — Open
Engagement Full-time · Contract · Advisory