# Mustafa Khan > I build products that stay useful I design and build the interfaces behind live auctions, apparel quotes, embroidery production, hospitality supply, and South Asian couture — products where the next decision needs to be easy to see. Public CMS-authored portfolio information. Canonical HTML pages are the primary sources: https://mustafakhan.dev/ ## About I work across product structure, interface design, and the code that makes both hold together. The useful work is usually in the middle: naming a service, ordering a catalogue, exposing a price, or deciding what someone needs to know before they ask for a quote. The featured product stories follow Auctibuy, Liberty Digitizing, Digitizing Depot, Spider Digitizing, Affinity Hospitality UAE, and TY Dress Collection. Further work includes the terminal tools Relay and Gitscape, the Hamwas agency website, Star Tourism, and Global Beauty Verse. Each project has its own stack, audience, and workflow. ## Availability Available for selected product builds ## Public contact email me@mustafakhan.dev ## Canonical pages and profiles - [Home](https://mustafakhan.dev/) - [About and experience](https://mustafakhan.dev/about) - [Services](https://mustafakhan.dev/services) - [Work](https://mustafakhan.dev/work) - [Interactive product workbench](https://mustafakhan.dev/lab) - [Journal](https://mustafakhan.dev/journal) - [Contact](https://mustafakhan.dev/contact) - [Start a project](https://mustafakhan.dev/quote) - [Sitemap](https://mustafakhan.dev/sitemap.xml) - [GitHub](https://github.com/Mustafa-KhanDev) ## Case studies ### Auctibuy Canonical source: https://mustafakhan.dev/work/auctibuy #### Summary A real-time auction marketplace connecting discovery, creator operations, bidding, specialist roles, and account workflows. #### Overview Auctibuy combines a consumer marketplace with the operational tools behind live commerce. My work spans the React interface and the Express API: browsing a feed, entering an auction, creating a listing, managing an account, and administering the platform are connected journeys with different permissions. Those journeys share an authoritative auction model, with room state kept in step through real-time updates and polling. The product brings discovery, participation, and seller operations into one experience. #### Category Marketplace / Live commerce #### Client Auctibuy #### Year 2026 #### Role Product design + full-stack engineering #### Technology stack TypeScript React 19 Vite 6 React Router 7 Node.js / Express 4 MongoDB / Mongoose 8 Redis WebSocket / ws Zod / JWT #### Problem statement Connect discovery, participation, and seller operations while keeping auction decisions authoritative and each account’s available actions explicit. #### Situation A visitor can arrive through a feed or Explore, inspect an item and its seller, and move into a live room. Returning users also need watchlists, inbox activity, and account tools. Creators need a studio for their selling work; administrators need moderation and audit surfaces. The product therefore extends beyond the public auction screen. #### Tension The interface needs rapid price and activity updates, while each bid must be checked against the current auction in the database. Discovery should stay approachable as sellers, specialists, and administrators handle more complex responsibilities. Current price, participation state, and the server’s response to a bid all need to remain clear within the pace of a live room. #### Key decision Separate the consumer, creator, and administration surfaces around a shared API. Keep MongoDB authoritative for auction mutations, use Redis for derived hot state and fan-out, and retain polling when the live connection is unavailable. Make the route from item context to participation readable before exposing the next action. #### Responsibilities My implementation spans product structure, responsive React screens, typed API integration, and the Node.js service layer. That includes the feed and Explore journey, auction-room states, creator studio, account watchlists and inbox, plus moderation and audit operations. I also connected validation, authentication, auction rules, and provider-facing settlement services so the interface follows the backend’s workflow states and commercial rules. #### Architecture The workspace separates an Express 4 API from a React 19 application built with TypeScript, Vite 6, and React Router 7. Mongoose 8 maps the MongoDB domain models; Zod validates request shapes and JWT supports session authentication. MongoDB is the source of truth, with version-keyed compare-and-swap and transaction paths for auction mutations. Redis accelerates derived room state and distributes events through pub/sub. The ws transport delivers authenticated room updates, with HTTP polling retained as a fallback. Audit, inbox, and real-time side effects follow the committed domain operation. The provider-facing service layer handles settlement workflows separately from auction mutations and room updates. #### Access control The API defines admin, seller, valuator, estate-agent, trader, escrow-provider, and bidder roles. Capabilities include buyer, seller, the four specialist roles, brand-account, dealership, and admin. JWT identifies the session; authorization hydrates the user from a fresh database read and evaluates the account’s current effective roles and capabilities. requireRole accepts a matching effective role or capability. Session-version checks support revocation. Authenticated WebSocket delivery rechecks the account against the database, so access to room events follows current authorization as well as the initial connection. #### System The consumer loop is discover, inspect, enter a room, read current state, and submit an eligible action. Creator tools prepare and manage the selling side; account areas collect watchlists and inbox activity. Administration handles moderation and operational review. Auction state, room messages, and settlement workflow remain distinct concerns even when they meet on the same screen. #### Evidence Explore and auction rooms present item, seller, and participation context, while the creator studio and account areas support listing work, watchlists, and inbox activity. Separate web and API applications contain the auction transaction paths, Redis hot-state and pub/sub modules, authenticated room delivery, and polling fallback. Moderation and audit tools give administrators a dedicated operational surface. #### Next iteration Exercise the browse-to-room journey on a slow connection and compare connected, stale, and polling states. Review how a first-time bidder understands eligibility and the response to a submitted action, and how a creator moves from preparing a listing to following its operational state. #### Features Feed and Explore discovery Live auction rooms and bid states Creator studio and listing workflows Account watchlists and inbox Effective roles and capabilities Moderation and audit operations WebSocket updates with polling fallback Provider-facing settlement workflows #### Screen captions Auctibuy homepage — live auction marketplace Auctibuy Explore — auction discovery Auctibuy auction room — item, seller, and bid state Live product: https://auctibuy.com Cover image: https://mustafakhan.dev/images/case-studies/auctibuy-live-home.webp #### Screens - [Auctibuy homepage — live auction marketplace](https://mustafakhan.dev/images/case-studies/auctibuy-live-home.webp) - [Auctibuy Explore — auction discovery](https://mustafakhan.dev/images/case-studies/auctibuy-live-explore.webp) - [Auctibuy auction room — item, seller, and bid state](https://mustafakhan.dev/images/case-studies/auctibuy-live-room.webp) --- ### Liberty Digitizing Canonical source: https://mustafakhan.dev/work/liberty-digitizing-rebuilt #### Summary A PHP/MySQL storefront and production system joining apparel, service quotes, customer accounts, and staff handoffs. #### Overview Liberty Digitizing combines an apparel and service storefront with an existing production operation. Customers browse garments, patches, sports apparel, and digitizing or vector services, then continue through a quote or customer account. Behind that public surface are quote and order queues, designer assignments, delivery files, invoices, and reporting. My work connects the public experience to those operational paths while respecting the existing PHP application and its separate staff portals. #### Category Commerce / Production operations #### Client Liberty Digitizing #### Year 2026 #### Role Product design + PHP full-stack engineering #### Technology stack PHP MySQL PDO Legacy mysqli integration HTML / CSS Vanilla JavaScript #### Problem statement Give different buyers a clear shopping or quote route, then carry their request into a production workflow staff can price, assign, deliver, and invoice. #### Situation The same brand serves someone choosing apparel and someone supplying artwork for embroidery or vector work. Public pricing, portfolio context, customer login, and quote requests sit beside the catalogue. Existing staff operations already distinguish work awaiting a price, production work in progress, and work ready for the next handoff. #### Tension A catalogue shopper needs product families and a quick route through the offer. A production customer needs to explain a job and return to its files or account. Staff need queue-level detail, assignment context, and commercial records. The implementation also needs to work with the established PHP database paths and independently authenticated portals that support the business’s daily operations. #### Key decision Organise the storefront around named apparel and service lanes, with Get Quote and Customer Login as visible next steps. Connect the public and customer work to the existing operational states, and introduce shared PHP helpers where they fit while retaining compatible legacy mysqli paths. #### Responsibilities My scope includes the public navigation, responsive storefront pages, quote entry, customer-facing account flow, and the PHP/MySQL connections behind the experience. The operational work covers quotes becoming orders, embroidery and vector queues, assignments, file handoffs, invoices, and the reports staff use to follow production and commissions. I also built the Ask Liberty guided-help widget, whose authored question-and-answer tree routes visitors to relevant service information or a human contact path. #### Architecture Server-rendered PHP supplies the pages, with HTML, CSS, and vanilla JavaScript handling the browser layer. A newer core uses PDO-backed database access and shared request/session helpers alongside preserved mysqli-based legacy modules. Customer account pages use a session guard; the storefront and account share a shell, while administration, designer, and partner areas have separate page structures and authentication. Quote and order records connect to assigned production work, file slots, invoice records, and reporting. Ask Liberty reads an authored answer tree from include/chat_data.php, with assets/js/chat.js presenting the guided choices and answers in the browser. #### Access control Customer account access is session-gated through account/guard.php. The administrator, designer, and partner portals use separate authentication paths with different operational purposes. Administrators manage production queues and commercial records; designer-facing work centres on assigned production, and partner-facing work includes its own reporting context. Each portal provides an entry point suited to the work its users need to carry out. #### System A new buyer enters through apparel, patches, sports, or services and supplies quote context when the job needs pricing. Staff review the request, move it into an order or vector queue, handle unpriced and ready states, assign production, and attach files. Customer access, invoicing, performance reporting, and commission views support the continuing relationship after the initial form. #### Evidence The storefront separates apparel, patches, sports, and service lanes, with public pricing, quote entry, and customer login close to the browsing journey. Staff screens expose quote-to-order operations, unpriced and ready queues, assignments, file handling, invoices, and operational reports. Ask Liberty pairs a PHP-authored content tree with a JavaScript widget that lets visitors follow questions to service information or contact. #### Next iteration Follow one apparel enquiry and one artwork job from the public form through pricing, assignment, file delivery, and the customer account. Use those observations to clarify labels and reduce repeated data entry at handoffs while retaining the information production needs. #### Features Apparel, patch, and sports storefront paths Digitizing and vector service quotes Session-gated customer account Quote-to-order and production queues Unpriced and ready work states Designer assignments and file handoffs Invoices and operational reporting Performance and commission views Ask Liberty guided-help widget #### Screen captions Liberty Digitizing homepage — apparel, services, and quote entry points Liberty Digitizing catalogue — T-shirt styles and product options Liberty Digitizing pricing — published production rates Live product: https://libertydigitizing.com Cover image: https://mustafakhan.dev/images/case-studies/liberty-live-home.webp #### Screens - [Liberty Digitizing homepage — apparel, services, and quote entry points](https://mustafakhan.dev/images/case-studies/liberty-live-home.webp) - [Liberty Digitizing catalogue — T-shirt styles and product options](https://mustafakhan.dev/images/case-studies/liberty-live-catalogue.webp) - [Liberty Digitizing pricing — published production rates](https://mustafakhan.dev/images/case-studies/liberty-live-pricing.webp) --- ### Digitizing Depot Canonical source: https://mustafakhan.dev/work/digitizing-depot-rebuilt #### Summary A WordPress service storefront supported by separate PHP/MySQL production operations and a custom guided-help plugin. #### Overview Digitizing Depot’s public website and production administration are separate systems serving the same business. The WordPress website presents apparel, patches, sports products, and services; the PHP/MySQL operations application handles the detail after a request reaches staff. My work covers catalogue structure, quote entry, guided help, and the workflows behind production handoffs. Together, those surfaces give visitors a way to explain a request and staff the context to take it forward. #### Category WordPress / Service operations #### Client Digitizing Depot #### Year 2026 #### Role Website design + WordPress and PHP engineering #### Technology stack WordPress PHP MySQL HTML / CSS JavaScript Custom WordPress plugin #### Problem statement Make a broad production offer easier to enter, while keeping catalogue content, customer enquiries, and staff production work in their appropriate systems. #### Situation The public offer includes apparel, patches, sports apparel, digitizing, vector work, web services, pricing, and portfolio context. A quick-order or quote route helps visitors turn that breadth into a specific request. Separately, the operations application contains the customer, employee, designer, salesman, invoice, and production records staff need to do the work. #### Tension The service range needs enough detail to communicate capability and enough structure to help a new buyer choose a starting point. Staff need a different level of detail around queues, files, invoices, and customer records. WordPress content publishing and PHP production administration each have their own interface and account context, so both sides need clear entry points. #### Key decision Use service families, public pricing, portfolio context, and a quick-order action as the public organising structure. Keep production administration separate, and add a WordPress-native guided-help plugin that answers common questions through authored choices and directs the visitor toward an appropriate next step. #### Responsibilities My work covers the public website’s service and catalogue structure, responsive page experience, enquiry entry points, and the Ask Depot guided-help plugin. On the operations side, the implementation includes the PHP administration paths for production queues, invoice and file handling, exports, and customer/staff records. My responsibility spans the presentation of the offer and the operational stages staff use to organise work, handle files, and follow commercial records across these two applications. #### Architecture WordPress manages the public website. The custom digitizing-depot-assistant plugin provides the guided-help experience through WordPress hooks, browser assets, and an authored answer structure. A separate PHP/MySQL operations application contains route families for production queues, invoices, files, exports, customers, employees, designers, and salesmen. Public content and production records remain separate application concerns: WordPress supplies the service catalogue and enquiry presentation, while PHP screens organise the records and actions used in the ongoing production workflow. #### Access control core/Auth.php provides the session-based administrator gate for the operations application. Inside that surface, route families organise customer, employee, designer, and salesman records alongside production queues, files, invoices, and exports. WordPress manages public content in its own publishing environment. The two applications keep content administration and production administration in their respective account contexts. #### System A visitor narrows the request through a service or product family, consults pricing or portfolio examples, and starts a quick order or enquiry. Guided help offers another route through common questions. Once work reaches staff, production queues, assignments, files, invoices, and exports provide the operational context. The public site introduces the offer; the operations application supports the ongoing job. #### Evidence The public catalogue presents product and service families beside pricing, portfolio links, and enquiry actions. Ask Depot’s WordPress plugin packages its authored answers, hooks, and browser assets into a guided-help experience. The PHP administration screens provide production queues, file and invoice handling, exports, and customer/staff record management, making the stages behind a service request concrete. #### Next iteration Compare the terminology customers use in an enquiry with the public category labels and the production queue names. Review where a request needs additional explanation before staff can act, and make that handoff clearer in the public form and guided-help content. #### Features WordPress service and apparel catalogue Pricing and portfolio context Quick-order and enquiry routes Ask Depot guided-help plugin Separate PHP production administration Production queues and file handling Invoice and export workflows Customer, employee, designer, and salesman records #### Screen captions Digitizing Depot homepage — service families and quick order Digitizing Depot catalogue — T-shirt styles and product options Digitizing Depot pricing — service rates and inclusions Live product: https://digitizingdepot.com Cover image: https://mustafakhan.dev/images/case-studies/depot-live-home.webp #### Screens - [Digitizing Depot homepage — service families and quick order](https://mustafakhan.dev/images/case-studies/depot-live-home.webp) - [Digitizing Depot catalogue — T-shirt styles and product options](https://mustafakhan.dev/images/case-studies/depot-live-catalogue.webp) - [Digitizing Depot pricing — service rates and inclusions](https://mustafakhan.dev/images/case-studies/depot-live-pricing.webp) --- ### Spider Digitizing Canonical source: https://mustafakhan.dev/work/spider-digitizing #### Summary A framework-free PHP production platform linking public rates and quote tickets to customer accounts, staff permissions, and delivery workflows. #### Overview Spider Digitizing brings a production-floor website and a working service application together. The public ledger and ticket explain the offer before asking for artwork. Customer accounts then carry quotes, offers, conversations, orders, revisions, and invoices; staff tools carry the job into pricing and production. My work includes the site’s visual direction and the PHP application behind it, with an explicit permission model that gives support, production, finance, and content staff their own working responsibilities. #### Category Service commerce / Production platform #### Client Spider Digitizing #### Year 2026 #### Role Creative direction + PHP full-stack engineering #### Technology stack PHP 8.2+ MySQL / PDO Custom PHP router PSR-4 application structure HTML / CSS / JavaScript PHPMailer 7 PHPUnit 10 #### Problem statement Explain a technical service clearly, then keep artwork requests, pricing, production assignments, customer communication, and billing connected after the quote. #### Situation The public site presents digitizing, vector work, and patches with rate, turnaround, format, and production context. Guest quote entry lets a new customer begin directly from the public ticket. The deeper product supports customers returning to offers, message threads, orders, revisions, and invoices, plus staff who need to price and deliver those jobs. #### Tension A short public ticket must collect enough detail for a production decision. Once work is accepted, support, production, finance, and content tasks need different actions on the same application. The customer needs a continuous account of the job, while each staff role needs the queue, record, and controls relevant to its part of the handoff. #### Key decision Use the public ledger and quote ticket as the entry layer, then carry requests into customer and staff workflows. Structure the PHP application into routed surfaces and domain code, with explicit permissions for quoting, orders, commercial records, publishing, settings, and staff management. #### Responsibilities My implementation covers the production-led art direction, responsive public pages, guest quote and cart/bundle entry, customer account workflows, and staff operations. That includes quote offers and conversion to orders, assignments, deliverables and revisions, message threads, invoice access, billing exports, and outgoing mail handling. I also built the application’s content and administration paths so maintaining public information is a named responsibility alongside support, production, and finance. #### Architecture The application is framework-free PHP 8.2+ with a custom router, PSR-4 application structure, and MySQL accessed through PDO. Separate admin, customer, and shop route files organise the main surfaces. Domain repositories handle the data behind quotes, orders, accounts, and permissions. Composer supplies PHPMailer 7 for mail and PHPUnit 10 for tests. Staff queues and customer views meet on persistent job records; billing/export and mail-outbox paths support the follow-up around those jobs. Routing, domain data access, and browser-facing pages give each part of the service journey a defined place in the application. #### Access control RbacRepository resolves permissions through user_roles, role_permissions, and permissions. The super_admin role has all permissions, including staff management. The administrator covers operational administration and settings; refund permissions belong to finance and super_admin. A support_agent views and assigns quotes, changes quote status, and views customers. A production_manager converts quotes and manages order assignments, status, and deliverables. Digitizer and designer roles can view orders and upload deliverables; finance can also view payments and orders. The content_editor has both content.edit and content.publish, which remain distinct permissions. Separate permissions cover audit access. Customer and guest journeys have their own routes alongside the staff permission model. #### System A guest supplies a production request; staff review and price it as an offer. Customer account views keep the quote and conversation accessible, while approved work moves into an order and assignment. Production attaches deliverables and handles revision work. Invoices, billing views, exports, and queued mail support the commercial follow-up. The public rate story and operational record are two parts of the same service journey. #### Evidence The public ledger presents rates, turnaround, and file-format context beside the quote ticket. Customer routes carry quotes, offers, messages, orders, revisions, and invoices; staff queues provide assignment and quote-conversion actions. The role/permission seed maps those staff responsibilities to named permissions. Billing exports and the mail outbox support the commercial records and communications that accompany production. #### Next iteration Review the information carried from a guest ticket into an offer, production assignment, revision, and invoice. Compare support, production, finance, and content tasks against their permission sets, and simplify duplicated explanations while preserving the context that the next person needs. #### Features Public rates and production-led service pages Guest quote and cart/bundle flows Customer quotes, offers, and message threads Quote-to-order conversion Staff production queues and assignments Deliverables and revisions Invoices, billing, and exports Mail outbox Database-backed roles and permissions Separate content-edit and publish permissions #### Screen captions Spider Digitizing homepage — production promise and first action Spider Digitizing detail — thread and machine-room evidence Spider Digitizing process — the production floor Spider Digitizing service proof — patch detail Spider Digitizing pricing — rates, formats, and turnaround Spider Digitizing quote — the three-step production ticket Live product: https://spiderdigitizing.com Cover image: https://mustafakhan.dev/images/case-studies/spider-live-home.webp #### Screens - [Spider Digitizing homepage — production promise and first action](https://mustafakhan.dev/images/case-studies/spider-live-home.webp) - [Spider Digitizing detail — thread and machine-room evidence](https://mustafakhan.dev/images/case-studies/spider-thread.jpg) - [Spider Digitizing process — the production floor](https://mustafakhan.dev/images/case-studies/spider-machine.jpg) - [Spider Digitizing service proof — patch detail](https://mustafakhan.dev/images/case-studies/spider-patch.jpg) - [Spider Digitizing pricing — rates, formats, and turnaround](https://mustafakhan.dev/images/case-studies/spider-live-pricing.webp) - [Spider Digitizing quote — the three-step production ticket](https://mustafakhan.dev/images/case-studies/spider-live-quote.webp) --- ### Affinity Hospitality UAE Canonical source: https://mustafakhan.dev/work/affinity-hospitality #### Summary A specification-led hospitality and bags website helping B2B buyers turn manufacturing capability into a useful enquiry. #### Overview Affinity Hospitality UAE brings bed linen, bath linen, hospitality-use bags, promotional bags, facilities, and resources into a specification-led catalogue. My website work centres on the structure and presentation that let a hotel or campaign buyer understand the offer and explain a requirement. Product photography, material details, manufacturing context, and enquiry prompts work together to support that buying conversation. Each collection gives a buyer a focused route through a broad manufacturing offer. #### Category B2B manufacturing / Hospitality #### Client Affinity Hospitality UAE #### Year 2026 #### Role Digital direction + website build #### Technology stack HTML CSS JavaScript Tailwind CSS #### Problem statement Help a B2B buyer move from a broad linen or bags capability to a requirement that includes the material, size, branding, and delivery context needed for a quote. #### Situation The audience includes hotel buyers evaluating bed and bath programmes and campaign buyers looking for branded bags. Both need evidence of capability, but their questions differ. Thread count, GSM, dimensions, materials, branding choices, and supply context matter before a contact form is useful. Facilities and brochure resources add another layer of information for someone comparing suppliers. #### Tension A procurement-oriented site needs concrete specifications in a format that can be scanned. Product photography introduces the offer, while material and production details help a buyer define a requirement. The same navigation must support both a repeat hospitality programme and a one-off promotional brief, with the relevant specifications close to each collection’s enquiry route. #### Key decision Organise the public experience by collection and capability: Bed Linen, Bath Linen, Custom Bags, Facilities, Resources, and Contact. Keep the specification cues and enquiry invitation beside the relevant product family so a buyer can carry the material, size, branding, and use context into the conversation. #### Responsibilities My website responsibility covers information architecture, visual direction, collection presentation, responsive page structure, and enquiry entry points. I organised the distinction between bed, bath, and bags, placed product photography alongside specification language, and gave facilities and downloadable resources their own role in the buying journey. The content structure supports a practical brief: what the buyer needs, the intended use, relevant material or size details, branding, and delivery expectations. #### Architecture The collection-led website is organised into Bed Linen, Bath Linen, Custom Bags, Facilities, Resources, and Contact. Product and capability sections sit alongside brochure resources and quote prompts. Bed and bath sections carry linen-specific cues such as thread count, GSM, and dimensions; bag sections carry material and branding context. The structure lets buyers move from a product family into specifications, supporting resources, and an enquiry with the relevant requirement in view. #### System A hotel buyer begins with bed or bath requirements, reviews specification cues and production context, and uses the enquiry route to describe the programme. A promotional buyer can enter through bags and focus on material, use, and branding. Facilities and resources provide further context for evaluating the offer. The enquiry prompt is the handoff from catalogue browsing to the commercial conversation, carrying the buyer’s product and specification context forward. #### Evidence Bed, bath, and bag sections publish specification details around GSM, thread count, materials, sizes, and branding. Facilities pages and brochure resources give buyers additional manufacturing and product context. Contact and quote prompts ask for the requirement and delivery details that shape the enquiry. These collection, resource, and contact destinations make the catalogue’s buying paths visible from the main navigation. #### Next iteration Observe a hotel buyer and a campaign buyer assembling a brief from the same site. Look for missing specification context, unclear collection labels, or resource downloads that interrupt the path to enquiry. The next content pass should help each buyer explain a requirement more completely, with the offer’s actual capabilities kept visible. #### Features Bed linen capability and specifications Bath and pool linen collection Hospitality and promotional bags Material, size, and branding context Facilities and production information Brochure resources Specification-led enquiry prompts #### Screen captions Affinity Hospitality UAE homepage — linen and custom bags Affinity Hospitality UAE linen — bath linen specifications Affinity Hospitality UAE bags — hospitality and promotional formats Live product: https://affinityhospitality.ae Cover image: https://mustafakhan.dev/images/case-studies/affinity-live-home.webp #### Screens - [Affinity Hospitality UAE homepage — linen and custom bags](https://mustafakhan.dev/images/case-studies/affinity-live-home.webp) - [Affinity Hospitality UAE linen — bath linen specifications](https://mustafakhan.dev/images/case-studies/affinity-live-linen.webp) - [Affinity Hospitality UAE bags — hospitality and promotional formats](https://mustafakhan.dev/images/case-studies/affinity-live-bags.webp) --- ### TY Dress Collection Canonical source: https://mustafakhan.dev/work/ty-dress-collection #### Summary A PHP/MySQL couture shop linking collection-led browsing to variants, cart snapshots, customer accounts, and order operations. #### Overview TY Dress Collection combines a fashion-house presentation with a custom commerce application. Pret, evening, bridal, jewels, and everyday pieces have distinct collection entry points, while the implementation carries visitors through products, variants, wishlist, cart, checkout, and tracking. My work spans that editorial storefront and its PHP/MySQL commerce layer, connecting product presentation, purchase details, customer accounts, and administration throughout the shopping journey. #### Category Fashion ecommerce #### Client TY Dress Collection #### Year 2026 #### Role Commerce design + PHP full-stack engineering #### Technology stack PHP MySQL / PDO HTML / CSS Vanilla JavaScript Whop integration #### Problem statement Preserve the identity of each fashion collection while keeping product choices, availability, checkout, and post-order operations understandable. #### Situation The storefront names collection worlds such as Pret Luxe, Evening Edit, Bridal Atelier, Heritage Jewels, Luxury Pret, and Modern Essentials. Customers also need concrete product information, a selected variant, a wishlist or bag, and a way to follow an order. Staff need to maintain the catalogue and handle the orders generated by that public journey. #### Tension Editorial photography and pacing create a collection identity, while shoppers need price, availability, variant choices, and a clear next action. Behind the page, a cart item must become an order line with its own recorded details. Payment lifecycle, stock, coupons, and refunds add states that need to stay connected to both the customer’s journey and the administrative order view. #### Key decision Keep collection-first navigation as the editorial layer and make shopping tools a continuous second layer. Implement the commerce flow in the existing PHP/PDO application, with explicit order and payment lifecycle handling. Order-line snapshots retain the product and variant details at purchase, giving the customer and staff a lasting record of the selected items. #### Responsibilities My scope includes collection and product presentation, responsive frontend behaviour, variant selection, wishlist and cart paths, guest and customer journeys, checkout integration, and order tracking. The implementation also covers administrative product, order, customer, coupon, message, and settings screens. On the commerce side, the work connects line-item snapshots, stock and coupon handling, and the Whop lifecycle and refund paths to the shop’s order records. #### Architecture The site is framework-free PHP with MySQL accessed through PDO; HTML, CSS, and vanilla JavaScript supply the browser experience. Shared include modules handle authentication and the commerce logic. includes/orders.php records cart-line snapshots and contains the order lifecycle, stock, coupon, and refund handling around the Whop integration. Payment webhooks provide a separate input to that lifecycle alongside checkout requests. Collection and product pages feed the cart, order records retain purchase details, and customer tracking and administration present the continuing order state. #### Access control includes/auth.php provides session-backed authentication, password hashing/verification, and current-user roles of customer or admin. admin/auth.php gates the administrative surface. Administrators have product, order, customer, coupon, message, and settings tools; the mobile admin surface is view-only. Customer accounts and guest shopping provide distinct routes through the storefront, with the customer/admin role model defining access to account and administrative work. #### System A shopper enters through a collection, opens a product, selects a variant, and saves it to a wishlist or cart. Guest and account paths lead into an order whose lines retain their purchase details. Checkout and webhook handling feed the order lifecycle; tracking supports the return visit. Administration maintains catalogue data and supports the commercial follow-up through order, customer, coupon, and message views. #### Evidence Collection pages and product variants lead into wishlist and cart controls, with customer accounts and tracking supporting the return visit. PHP/PDO modules connect those screens to order-line snapshots, customer/admin authentication, and the Whop integration’s webhook handling. Administrative views bring products, orders, customers, coupons, messages, and settings into the same commerce operation. #### Next iteration Trace a selected variant from collection browsing into cart, checkout, tracking, and the admin order view. Review sizing and delivery questions at the product stage, and separately exercise retry and webhook states against controlled test orders to understand the integration’s operational edge cases. #### Features Collection-first couture storefront Product and variant selection Wishlist and shopping cart Guest and customer account paths Order-line snapshots Whop integration and webhook handling Stock, coupon, and refund handling Order tracking Customer/admin roles View-only mobile administration #### Screen captions TY Dress Collection homepage — collection-led couture commerce TY Dress Collection — editorial hero and atelier story TY Dress Collection — bridal collection view TY Dress Collection — pret collection view TY Dress Collection bridal — the Bridal Atelier collection TY Dress Collection product — silk pret options and shopping controls Live product: https://tydresses.com Cover image: https://mustafakhan.dev/images/case-studies/ty-live-home.webp #### Screens - [TY Dress Collection homepage — collection-led couture commerce](https://mustafakhan.dev/images/case-studies/ty-live-home.webp) - [TY Dress Collection — editorial hero and atelier story](https://mustafakhan.dev/images/case-studies/ty-hero.jfif) - [TY Dress Collection — bridal collection view](https://mustafakhan.dev/images/case-studies/ty-bridal.jfif) - [TY Dress Collection — pret collection view](https://mustafakhan.dev/images/case-studies/ty-pret.jfif) - [TY Dress Collection bridal — the Bridal Atelier collection](https://mustafakhan.dev/images/case-studies/ty-live-bridal.webp) - [TY Dress Collection product — silk pret options and shopping controls](https://mustafakhan.dev/images/case-studies/ty-live-product.webp) --- ### Relay Canonical source: https://mustafakhan.dev/work/relay #### Summary An open-source terminal chat application with rooms, direct messages, presence, and optional client-side encrypted rooms. #### Overview Relay brings a live conversation into the terminal. I built the JavaScript application around a Node.js WebSocket server and a React/Ink terminal interface, with multi-room chat, direct messages, presence, and scrollback. Capped, in-memory server state keeps recent room activity available during the running session, while optional encrypted rooms put key derivation and message encryption in the client. #### Category Open source / Terminal tools #### Role Application design + implementation #### Technology stack JavaScript Node.js 22 React / Ink 8 WebSocket / ws Node.js crypto #### Problem statement Keep a live, multi-room conversation usable inside a text-first terminal interface with lightweight session-based server state. #### Situation The application needs to show conversation, room context, and other participants within a text-first interface. #### Key decision Use React/Ink for the terminal UI, WebSockets for live communication, and capped in-memory server state for the chat session. #### Responsibilities I implemented the terminal interaction, server messaging, room and direct-message flows, presence, scrollback, and the optional encrypted-room client path. #### Architecture A Node.js 22 server communicates over ws with a JavaScript React/Ink client. Optional encrypted rooms derive a key client-side with scrypt and encrypt messages using AES-256-GCM. The persistence model is capped, in-memory server state, holding recent chat activity for the running session. #### System Participants move between rooms, follow presence, exchange room or direct messages, and inspect recent scrollback. For optional encrypted rooms, the client handles key derivation and message encryption before sending messages over the WebSocket connection. #### Evidence The React/Ink interface presents room conversations, direct messages, presence, and scrollback in the terminal. The WebSocket server manages live messaging and capped in-memory state, while the client crypto module implements scrypt key derivation and AES-256-GCM for optional encrypted rooms. #### Features Terminal chat interface Multiple rooms Direct messages Presence and scrollback Optional client-side encrypted rooms Capped in-memory server state #### Screen captions Relay — multi-room terminal chat Public source code: https://github.com/Mustafa-KhanDev/relay Cover image: https://mustafakhan.dev/images/case-studies/relay-demo.webp #### Screens - [Relay — multi-room terminal chat](https://mustafakhan.dev/images/case-studies/relay-demo.webp) --- ### Gitscape Canonical source: https://mustafakhan.dev/work/gitscape #### Summary A local Git activity tool with a terminal interface and a self-contained offline HTML dashboard. #### Overview Gitscape turns local repository history into a visual activity landscape. I built a JavaScript/Node.js collector and React/Ink terminal experience, plus an HTML dashboard generator with terrain, skyline, rhythm, and repository views. Collection reads local Git history; the generator produces a self-contained, dependency-free dashboard that opens offline. #### Category Open source / Developer tools #### Role Tool design + implementation #### Technology stack JavaScript Node.js 22 React / Ink Babel Git CLI Self-contained HTML #### Problem statement Make local coding activity inspectable across repositories in both a terminal and an offline visual dashboard. #### Key decision Collect local git log --all data across repository refs and generate a self-contained HTML dashboard. Keep history collection, activity aggregation, and visual output in a local workflow that can be opened offline. #### Responsibilities I implemented Git history collection, timestamp and repository-day aggregation, the terminal interface, and the terrain, skyline, rhythm, and repository-chart dashboard output. #### Architecture The Node.js collector reads local Git logs across refs and buckets activity using author timestamps and repository days. React/Ink supplies the terminal interface. The HTML generator packages its visual views into a self-contained offline output with zero dashboard runtime dependencies. #### System Local repository history becomes activity buckets that can be explored in the terminal or exported into the HTML dashboard. Terrain, skyline, rhythm, and repository views offer different ways to read that history, moving between the overall activity pattern and its distribution across repositories and days. #### Evidence The collector reads local Git logs and groups activity by author timestamps and repository days. The HTML generator packages terrain, skyline, rhythm, and repository charts into one offline artifact, while the React/Ink interface makes the same local-history workflow available in the terminal. #### Features Local Git history collection Author-timestamp activity buckets React/Ink terminal interface Terrain and skyline visualisations Rhythm and repository views Self-contained offline HTML dashboard #### Screen captions Gitscape — offline Git activity dashboard Public source code: https://github.com/Mustafa-KhanDev/gitscape Cover image: https://mustafakhan.dev/images/case-studies/gitscape-dashboard.webp #### Screens - [Gitscape — offline Git activity dashboard](https://mustafakhan.dev/images/case-studies/gitscape-dashboard.webp) --- ### Hamwas Canonical source: https://mustafakhan.dev/work/hamwas #### Summary An agency website connecting services, selected work, process, and custom-order enquiries. #### Overview I designed and built the Hamwas website around the way a prospective client explores an agency. Services introduce the offer, selected work provides context, and process and about pages explain the approach behind it. Contact and custom-order paths give visitors a clear way to bring their own brief into the conversation. The result is a complete agency website with a connected route from learning about the work to starting an enquiry. #### Category Agency website #### Client Hamwas #### Role Full website design + build #### Technology stack HTML CSS JavaScript #### Problem statement Help prospective clients understand the agency’s offer, inspect its work, and choose a contact or custom-order route. #### Responsibilities I designed and implemented the full website experience, including its service presentation, selected-work pages, process and about content, navigation, and contact and custom-order entry points. #### System Visitors can begin with services or selected work, read about the agency and its process, then continue to contact or custom order with a clearer sense of the offer. The page structure brings those stages into one agency experience. #### Evidence Dedicated services, work, process, and about destinations present the agency’s offer and approach. Contact and custom-order pages turn that context into a practical next step for a prospective client. #### Features Agency service pages Selected work Process and about content Contact path Custom-order enquiry #### Screen captions Team Hamwas — agency services and project enquiry entry points Live product: https://hamwas.com Cover image: https://mustafakhan.dev/images/case-studies/hamwas-live-home.webp #### Screens - [Team Hamwas — agency services and project enquiry entry points](https://mustafakhan.dev/images/case-studies/hamwas-live-home.webp) --- ### Star Tourism Canonical source: https://mustafakhan.dev/work/star-tourism #### Summary A WordPress travel-services website presenting packages and practical details before a WhatsApp enquiry. #### Overview I built the Star Tourism website to bring travel services and package information into one WordPress experience. The site covers tickets, insurance, transport, Umrah, visa services, and travel packages. Package cards present prices and inclusions together, giving visitors practical details to compare before continuing through WhatsApp. The service and package structure helps a traveller find a starting point and discuss the trip with the business. #### Category WordPress / Travel services #### Client Star Tourism #### Role Full website design + build #### Technology stack WordPress PHP Elementor HTML / CSS JavaScript #### Problem statement Let travellers compare services and package details before asking the business about a trip. #### Responsibilities I built the full website and organised the public service and package presentation around a clear enquiry path. #### Architecture WordPress provides the website’s service and package content structure. Travel-service sections organise the offer, while package cards bring pricing and inclusions into the browsing experience. WhatsApp enquiry actions connect those details to the conversation about a traveller’s requirement. #### System Visitors choose a service or package, review the advertised price and inclusions, and continue through WhatsApp to discuss the requirement. #### Evidence Travel-service categories cover tickets, insurance, transport, Umrah, and visa information. Package cards place pricing and inclusions beside WhatsApp enquiry actions, giving visitors a concrete route from comparing an offer to asking about their trip. #### Features Tickets, insurance, and transport services Umrah and visa information Travel package cards Package pricing and inclusions WhatsApp enquiry handoff #### Screen captions Star Tourism — travel services, quote access, and WhatsApp contact Live product: https://startourism.com.pk Cover image: https://mustafakhan.dev/images/case-studies/star-tourism-live-home.webp #### Screens - [Star Tourism — travel services, quote access, and WhatsApp contact](https://mustafakhan.dev/images/case-studies/star-tourism-live-home.webp) --- ### Global Beauty Verse Canonical source: https://mustafakhan.dev/work/globalbeautyverse #### Summary A beauty-industry event and training website connecting women’s skill development, event archives, community, and enquiries. #### Overview I designed and built the Global Beauty Verse website end to end. The public experience introduces a beauty-industry platform centred on inclusivity, women’s skills, workshops, demonstrations, master classes, and professional networking. It brings the organisation’s mission, founder profile, past training sessions, event stories, gallery, and contact routes into one branded website. The challenge was to make the purpose immediately clear while giving prospective participants a way to explore the people and events behind it. Mission-led copy and imagery establish the first impression; event archives, a founder introduction, and a promotional video provide a more concrete picture of the community. #### Category Brand / Events and training #### Client Global Beauty Verse #### Role Full website design + engineering #### Technology stack HTML CSS JavaScript Bootstrap jQuery 3.6 #### Problem statement Give a beauty-industry training and events platform a clear public identity, with credible community context and accessible paths into its activities. #### Situation The organisation brings beauty professionals and learners together through workshops, demonstrations, master classes, and events. The website has to explain that purpose to a newcomer while making its past activities, founder, media, and contact information easy to explore. #### Tension A mission-led introduction creates a strong first impression, but visitors also need practical evidence of what the organisation does. Event material spans different years, so the archive needs a recognisable structure alongside the main brand story. #### Key decision Build the journey around the mission, then move into the people and activities behind it. Keep About, Events, Gallery, Blogs, and Contact as distinct destinations, with past training sessions and event stories linking into their own context. #### Responsibilities My scope covers the complete website design and implementation: responsive layouts, the homepage narrative and carousel, organisation and founder presentation, event and gallery entry points, archive navigation, media placement, and newsletter/contact entry points. The visual hierarchy connects the platform’s purpose to the next section a visitor can explore. #### Architecture The browser layer uses HTML, CSS, JavaScript, Bootstrap, and jQuery 3.6. Shared navigation connects the public page families. The homepage combines a hero carousel, about section, training-session archive, founder profile, event video, blog highlights, and newsletter entry. Year-specific event stories give historical content a durable destination, while the promotional video has its own explicit viewing link. #### System A first-time visitor reads the purpose, learns about the platform, and inspects a past training session or event. The founder and media sections add human context. About, Events, Gallery, and Blogs support deeper exploration, while Contact and newsletter entry provide ways to continue the relationship. #### Evidence The live website exposes the mission-led carousel, workshop and training introduction, past session links, Shaziya Khan’s founder profile, event-blog archives, a Vimeo promotional video, and the newsletter/contact entry points. The pages give the brand story and its activity archive a common navigation structure. #### Next iteration Make upcoming and historical activity even easier to distinguish, and review the route from a particular training format to an enquiry. Maintain useful event titles and archive labels as the organisation adds new material. #### Features Mission-led homepage and carousel Workshops and professional training introduction Year-specific training and event archives Founder profile Gallery and blog navigation Event promotional video Newsletter and contact entry points Responsive Bootstrap and jQuery interface #### Screen captions Global Beauty Verse — beauty-industry training and event homepage Live product: https://globalbeautyverse.com Cover image: https://mustafakhan.dev/images/case-studies/globalbeautyverse-live-home.webp #### Screens - [Global Beauty Verse — beauty-industry training and event homepage](https://mustafakhan.dev/images/case-studies/globalbeautyverse-live-home.webp) ## Services ### Product systems Canonical source: https://mustafakhan.dev/services #### Summary The product layer behind auction rooms, quote tickets, account areas, and operational handoffs. #### Overview I map the route from a visitor’s first question to the action the business needs next, then build the interface and data flow around it. That can mean a live room for Auctibuy, a quote path for Spider, or account and order states for an apparel business. #### Deliverables Product architecture React / Node builds API and data design Admin operations #### Starting price Let’s scope it --- ### Commerce experiences Canonical source: https://mustafakhan.dev/services #### Summary Catalogues for tees, patches, linen, bags, and couture — each with a different reason to buy. #### Overview I shape the catalogue, collection, product detail, cart, checkout, and quote moments around the way a real business sells. Liberty and Digitizing Depot need breadth; Affinity needs specification; TY Dress Collection needs an editorial route into shopping. #### Deliverables Catalog architecture Product and collection UI Cart / checkout flows Quote and account systems #### Starting price Built around scope --- ### Interface direction Canonical source: https://mustafakhan.dev/services #### Summary A visual language that gives a live room, production floor, manufacturer, or fashion house its own temperature. #### Overview The visual system follows the product. Spider uses a production-floor voice and public rates; TY Dress Collection uses collection-led editorial pacing; Affinity lets specifications and photography do the trust work. Components and motion support those differences instead of flattening them. #### Deliverables Art direction UI systems Responsive prototypes Motion language #### Starting price Start with a direction --- ### Launch systems Canonical source: https://mustafakhan.dev/services #### Summary The final pass on content, image paths, search metadata, responsive behavior, and the link to the real product. #### Overview A case study is only useful when the live link, copy, images, and page structure agree. I use the launch pass to check those seams: what the visitor can actually click, what the CMS can maintain, and what still needs a human decision. #### Deliverables Performance pass Technical SEO CMS content setup Launch support #### Starting price Audit or full launch ## Skills ### Laravel Canonical source: https://mustafakhan.dev/about --- ### PHP Canonical source: https://mustafakhan.dev/about --- ### MySQL Canonical source: https://mustafakhan.dev/about --- ### NodeJS Canonical source: https://mustafakhan.dev/about --- ### MongoDB Canonical source: https://mustafakhan.dev/about --- ### React Canonical source: https://mustafakhan.dev/about --- ### WordPress Canonical source: https://mustafakhan.dev/about --- ### HTML Canonical source: https://mustafakhan.dev/about --- ### CSS Canonical source: https://mustafakhan.dev/about --- ### JavaScript Canonical source: https://mustafakhan.dev/about ## Experiences ### Product engineering across live brands Canonical source: https://mustafakhan.dev/about #### Summary Six live products across auctions, apparel, embroidery, hospitality supply, and couture commerce. #### Overview The work moves between a real-time auction marketplace, service-heavy apparel catalogues, a production-led embroidery site, a B2B linen and bags manufacturer, and a collection-led fashion shop. Each product changes the vocabulary, hierarchy, and proof a page needs. #### Organization Independent product work #### Period 2023 — now --- ### MERN and full-stack application builds Canonical source: https://mustafakhan.dev/about #### Summary React, Node.js, MongoDB, Laravel, and the decisions that connect a screen to a working workflow. #### Overview The implementation work sits close to the product decisions: catalogue models, quote forms, account states, content structure, responsive pages, and the links that let a visitor continue the task they started. #### Organization Full-stack practice #### Period 2021 — now ## Posts ### One auction room needs one answer Canonical source: https://mustafakhan.dev/journal/one-auction-room-needs-one-answer #### Summary A bid screen has one job: show people the same current truth. Here is how I think about that problem in Auctibuy. #### Overview A live auction can look like a small screen: an item, a price, a clock, and a button. The difficult part is making sure every person sees the same answer. The room has more than one visitor Auctibuy has a feed and an Explore area for buyers. It also has a creator studio, account tools, moderation screens, and operations around settlement. Those people do not need the same controls, but they still depend on the same auction state. A buyer might open a room from an item page. A seller might be watching the listing from a different screen. An administrator may be checking the same auction from an operations view. If those screens disagree about the current bid, trust disappears quickly. The database gets the final say The browser can show a quick update, but it should not decide whether a bid is valid. Auctibuy keeps the auction record in MongoDB as the source of truth. The API checks the current room before it accepts a change. That protects the important action even when two people click at nearly the same time. Redis helps carry hot room state and events. WebSockets deliver updates while the connection is healthy. Polling remains available when the live connection drops. The fallback is less exciting, but it is useful: a person should still be able to understand the room when the best connection is unavailable. The interface should explain the state Real-time work is not only a transport problem. The screen needs to answer simple questions: What is the current price? Can I bid right now? Did the server accept my action? What changed while I was looking away? The next useful improvement is to test those questions on a slow connection and during a connection change. The goal is not to make the room feel busy. The goal is to make the important state hard to misunderstand. #### Category Product engineering --- ### A quote form is part of the product Canonical source: https://mustafakhan.dev/journal/a-quote-form-is-part-of-the-product #### Summary A useful quote form helps a customer explain the job and helps the team know what to do next. #### Overview A quote form is often treated like the last page of a website. That is too late. For a service business, the form is part of the product: it is where a visitor turns a question into work someone can actually price. A short form can still collect the right detail On Spider Digitizing, the public site explains rates, turnaround, accepted formats, and the production process before asking for artwork. The customer can start with a guest ticket, then return to quotes, messages, orders, revisions, and invoices through an account. That order matters. A person should not have to upload a file before they know what the service does. They also should not have to write a long paragraph when a few clear fields would explain the job better. The next person needs the same context The form is only the first handoff. At Liberty Digitizing, a request can move from a public apparel or service path into pricing, assignment, file delivery, invoicing, and reporting. The customer sees a request. Staff see a queue and the next action. Good form design keeps those two views connected. It asks for information that helps the team act, but it does not make the customer do the team’s job. The labels should say what is needed, the upload step should explain accepted files, and the confirmation should make the next step visible. The small test I use After building a quote path, I follow one request as if I were a new customer. Then I follow the same request as the person who has to price or produce it. If the customer has to repeat the story, or the staff member has to guess what the customer meant, the form is not finished. The best quote form is not the one with the fewest fields. It is the one that carries the right information from the first question to the next useful decision. #### Category Service commerce --- ### A catalogue should help someone choose Canonical source: https://mustafakhan.dev/journal/a-catalogue-should-help-someone-choose #### Summary More products do not automatically make a better shop. The first screen should help a person find a sensible place to start. #### Overview A large catalogue can make a site feel like a warehouse. Every category, product, price, and button is useful on its own, but the whole page can still leave a new visitor asking, “Where do I begin?” Start with the reason people came Liberty Digitizing serves more than one kind of customer. Someone may be choosing apparel, ordering patches, or asking for embroidery and vector work. Those are different jobs, so they should have different starting points instead of one large list. Digitizing Depot has a similar problem. Its offer includes products, digitizing, vector work, and other services. A service family, a useful example, and a clear next action help a visitor narrow the question before they reach the form. Keep the story and the action together For TY Dress Collection, the collection is part of the reason someone wants to look. The page can create a fashion mood, but it still needs to show the piece, price, variant, availability, bag, and checkout path. Editorial presentation and commerce do not need to fight each other; they need to hand the visitor from one to the next. For a B2B buyer at Affinity Hospitality UAE, the useful detail is different again. Material, size, branding, and delivery context may matter more than a broad slogan. The right catalogue helps the buyer assemble a brief that can become a real enquiry. A simple catalogue check Pick a product or service you have never seen before. Can you tell what the business offers, which part is for you, and what to do next without opening every page? If not, the catalogue needs a better order, not more decoration. The job of a catalogue is to reduce the first decision. Once someone has a sensible starting point, the deeper details can do their work. #### Category Interface design