Peter T ContiSOLUTIONS ARCHITECTURE | CLOUD ENGINEERING
  • Home
  • Case Studies
  • About
  • Contact
Back to Case Studies
Art & CommerceFine's GalleryOngoing platform build + fractional CTOCustom Business Application DevelopmentCustom High-Ticket Ecommerce PlatformsTerraform AWS Infrastructure and Cloud SecurityCommerce Data, Performance, and AutomationFractional CTO and AWS Solutions Architect
Published July 19, 2026
Fine's Gallery Logo

Fine's Gallery Platform Modernization

From a catalog-only website with no online payment to a transactional commerce and operations platform running inside the client’s own AWS Organization.

    Explore Platform Build Options

Fine’s Gallery began with a catalog-only website: customers could browse thousands of high-value products, but they could not complete payment online. Sales happened through staff, phone, email, showroom conversations, FileMaker, and disconnected vendor tools. I built the first transactional commerce and operations platform inside the client’s own AWS Organization. It now supports millions in annual revenue, including six-figure monthly commerce volume; migrated 28,062 invoices and more than 20 years of operating history without loss or duplicate invoice numbers; and cut over with zero downtime. The custom quote, deposit, ACH, wire, check, signature, fulfillment, acquisition-feed, and staff workflows are now operated through a Fractional CTO retainer.

Key Results

Annual commerce volume

Millions in annual revenue

User acquisition lift

+40%

Production cutover

Zero downtime

Where this engagement starts

The problem

Fine’s Gallery sells high-value marble and bronze fireplaces, fountains, statues, and architectural items. The pre-existing web presence was a product catalog. The buying workflow was offline, fragmented across FileMaker, spreadsheets, and outside vendor tooling, and meaningful transactional operations either happened by phone or were recreated manually downstream.

The objective was to build a complete order-to-cash commerce platform that owns the storefront, the staff operating surface, the payment and invoicing flows, the integration boundary with Stripe, DocuSign, Klaviyo, Google Merchant Center, GA4, Pinterest, and the legacy FileMaker system, plus a sovereign AWS Organization to run it inside and an async event-driven backbone for everything that should not block a request. Solo delivery, end to end.

Engineering memo

Key decisions

What was decided, why, and what was deliberately not done.

  1. 01

    Run the platform inside a sovereign, client-owned AWS Organization.

    Rationale

    Fine's owns its multi-account AWS Organization outright. No shared vendor account, no platform lock-in, predictable billing. Every workload runs under the client's Org with explicit IAM trust boundaries and first-party services: ECS Fargate for the application tier, RDS for Postgres, S3 and CloudFront for media, plus an event-driven backbone built on SQS queues (email, document, business operations, media, nightly cron) with dedicated Lambda workers, EventBridge Scheduler for delayed dispatch, and MediaConvert for product video transcoding.

    Alternative considered

    A managed-vendor stack like Shopify Plus or a headless commerce SaaS would have left payment data, customer records, and operational workflows inside another company’s perimeter. At this order complexity, platform and payment economics also required a business-specific model rather than a generic rate assumption.

  2. 02

    Use Payload CMS as the staff operating surface, not just the marketing CMS.

    Rationale

    Payload collections model the full luxury-commerce domain: Orders, Invoices, Payments, Products, Customers, Categories, Documents, and dozens more. Staff manage the entire catalog, order lifecycle, payment ledger, DocuSign envelopes, and invoicing inside one admin surface rather than across a stack of disconnected tools, with full role-based dashboards allowing management of the business workflow.

    Alternative considered

    A headless marketing CMS plus a separate custom back office would have recreated the exact tool-stack fragmentation the platform was meant to remove.

  3. 03

    Give every order an explicit state machine and track payment, fulfillment, signature, and inventory state independently.

    Rationale

    A dedicated OrderService coordinates transitions across more than ten statuses with atomic state changes. Each order carries six concurrent state trees in one document: order status, payment state, fulfillment state, signature state, inventory state, and deposit state. Transitions are explicit and validated against a state machine, with invalid transitions rejected at the service level. A dedicated invoicing system generates PDFs from order data, syncs deposits and payments to the order ledger, and routes to DocuSign for signature workflows.

    Alternative considered

    Implicit state inferred from booleans and timestamps, which would be easy to implement but hard to reason about under concurrency. With each order representing a significant financial transaction, this tradeoff is unacceptable.

Outcomes

Outcomes (with sources)

Real metrics with attribution. Numbers without sources read as marketing. Every claim here is sourced.

  • Metric

    Monthly online commerce volume

    Before

    Prior web presence was product-catalog-oriented, not transactional.

    After

    Six-figure monthly commerce volume flows through the platform across catalog, quote, invoice, payment, signature, fulfillment, and staff operations.

    Source: Fine's Gallery platform operations

  • Metric

    User acquisition after platform cutover

    Before

    Pre-cutover analytics baseline.

    After

    +40% increase in user acquisition after launch, sustained through ongoing GA4 / Klaviyo / Pinterest / GMC integration work.

    Source: Fine's Gallery post-cutover analytics

  • Metric

    Infrastructure ownership

    Before

    Prior platform was vendor-hosted; data and operational logic lived inside a third-party perimeter.

    After

    Sovereign AWS Organization, owned end to end by Fine's. Full IaC, full client control.

    Source: Fine's Gallery AWS Organization (OU-managed)

  • Metric

    Legacy system retirement (FileMaker)

    Before

    FileMaker was the system of record for 20+ years of quotes, invoices, and operational state. Reconciliation between FileMaker and the commerce platform was manual and error-prone.

    After

    FileMaker fully retired from the active stack. 28,000+ historical invoice records migrated into platform-native invoicing inside Payload + Postgres. Quotes, invoices, payment ledger, customer PDFs, and DocuSign workflows now compose with orders directly. No vendor lock-in to a 20-year-old desktop database.

    Source: Fine's Gallery production migration (audit: 28,062 unique invoice numbers, 0 duplicates, strict payment-ledger audit exit code 0)

Case Study: Fine's Gallery

Enterprise Platform Modernization & Sovereign AWS Architecture

The Objective: Transform a catalog-only website, where every sale was completed through staff, phone, email, showroom conversations, and legacy tools, into a transactional commerce and operations platform without losing the consultative, high-touch sale.

The Role: Lead Solutions Architect & Full-Stack Engineer (End-to-End Solo Delivery, now ongoing as a Fractional CTO retainer).

Fine’s Gallery sells high-value marble and bronze fireplaces, fountains, statues, and architectural items. Its pre-existing website displayed the catalog, but customers could not complete payment online. Every sale moved off the website into phone calls, email, showroom conversations, FileMaker, spreadsheets, payment coordination, and outside vendor tooling. The objective was not to add a generic cart. It was to build the company’s first transactional channel and a vertically integrated commerce platform that owns every step of the order-to-cash workflow, retires the legacy operational stack, and runs in infrastructure the client owns end to end.

I architected and deployed that platform inside the client’s own AWS Organization. It now supports millions in annual revenue and hundreds of thousands a month in commerce volume, cut over to production with zero downtime, and migrated 28,062 invoice records spanning more than 20 years without loss or duplicate invoice numbers. FileMaker and the vendor SaaS workflows it replaced have been retired from the active operating stack.

Download the video
0:00 / 0:00
Fines Gallery Custom Sales Dashboard / Control Center

2. Business Impact

Technology only matters if it drives the business forward. The platform's business outcomes are the only ones that count.

  • Annual revenue: Millions flowing through the custom platform, including high-ticket marble orders that previously required offline handling.
  • Production cutover: Zero downtime. Cut over to the custom AWS platform without losing a single order, customer record, or signed document in transition.
  • Legacy data migration: 20+ years of operational data (28,000+ historical invoice records, customer accounts, order history, ~10,000 products) migrated into the new platform without loss. Strictly rehearsed and well-orchestrated migration processes ensured absolute data integrity.
  • Vendor lock-in retired: FileMaker fully removed from the active stack. SaaS commerce tooling, plugin marketplaces, and third-party operational consoles systematically replaced with first-party platform-native workflows.
  • User acquisition: +40% sustained increase post-cutover (June 2025 baseline through February 2026), driven by first-party Klaviyo, Pinterest, GA4, GMC, and CallRail integration work.
Fine's Gallery User Acquisition Analytics

Fine's Gallery User Acquisition Analytics

Direct user acquisition over the period from production cutover (06-01-2025) through 02-22-2026, compared against the preceding period. Sustained growth post-cutover.

3. Core Technology & Sovereign Architecture

To ensure data integrity and platform sovereignty, I designed the architecture as layered AWS services with explicit security and responsibility boundaries. Every workload runs inside the client's own AWS Organization. The application tier runs on ECS Fargate with RDS Postgres and S3 as the data stores. CloudFront / WAF serves statically-generated content from the Edge at high speeds for storefront customers using revalidation-based ISR. An event-driven backbone built on SQS queues (email, document, business operations, media, nightly cron) with dedicated Lambda workers and EventBridge Scheduler for delayed dispatch ensures reliable async processing. MediaConvert handles product video transcoding at upload.

The Stack:

  • Cloud & Infrastructure: AWS sovereign Organization spanning ECS Fargate, RDS PostgreSQL, S3, CloudFront, Lambda, SQS, EventBridge, EventBridge Scheduler, MediaConvert, KMS, IAM, and Secrets Manager.
  • Application Layer: Next.js 15 (Web/Routing/Server Components), Payload CMS 3 (Admin/APIs, custom admin dashboards, email templates, checkout and payment flows).
  • Async Backbone: SQS queues (Email, Document, BusinessOps, Media, NightlyCron), Lambda workers, typed task contracts, dedicated DLQs, CloudWatch alarms, and a 60-second outbox publisher for retry recovery.
  • Integrations: Stripe (full PaymentIntent, Tax, Refund, Terminal lifecycle), DocuSign, Klaviyo, Google Merchant Center, Google Analytics 4, Pinterest, CallRail, Meta.
Sovereign client-owned AWS Organization topology: WAFv2 + CloudFront edge, ECS Fargate application tier, RDS PostgreSQL + S3 data tier, SQS + Lambda async backbone with EventBridge / MediaConvert / outbox publisher, KMS / IAM / Secrets Manager security, and first-party integrations with Stripe / DocuSign / Klaviyo / GMC / GA4 / Pinterest / CallRail.

Fine's Gallery production AWS topology. Customers and staff hit a WAFv2 + CloudFront edge; the application tier (Next.js + Payload on ECS Fargate) writes to RDS PostgreSQL in private subnets and serves media from S3 through the same CloudFront distribution at /media/*. SQS queues feed Lambda workers with typed task contracts to form the Async Backbone; EventBridge Scheduler fires nightly cron rules; MediaConvert handles video transcoding; an outbox publisher recovers any operation stuck in pending. Identity is STS-only end to end: GitHub OIDC for CI, ECS task role at runtime, no long-lived credentials anywhere.

Edge & Delivery Layer

CloudFront (behind WAF) handles edge routing and caching policy segmentation, resolving static media to S3 and dynamic routes to ECS-hosted services. All pages are statically generated at build-time, and updates automatically trigger both Next.js and CloudFront tag and path-based invalidations. Cloudflare Turnstile sits in front of every form-submission endpoint to defeat automation without forcing CAPTCHA friction on real customers.

Compute & Domain Layer

Core platform services run on ECS Fargate. Domain boundaries are maintained in code through strict access controls: role-scoped APIs for staff workflows, and a secure administrative surface in Payload via role-based operational dashboards that unifies all back-office workflows in a single interface.

Data & Integrity Layer

RDS PostgreSQL serves as the immutable source of truth for commerce, inventory, and operations data. Relational modeling enforces consistency across the entire order lifecycle, with write-time business rules governed by authoritative services. Order documents carry six concurrent state trees (order status, payment, fulfillment, signature, inventory, deposit) that the application explicitly transitions atomically.

System context for the Fine's Gallery commerce platform: customers and staff interact with the storefront and admin surface; the backend composes order state, invoicing, payment ledger, and the async backbone, and integrates with Stripe / DocuSign / Klaviyo / GMC / GA4 / Pinterest / CallRail.

System context for the Fine's Gallery commerce platform: customers and staff interact with the storefront and admin surface; the backend composes order state, invoicing, payment ledger, and the async backbone, and integrates with Stripe / DocuSign / Klaviyo / GMC / GA4 / Pinterest / CallRail.

4. Operational Governance: The Order State Machine

High-value transactions require absolute determinism. I engineered a formal, auditable order state machine that ensures every transition (payment, fulfillment, signature, inventory) is explicit, validated, and automation-safe. Invalid transitions are rejected at the service layer; the system refuses to silently permit a stale or out-of-sequence change.

Download the video
0:00 / 0:00

Fine's Gallery Order State Machine (Sales Interface)

Strict State Controls:

  • Payment Gates: Fulfillment pipelines cannot execute prior to validated payment states. Stripe webhooks settle deposits and ACH transfers, with wire and check settlements reconciled into the order state machine through the staff admin interface.
  • Signature Gates: High-liability orders enforce DocuSign envelope completion before progressing to inventory allocation. Webhook envelope tracking is wired across the pipeline so the order document always reflects ground truth on the signature state.
  • Inventory Gates: Reserved inventory transitions are mathematically tied to payment progression to prevent stock discrepancies. The same item cannot be sold twice during a deposit-to-balance lifecycle.
  • Deposit & Balance Lifecycle: Every order can carry a non-refundable card deposit and a separately reconciled ACH/wire/check balance. The state machine tracks both independently, and the staff surface presents a unified view per order.
Fine's Gallery Order State Machine

Fine's Gallery Order State Machine

5. Custom Payment Flows: ACH, Wire, Check, and a Bounded Card Deposit

Percentage-based payment costs become material at high order values, but the honest comparison must use the client’s contracted rates and actual payment mix. The model includes platform subscription, transaction fees, required apps, tax and fraud tooling, refunds and chargebacks, operating labor, and the cost of owning a replacement system. That analysis determines whether custom architecture is justified; the answer is not assumed in advance.

Payment Flow Highlights:

  • Stripe deposits: Card payments accepted for deposits on orders to reserve merchandise; handled via Stripe PaymentIntent
  • Stripe Tax: Real-time jurisdiction-aware tax calculation, with transaction recording and compliance documentation tied to the order ledger.
  • ACH workflow: ACH payments facilitated through Stripe ACH Direct Debit, with customers able to securely log into their bank, select an account, and authorize debits directly from our platform. ACH settlement tracked through Stripe webhooks to AWS API Gateway and reconciled into the order state machine.
  • Check / Wire workflow: Check / Wire instructions generated and emailed on demand per order in response to customer actions, with reference numbers tied to the order; staff reconciles settlement against bank confirmation.
  • Stripe Terminal: Physical card-reader integration for in-showroom deposit payments, sharing the same Stripe customer/payment infrastructure as the online flow.

6. Asynchronous Processing: SQS / Lambda Event-Driven Backbone

To maintain high performance, every operation that can be slow, retried, or scheduled is decoupled from the request path and executed on a dedicated event-driven backbone. The backbone consists of SQS queues, Lambda workers, typed task contracts, dedicated dead-letter queues, CloudWatch alarms on DLQ depth and oldest-message age, and a cron that republishes any operation stuck in pending or unknown delivery states.

Queue Topology:

  • EmailQueue: Transactional and lifecycle email dispatch.
  • DocumentQueue: DocuSign envelope creation, status webhooks, and PDF generation pipelines.
  • BusinessOpsQueue: Payment reminders, promotion endings, category re-ordering, conversion event dispatch, and Pinterest pin publishing.
  • MediaQueue: Video processing through MediaConvert, media metadata updates, and image-pipeline workers.
  • NightlyCronQueue: Catalog syncs (Klaviyo, Pinterest), product inventory sync, and the daily Google Merchant Center feed export.

One external-event Queue:

  • StripeWebhookQueue: Stripe webhook events are critical financial transactions and are handled separately. Stripe events POST to an API Gateway endpoint that queues to SQS and is processed by a Lambda that verifies the Stripe event, and initiates a privileged request to append to the payments ledger. This is the only write path for ACH payments.

Reliability Posture:

  • Typed task contracts: Each of the task types ships with a Zod input schema. Producer and Lambda worker cannot drift on payload shape.
  • Idempotency keys: At the database row level. SQS at-least-once delivery cannot produce duplicate side effects.
  • Dedicated DLQs: Every primary queue has a DLQ; CloudWatch alarms fire on depth or oldest-message age.
  • Outbox publisher: 60-second cron republishes any operation in pending_enqueue or unknown_delivery_state. At-least-once delivery is recoverable.
  • CloudWatch namespace: FinesGallery/AsyncOperations dashboards every queue and every task type.

The backbone shipped through a per-task feature-flag staircase (original system: payload-jobs) so each migration soaked real production traffic before retiring the legacy path. The dual-write phase has now been retired across all task types, and the SQS / Lambda backbone is the sole async handler in production.

Async backbone: producers (web requests, EventBridge Scheduler, third-party webhooks) publish to 5 SQS queues; 5 Lambda workers consume them with typed task contracts; each queue has a DLQ wired into CloudWatch alarms; an outbox publisher republishes any operation stuck in pending or unknown delivery state.

Async backbone: producers (web requests, EventBridge Scheduler, third-party webhooks) publish to SQS queues; Lambda workers consume them with typed task contracts; each queue has a DLQ wired into CloudWatch alarms; an outbox publisher republishes any operation stuck in pending or unknown delivery state.

Fine's Gallery Order to Cash Mermaid Diagram

Fine's Gallery Order to Cash Mermaid Diagram

Media Pipelines:

MediaConvert handles long-running video transcoding for product showcase reels. EventBridge captures completion callbacks and routes them to a Lambda completion handler that updates the media metadata, regenerates derivative assets, and notifies the staff surface. Image transformations run through Sharp on demand at the Next.js layer, served through CloudFront with aggressive caching.

7. Replacing 20 Years of FileMaker

FileMaker held two decades of operational truth: 28,000+ invoice records, sequential invoice numbers staff and customers recognized, free-text fields used as flexible business cells, and a record-oriented workflow staff could move through with muscle memory. Replacing it was not a cleanup project. If the replacement failed, staff would lose the workflow they relied on to sell, collect payment, coordinate shipping, and keep expensive orders straight.

The replacement is now in production. FileMaker is fully retired from the active stack. Quotes, invoices, payment ledger, signed customer PDFs, and DocuSign workflows are platform-native records inside Payload + Postgres. Staff use a custom FileMaker-style admin surface (search, found-set navigation, jump-to-record, autosave, dirty-state protection) on top of a safer modern data model. PDF rendering shares a layout planner with the admin editor, so screen and print stay consistent.

Migration Audit (production-clone rehearsal):

  • Invoice records migrated: 28,062 unique invoice numbers in the FileMaker export, 28,062 platform invoice records produced.
  • Duplicate invoice numbers: 0.
  • Invoice-order relation anomalies: 0.
  • Strict payment-ledger audit: Exit code 0.
  • Legacy payments backfilled: 350.
  • Orphan invoice deposits: 12, deferred by policy instead of forced into the ledger. Money movement is not an area where probably correct is good enough.

Full write-up of the migration approach and the engineering decisions that made it safe to ship lives in a separate post here.

8. Integrations as First-Party Adapters

Every external integration is owned. Each adapter lives behind a typed boundary, with Zod input validation, retry semantics, and dedicated tests.

  • Stripe: Full PaymentIntent lifecycle, Stripe Tax, Refunds, and Stripe Terminal for in-showroom card present.
  • DocuSign: Signature requests, terms-of-sale templates, envelope status webhook tracking, complete PDF composition from input images and templates.
  • Klaviyo: Catalog sync (nightly Lambda), customer segmentation, conversion event dispatch.
  • Google Merchant Center: Daily product feed sync, GMC category resolution, local-inventory feed auto-export.
  • Google Analytics 4: Full conversion tracking, admin dashboards with real-time performance charts and metrics per resource.
  • Pinterest: Catalog automation, audience segmentation, pin publishing workflow, feed builder, full product catalog sync.
  • CallRail: Lead attribution tracking, form submission capture, phone-call correlation to orders, call information stored to database via webhook for real-time attribution.
  • Cloudflare Turnstile: Bot protection on every form-submission endpoint.

9. Operations & Reliability

Complete CI/CD pipeline built on GitHub Actions, with automated production deployments, database migrations, testing, and branch environments. Centralized logging solution implemented with Cloudwatch Logs, monitoring through Cloudwatch Alarms, active-passive DR plan in place with RDS cross-region read replica and automated failover strategy.

Deployments use GitHub OIDC trust to AWS. Zero long-lived IAM keys exist across any AWS account or deployment environment. Every deploy runs as a short-lived assumed role with least-privilege permissions.

The Bottom Line

This architecture was not built just to serve web pages. It was built to run a luxury commerce business at the order-value scale where the templated SaaS economics break down. By bridging rigorous data modeling with sovereign AWS infrastructure, retiring two decades of legacy operational tooling, and building a payment model that respects the actual economics of high-ticket sales, Fine's Gallery now operates on a platform that enforces business logic, secures customer data, owns the integration surface, and scales with revenue growth instead of taxing it.

Solo-built, end to end.

If your business is outgrowing the platform that got you here

High-ticket commerce, legacy operational tooling, multi-channel order workflows where the SaaS stack is starting to cost more than it returns. Thirty minutes is enough to know whether the practice is a fit.

Book a consultation

What the client said

“Mr. Peter, as our technology partner, built our entire commerce and operations platform from the ground up on AWS. It runs our website, our orders, our invoicing, our payments, everything. Migrating to the new system was seamless, with no interruption or data loss. Peter is honest, a strong communicator, and when something needs attention, he takes care of it fast. I trust him with the most important systems in my company. Highly recommended.”
Owner, Fine's Gallery
Peter T ContiSOLUTIONS ARCHITECTURE | CLOUD ENGINEERING

Solutions Architecture | Cloud Engineering

Solutions architecture and cloud engineering for teams that need production-ready systems, clean delivery workflows, and measurable business impact.

Conti Digital LLC548 4th Ave S.Naples, FL 34102
Book a free 30 min consultation30 min

Explore

  • Services
  • Pricing
  • Case Studies
  • Open Source
  • About
  • Contact

Connect

  • peter@petertconti.com
  • (215) 760-8590
  • Google Business Profile
  • LinkedIn
  • GitHub

© 2026 Conti Digital

Solutions Architecture, Cloud Engineering, Platform Delivery

AWS Partner Network · Services Path
Privacy