Senior Software Engineer — Commerce Platforms, AI Systems & Automation Architecture

Public proof updated: 2026-07-23

Start with the flagship repositories, then use the active public showcase library and pinning guide for the full employer-review path.

I work on production commerce systems where the important work spans backend PHP, WordPress/WooCommerce, frontend UX, APIs, data workflows, CRM operations, automation, reporting, and technical SEO.

My strongest work is turning business operations into reliable web systems: fast storefronts, controlled internal tools, snapshot APIs, CRM workflows, reporting pipelines, automation boundaries, and public-safe architecture documentation.

Portfolio: https://amiraliyaghouti.com
LinkedIn: https://www.linkedin.com/in/amirali-yaghouti
Email: amiraliyaghouti@gmail.com

For a fast hiring review, use the website for the broader career story and this GitHub profile for technical proof:

• Website overview: https://amiraliyaghouti.com
• Project index: https://amiraliyaghouti.com/projects.html
• Case-study library: https://amiraliyaghouti.com/case-studies.html
• Full public showcase index: docs/public-showcase-index.md
• Recommended profile pins: docs/github-profile-pinning.md
• GitHub samples: start with the flagship repositories below, then use the active showcase library for focused plugin/API/UI samples.

The public repositories are curated showcases. They include architecture notes, public-safe samples, and sample-only syntax checks. They do not expose private implementation code or production data.

Latest public update: the July 2026 releases publish the AI and automation line of work — woocommerce-ai-sales-assistant (AI sales consultant for WooCommerce over Telegram and website chat, grounded in the live catalog via OpenAI function-calling, with vision and voice), ai-token-platform (Telegram AI assistant platform with an internal credit economy), telegram-crm-campaign-manager (rate-limited scheduled customer messaging with a live dashboard), and woocommerce-telegram-order-bot (live, self-updating order cards with Jalali-dated reports), alongside an updated a2-crm-operations-system.

• Public technical writing index
• WooCommerce request classification before cache
• Action Scheduler backlog as operational risk
• Public-safe engineering proof

• AI sales consultant for WooCommerce — Telegram + website chat, grounded in the live catalog via OpenAI function-calling (vision + voice): woocommerce-ai-sales-assistant
• Telegram AI assistant platform with an internal credit economy — aiogram bot + Telegram Mini App + FastAPI admin dashboard: ai-token-platform
• Rate-limited scheduled customer messaging over Telegram, with a live dashboard: telegram-crm-campaign-manager
• Modular-monolith commerce platform engineering, selected samples, and ADRs: a2-commerce-platform-showcase — the earlier architecture planning, data modeling, and migration strategy work lives in commerce-platform-modernization-showcase
• WooCommerce performance, cache boundaries, REST pressure, and scheduler risk: a2-woocommerce-performance-lab
• CRM, operator workflows, provider boundaries, and reporting snapshots: a2-crm-operations-system
• Automation workflows, n8n-style routing, reporting pipelines, and approval gates: commerce-automation-workflows-showcase
• Retail operations PWA architecture and assisted ordering workflows: jeweltimeco-showcase
• Marketplace state design, custody boundaries, and review workflows: a2-watch-marketplace-showcase

These repositories are focused public-safe showcases for active private work. Each one includes a privacy boundary, update notes, architecture notes, and sanitized samples.

• AI-assisted SEO workflow: a2-seo-plugin-showcase
• Catalog/search API boundary: a2-catalog-api-showcase
• Bulk discount operations: a2-discount-showcase
• Spreadsheet price/stock sync: a2-excel-price-sync-showcase
• Snapshot product API: a2-searchwiz-product-api-showcase
• Messaging/customer hub: a2-bale-customer-hub-showcase
• Storefront carousel component: a2-lux-showcase
• Checkout/cart UI compatibility: a2-woo-flow-ui-showcase
• MU-plugin operations umbrella: mu-plugins-showcase — updated for asset cleanup, SEO/schema safety, archive pagination stability, microcache operations, and checkout/payment safeguards.
• Telegram order operations: woocommerce-telegram-order-bot — live, self-updating order cards with featured images, Jalali-dated captions, in-place edits on status/price changes, and per-gateway sales reports.
• Local lead generation: a2-local-lead-engine-public — safety-first lead-gen and outreach engine (OSM, free/keyless, human-reviewed).
• Staging security orchestration: a2-staging-security-showcase — sanitized security engineering showcase for fail-closed staging recovery orchestration.
• Customer identity architecture: a2-customer-identity-core-showcase — public showcase of a security-first customer identity architecture.
• Trading-signal operations platform: a2-vip-trading-showcase — modular-monolith services sharing one domain layer, server-authoritative billing, and a code-enforced no-withdraw invariant.
• WhatsApp customer response & cart recovery: wa-assistant-showcase — an operator-priority hand-off state machine, rate caps, and conservative, opt-out-respecting pacing.
• Instagram automation & analytics: instagram-automation-showcase — official Graph API first, a reactive-only responder scoped to one account, and read-only isolated insights.

I am not positioning myself as a theme customizer or generic freelancer. The work I want to be reviewed for is full-stack production engineering around commerce and operations platforms:

• diagnosing slow routes, queue pressure, transient growth, and cache misses;
• designing small, controlled plugin/MU-plugin modules instead of risky broad rewrites;
• building admin and operator tools that reduce manual work without weakening data integrity;
• connecting APIs, spreadsheets, CRM events, messaging providers, and reporting workflows safely;
• keeping public code samples curated, anonymized, and safe to inspect.

• Classify request type before applying cache, API controls, or shortcuts.
• Treat cache invalidation as part of the design, not a cleanup task.
• Watch queue backlog and oldest pending age as operational risk signals.
• Control REST/API pressure separately from page-render performance.
• Design admin operations around permission gates, snapshots, audit records, and rollback paths.
• Keep provider integrations fail-visible and replaceable.
• Model marketplace workflows as state machines before payment or public listing logic.

These metrics are used only where they are represented in the public website/resume materials.

• Product detail page TTFB: 2.3s -> 0.9s
• Product archive p95: 5.2s -> 1.7s
• REST route p95: 2.8s -> 0.9s
• Product API p95: 1.9s -> 0.42s
• Similar-products block render: 1.9s -> 0.42s
• Action Scheduler pending queue: about 38k -> about 4.9k
• Transient rows: about 1.3M -> about 180k
• Cart noise: about 4100/day -> about 180/day

https://github.com/shiny-a2/a2-commerce-platform-showcase

Engineering case study for a modular-monolith commerce platform with selected samples and ADRs. The earlier modernization phase — architecture planning, data modeling, migration strategy, RBAC boundaries, and SEO control-plane thinking — is documented in commerce-platform-modernization-showcase.

https://github.com/shiny-a2/a2-woocommerce-performance-lab

Microcache boundaries, REST route control, Action Scheduler cleanup, transient protection, autoload hygiene, and low-overhead diagnostics for WooCommerce stores under real traffic pressure.

https://github.com/shiny-a2/a2-crm-operations-system

WordPress-based CRM architecture for operator inboxes, customer follow-up, customer hubs, SMS/VoIP integration boundaries, reporting, and operational auditability.

https://github.com/shiny-a2/commerce-automation-workflows-showcase

n8n-style workflow architecture for CRM routing, reporting pipelines, messaging review gates, Google Sheets handoffs, and approval-safe operational automation.

https://github.com/shiny-a2/a2-style-dna-similar-products

Recommendation architecture using product signatures, cached candidate scoring, rebuild locks, and render-time protection for WooCommerce product pages.

https://github.com/shiny-a2/a2-woocommerce-admin-ops-toolkit

Admin operation patterns for exceptional order workflows, operational flags, controlled edits, audit notes, and rollback-aware productivity tooling.

https://github.com/shiny-a2/a2-watch-marketplace-showcase

Architecture showcase for seller intake, verification states, custody/delivery flows, operator review, and marketplace workflow boundaries. Production launch is not represented.

• Request classification before cache
• Action Scheduler backlog as operational risk
• Transient growth and autoload pressure

• Operator inbox state boundaries
• Provider abstraction for SMS and VoIP

• Commerce automation architecture notes

• Recommendation without heavy real-time queries

• Safe admin actions and rollback thinking

• Marketplace state machine before payments

• WooCommerce request lifecycle and cache safety
• MU-plugin architecture for small, reversible production changes
• REST/API route pressure reduction and snapshot data patterns
• MySQL option/transient pressure management
• Action Scheduler and WP-Cron maintenance
• Admin UX for operations teams
• CRM/customer operation workflows
• Technical SEO architecture for catalog-heavy sites
• Human-reviewed automation with n8n, Google Sheets, and reporting workflows

• lightweight performance logging that avoids storing customer data;
• scheduled cleanup routines with bounded batches;
• admin-only operations tools with capability checks and audit notes;
• snapshot/rebuild patterns for expensive product data;
• provider abstractions for SMS/VoIP-style integrations;
• rollback and fallback thinking for checkout/admin-sensitive changes.

I build internal systems as operational tools, not as generic dashboards. The recurring concerns are assignment state, customer context, role boundaries, reporting quality, provider failure, auditability, and whether the tool makes daily work safer instead of just prettier.

• hardening WooCommerce performance case studies into public-safe technical references;
• improving public samples so reviewers can see architecture without seeing private business logic;
• keeping production repositories private where direct release would expose clients, operations, or implementation details;
• aligning GitHub, portfolio, and resume around senior production ownership.

• Measure the bottleneck before changing the system.
• Prefer reversible modules over broad rewrites on live commerce platforms.
• Treat cache invalidation, checkout state, and customer data as first-class constraints.
• Keep public code curated and safe; never publish raw production dumps.
• Write documentation that explains tradeoffs, not just features.