Selected systems
Proof of difficult work, without inflated claims.
Each case is presented around the real problem, what changed, what can be inspected and what is known now. Business results are only claimed when they are actually measured.
Selected cases
Loom
Problem. A Persian-language hospitality operation had multiple public menu surfaces, WordPress complexity and a need to make site, menu and operating evidence easier to reason about before larger growth work.
Work. The project established technical and UX baselines, preserved public menu states, documented WordPress behavior and created an evidence registry that separates private, sanitized and public material. Evidence IDs track what was captured, its confidence and whether it is suitable for public case-study use.
Evidence. Public menu routes and a WordPress REST baseline were captured under explicit evidence records. Some commercial and outcome records are still marked as pending capture or require owner input, so Sazvara does not present those as completed results.
Status. The implementation and release process can be demonstrated; measured business outcomes remain a separate measurement phase.
Rahro
Problem. Turn a personalized English-learning service for Persian-speaking learners into an operating system rather than a collection of disconnected forms and manual steps.
Work. Rahro has explicit intake, enrollment, learner-profile and operator surfaces. Its governance evidence includes baseline inventories for copy, fields and calls to action, plus desktop and mobile render evidence for public, intake, enrollment and operator-analytics views.
Evidence. Structured baseline and coverage records make later changes comparable against a known state rather than relying only on screenshots or narrative descriptions.
CMRP
Problem. A real café digital-menu problem needed to become a reusable WordPress product instead of remaining a one-off site customization.
Work. CMRP evolved into an RTL-first menu product with explicit menu rendering, category and pricing structures, administration architecture, publishing behavior and release checkpoints. The system map documents the path from WordPress data to the rendered menu and the validation pipeline used around releases.
Evidence. Release records include modern WordPress runtime validation. A Persian RTL acceptance failure was retained as a failure, investigated and later cleared by targeted retesting rather than being silently rewritten as a pass.
Editorial Notices
Purpose. A deliberately small public WordPress project that makes the engineering approach inspectable without requiring access to private client work.
Work. The public proof surface covers documented behavior, Gutenberg integration, REST API work and automated validation. Its value is not the size of the plugin; it is that implementation choices and source can be examined directly.
Evidence. The repository is the inspectable proof surface, complementing the larger private and venture projects on this page.
How to read the work
Problem → change → working state → evidence.
The useful question is not whether a project looks impressive. It is whether the difficult part became clearer, safer and more workable—and whether that can be shown.
Have something similar?
Start with one difficult piece.
A stalled build, inherited WordPress system, integration or workflow problem is enough to begin.