Selected work / Workflow engineering / LinkedIn / Contact
I take technical responsibility for architecture, task planning, delivery coordination and releases. My project experience includes initiatives with 20–30 participants and, in one case, around 50. I also build projects independently.
I build APIs and business workflows where the rules behind an action matter: who may approve a change, which version was reviewed, what survives a restart, and how conflicting actions are handled. My work combines implementation, architectural explanations and reproducible checks.
Based in Astana, Kazakhstan. Three years of programming experience. Computing at Coventry University Kazakhstan (2025–2029 expected, in progress).
Open to paid, fully remote projects. Total availability: 20–30 hours/week. For a complete web MVP, API or internal tool, we can agree the user journeys, integrations, acceptance criteria and delivery stages before implementation.
| Project | Engineering problem | Implementation and evidence |
|---|---|---|
| BekitChange | Two approved requests must not overwrite a newer record. | Two assigned reviews, exact base-version check, author-only application and an atomic SQLite write with audit. Domain rules · 24 local workflow tests. |
| KadamRun | A retry should preserve an already successful intermediate result. | Recipe snapshots, saved events and explicit owner-driven retries. State transitions · 24 local workflow tests. |
| KoshiMap | An import preview can become stale before the write. | Exact duplicate/conflict rules, server-side plan recalculation and whole-batch atomic application. Import planning · 24 local workflow tests. |
| ASHYQ Apply | Admissions workflows need explicit evidence states and background-job ownership. | Collaborative Python/React work with requirement states, job leases, retries and cancellation. Architecture and scope. |
On 26 October 2026, 96 local workflow tests passed across BekitChange, KadamRun, KoshiMap and QaitaCycle, 24 per project, on Node 24.15.0. These runs used synthetic data, SQLite and local HTTP. They establish the checked local behavior; external integrations and production operation need separate validation. The operational projects reuse a shared cabinet/authentication core.
- Context Platform: calculation modules, invalid inputs and horizon boundaries.
- Alēm Expert Router: skill/capacity constraints and explainable assignment.
- Petrel RAG: retrieval pipeline exploration and validation limits.
- Yummy and BudgetGate: order/stock transitions and expense-approval rules.
Define the result → model the rules → compare options → implement → verify → document the handover.
I make the important boundaries visible: rejected actions, stale data, ownership, restart behavior and the scope of tests. Workflow engineering notes explain three current examples.
Toolkit: Python/FastAPI · React/TypeScript · Node.js · SQLite · SQLAlchemy · Git · pytest. Technologies vary by project; follow the source and case notes for the reviewed scope.
I use AI tools in development and review. Tool permissions, private-data handling and acceptance criteria are agreed for each client brief. Project leadership is described at portfolio level; participant counts do not describe the contributors to every repository or a verified number of direct reports.
I publish short engineering explanations about architecture, reliable state transitions and business workflows.
LinkedIn · X / @wpalish · Astana Hub · Engineering notes · Email
Concept Work / Synthetic Data portfolio is labelled separately from repository work. Public projects include collaborative and AI-assisted development; the case notes distinguish local checks from client delivery and production outcomes.