Senior Backend Engineer · Tech Lead · 6+ years
Max
Yastremskyi
Positioning
I own the parts of a system that must not be approximately right — money, orders, production workflows — and I build the tooling that proves the work was actually done.
Facts
- Stack
- PHP 8.4 · Laravel 12 · Node / NestJS
- Data
- MySQL 8 · Redis · Docker
- Based
- Ukraine, UTC+3
- Open to
- Remote worldwide · relocation · available at two weeks’ notice
- Markets
- Israel · Ukraine
- Languages
- English B2 · Ukrainian Native · Russian Fluent
Open source · MIT · the flagship
Groundwork
A Claude Code plugin that makes verification part of the development process instead of leaving it to the human.
“An agent will happily write plausible code and just as happily report that it is done. Groundwork makes the checking part of the process.”
- 7
- production codebases
- 340
- procedure runs
- 160
- written specs
- 27
- frontend hand-offs
- 1 in 3
- stopped before code
Approximate, as of August 2026
Pick a task. Watch the process resize.
Zero JavaScript — radio inputs and CSS. Keyboard: Tab into the group, then arrow keys. Works with scripting disabled.
L0 — Tiny
No spec. No plan. No review agents. No approval. The automatic gates are the entire Definition of Done.
Who reviews
Nobody — and that is deliberate.
What is required
- The gates that fire on their own
L1 — Small fix
A regression test that fails first, then one live exercise of the single thing fixed — not a sweep of every consumer.
Who reviews
No agents — a targeted self-trace instead.
What is required
- Short inline spec
- Fail-first regression test
- Live check of the one thing fixed
L2 — Feature
Discovery fans out before anything is planned. The blast radius is mapped, not assumed, and nothing is written before the plan is agreed.
Who reviews
- impact-mapper — what will this break
- conformance-reviewer — does the diff satisfy the criteria
What is required
- Spec, plan, approval
- Up to 2 rounds of questions
- Tests written before the code
L3 — High risk
Permissions, migrations, public contracts, financial visibility. Here the intent gets challenged, not only the code.
Who reviews
- impact-mapper
- blind-spot-map — what nobody thought to ask
- grounded-researcher — what the provider actually does, cited
- conformance-reviewer
- adversarial-verifier — is “it works” true
What is required
- Spec, plan, requirements check, deployment notes
- Up to 4 rounds of questions
- An ADR when the decision is cross-cutting
L4 — Critical
Financial calculation, order lifecycle, the permission model, destructive migrations. Being approximately right here is being wrong.
Who reviews
- Everything L3 engages
- An adversarial panel — at least two independent skeptics on the riskiest claims
What is required
- Everything L3 requires
- Rollback notes
- Human approval, always
- format on edit
- static analysis
- test suite
- OpenAPI contract
- enforced runner
- migrations locked
- edits locked in discovery
- unpushed work
- coverage claim
- task intent
- agent contract
Selected work
Four decisions
Not feature lists. Each records the constraint, what was chosen over what, and the detail a mid-level engineer would have got wrong.
- 01
Groundwork
Risk-based task classification L0–L4, 5 specialised review agents,11 automated gates and 14 workflow procedures, shipped under MIT.
The subtle partRoughly one task in three is stopped before any code is written — mis-scoped, conflicting with existing behaviour, or cheaper to solve without development. - 02
Voice to structured data
Speech becomes a validated task rather than a guess — domain-tuned transcription, schema-constrained extraction, and a human in front of every action.
The subtle partThe tests must never call the provider. It is not about the invoice — a suite that depends on a remote model is a suite that fails for reasons unrelated to the change under test, and a team learns to ignore it within a fortnight. The provider is mocked in CI, and model upgrades are caught by response-regression tests that compare structured output against fixed cases, so a silently retrained model is caught by the suite instead of by a user. - 03
Payments, clearing and tax documents
Card tokenization, idempotency-keyed clearing and accounting export, in a domain where being approximately right is being wrong.
The subtle partA tax document with a zero total is rejected outright by the provider. That sounds like an edge case until a discount, a refund or a fully-covered line produces one in the middle of an otherwise valid batch — and because issuance is all-or-nothing, the whole batch fails and nobody's invoices go out. Those items have to be recognised and closed locally instead, so the zero never reaches the provider at all. - 04
Multi-market commerce platform
One codebase cloned per market — config-driven currency, locale and timezone — with a pricing engine, driver-abstracted payments and delivery, and an ERP catalogue sync.
The subtle partCatalogue sync from the ERP stages every product change as a typed DTO for a human to review before it applies. It would have been far less work to write the incoming data straight to the catalogue — and an import that applies itself is an import nobody can undo. When the ERP sends a bad price on ten thousand products, the difference between staging and applying is the difference between a rejected batch and a weekend.
Capability map
What I do
Grouped honestly. No percentages — a bar chart of skills tells a reader nothing they can verify.
Backend & platform
- PHP 8.4, Laravel 12
- Node, NestJS
- MySQL 8, PostgreSQL
- Redis
- Docker
- Microservices
Money & correctness
- PCI card tokenization
- Idempotency keys
- Decimal money with bcmath
- Multi-currency and VAT
- Accounting and tax export
- Recurring billing, direct debit
Applied AI in production
- Schema-constrained extraction
- Tool calling without auto-execution
- Per-call cost accounting
- Provider abstraction and fallback
- Prompt-injection defence
- Response-regression tests
Integration & reliability
- Driver fallback chains
- Delivery-status webhooks
- Integration health-probe registry
- Queued job chains
- OAuth2 machine-to-machine
Hard rendering & data
- Hebrew RTL and bidi PDF
- OCR by morphological grid extraction
- CIE-Lab colour classification
- Typo-tolerant search and ranking
- FFmpeg and Imagick pipelines
How I lead
- Spec-driven development
- Blast-radius discovery before planning
- Adversarial verification
- OpenAPI contracts kept current
- Server-side RBAC
- Frontend when it is in the way: Vue, React, TypeScript
How I work
Three rules
They are not aspirations. They are what the tooling enforces.
Ground it, don’t guess it.
What an external provider does is confirmed against its official documentation with a citation, or marked unknown and proven in a sandbox. A plausible answer about someone else’s API is the most expensive kind of wrong.
The spec is the cheap place to be wrong.
Discovery is wide; the change is narrow. One task in three never reaches code because the discussion showed it was mis-scoped, already solved, or cheaper without development.
A claim is not evidence.
Tests, static analysis and contract checks run as gates rather than as good intentions. “It works” gets challenged by a reviewer whose only job is to try to refute it.
Contact
Available
Open to Senior Backend and Tech Lead roles — remote worldwide · relocation · available at two weeks’ notice. I have worked the Israeli and Ukrainian markets, including Hebrew and right-to-left products.