Architecture & System Design
These are technical breakdowns, not marketing case studies: the problem each system had to solve, how it's actually built, the technology choices behind it, and where trade-offs were made. Anything not yet built is labeled conceptual rather than presented as delivered work.
Multi-Application Commerce & Offline POS Architecture
ImplementedOne backend as the source of truth for two very different clients — a public storefront and an in-store desktop POS that has to keep working offline.
Related case study: DollTop Commerce & POS PlatformProblem
A retail business sells through two channels — an online storefront and an in-store POS — that must share one catalog and one inventory, while the POS keeps functioning through unreliable in-store internet.
Requirements
- Single source of truth for catalog, inventory, orders, and customers across both channels.
- POS usable offline: build carts, complete sales, and queue orders for later sync.
- Independent device-level authentication for POS terminals, on top of staff logins.
Constraints
- Existing retail hardware uses ESC/POS-compatible receipt printers.
- POS needs to be an installable desktop app, not a browser tab, for reliable offline storage.
Diagram
Storefront (Next.js)
Desktop POS (Tauri)
Local SQLite cache + retry queue
Express API
Catalog · inventory · orders · customers · auth
PostgreSQL (Prisma ORM)
Technology choices
Choice
One shared Express/PostgreSQL API for both clients
Why
Avoids two systems drifting out of sync on catalog, pricing, or inventory.
Choice
SQLite cache + retry queue on the POS instead of a browser-based client
Why
Tauri gives the POS a real local database and offline execution a web tab can't guarantee.
Choice
JWT for staff sessions plus a separate terminal key for the device
Why
Lets a terminal operate (and re-authenticate) independently of which cashier is currently logged in.
Trade-offs
- Offline-first adds sync and conflict-handling complexity that a purely online POS wouldn't need — accepted because a lost sale is more costly than the added engineering effort.
- A single shared API simplifies consistency but becomes a dependency both channels rely on.
Considerations
Scalability
Centralizing catalog/inventory/order state in one API lets additional terminals or sales channels be added without introducing new sources of truth.
Security
Two-layer authentication (staff JWT + terminal key) plus role-based access control on operational endpoints.
Reliability
Local SQLite caching and a queued-retry sync path let the POS keep operating through connectivity loss instead of blocking checkout.
AI-Assisted Data Enrichment Workflow
ImplementedUsing an LLM to draft structured content inside a CRUD workflow, without letting it write to the database unreviewed.
Related case study: Smart Inventory HubProblem
Writing consistent, useful asset descriptions by hand doesn't scale as an inventory grows, but AI output shouldn't be trusted to save itself directly into production records.
Requirements
- Generate a draft description from existing asset data on request.
- Keep the draft editable before it's saved — no silent auto-save of AI output.
- Keep the generation call server-side so provider credentials never reach the client.
Diagram
User requests a description for an asset
Server Action
Calls Gemini 2.5 Flash server-side
Editable draft returned to the UI
User reviews, edits, and saves
PostgreSQL (Neon) via Drizzle ORM
Technology choices
Choice
Gemini 2.5 Flash called from a Server Action rather than the client
Why
Keeps the API key server-side and lets the response be shaped before it reaches the UI.
Choice
Return a draft instead of writing directly to PostgreSQL
Why
Keeps a human in the loop before generated text becomes part of a production record.
Considerations
Scalability
Generation is invoked per user action rather than in bulk, so cost and latency scale with actual usage rather than dataset size.
Security
Provider credentials stay server-side; generated content is scoped to the same per-user data-access rules as the rest of the asset table.
Authentication & Authorization Approaches Across Projects
ImplementedThree projects, three different auth models — chosen for what each system actually needed instead of one default pattern everywhere.
Problem
Authentication and authorization aren't one-size-fits-all: a single-tenant SaaS dashboard, a public marketplace with an admin tier, and a desktop POS terminal each have different trust boundaries.
Technology choices
Choice
Clerk — Smart Inventory Hub
Why
Managed auth for a single-tenant dashboard; the authenticated user ID is applied as a filter at the query layer so records are isolated per account.
Choice
Supabase Auth + PostgreSQL row-level security — Othman Real Estate
Why
A public marketplace needs open read access to listings but restricted dashboard/admin data — RLS enforces that at the database layer, not just in the UI.
Choice
JWT (staff) + terminal key (device) — DollTop POS
Why
A POS terminal needs to authenticate independently of who's logged in at the moment, alongside normal role-based staff permissions.
Considerations
Security
In every case, authorization is enforced closer to the data (query-level scoping or database RLS policies) rather than relying solely on UI checks.
AI-Configurable Inventory Modeling
ConceptualA proposed evolution of Smart Inventory Hub: let a business's own requirements shape its categories, fields, and dashboards instead of shipping one fixed schema.
Related case study: Smart Inventory HubProblem
Different businesses need different inventory structures — a hardware store's meaningful fields aren't a design studio's. Smart Inventory Hub currently ships with one fixed schema; letting a business's own requirements shape its categories, custom fields, and dashboard without custom development per customer is a natural next step, not yet built.
Requirements
- Capture business-specific requirements during onboarding.
- Use an LLM to propose categories and custom fields from those requirements.
- Let the user review and adjust the generated configuration before it's applied.
- Store the resulting schema per account and drive forms/dashboards from it.
Constraints
- Has to build on the existing Clerk-authenticated, per-account data model already in production.
- Generated configuration must be validated and editable — AI output should never apply unreviewed.
Technology choices
Choice
Reuse Gemini for schema/category suggestion
Why
Already integrated for description generation; a second AI provider isn't needed.
Choice
Store generated schema as structured, versioned configuration rather than free-form JSON
Why
Keeps the dashboard and forms predictable and keeps a reviewable diff when configuration changes.
Considerations
Scalability
A per-account schema model would let one deployment serve many business types instead of forking the application per customer.
Security
Generated configuration would sit behind the same per-account scoping already enforced for asset records.