Team & process

Roles, Delivery Method & Cadences

Five people, three codebases, two weeks. This page is the deliverable the qualification exercise asks for under “documentation of the team structure, roles, and responsibilities” and “an overview of any AI-assisted coding tools used and how they contributed”.

On this page

Roles & responsibilities

Person Role Responsibilities
Oleksandr Andriichuk Team Lead Scope and delivery ownership, team organisation, task breakdown and assignment, cross-repo decisions, client-facing communication and the documentation set (this site included)
Abddukodir Gofurboyev Senior Backend Developer Backend development and system architecture: the NestJS services, the money path (payments → pricing → accrual → claim → attestation → relay → settlement), the data model and its invariants, deployment
Uladzislau Popou Senior React Native Developer Mobile development and mobile architecture: the WDK worklet integration, wallet lifecycle, session lock and biometrics, the store/API layering
Siamon Krapivin Senior React Native Developer Mobile development and mobile architecture: payment flows (scan, send, approve), the asset registry and balances, the rewards and claim screens, UI system
Mikita Yakunin QA Engineer Test planning and manual verification across all three codebases: the end-to-end money path on testnet, mobile regression passes (wallet lifecycle, scan/send/approve, claim), release checks before each main deploy, and bug reports on the project board

Both React Native engineers are senior and share architectural ownership of the app rather than splitting it into “features” and “plumbing”. The split above is where each spent most of their time, not a fence — every non-trivial mobile decision (the app → screens → shared import rule, the single RootStore, gas-mode fallback, the ERC-1271 claim signature) was made by the two of them together.

AI tooling

Two tools, used deliberately and for different jobs. Neither was allowed to merge anything on its own: every line landed through a human-reviewed pull request, and the test suites (590 backend tests, 119 contract tests) are the gate that made that review affordable.

Tool Used as What it actually contributed
Claude development and design tool Architecture exploration before code (process split, trust boundaries, the claim state machine), implementation of well-specified modules, test generation, security review of the money path, and this documentation set
Cursor agentic IDE In-repo, multi-file execution of agreed changes: refactors across a module, wiring a screen to an endpoint, keeping AGENTS.md/CLAUDE.md conventions applied consistently while editing

The conventions files in each repo (backend/CLAUDE.md, mobile/AGENTS.md) exist for this reason: they are the brief both tools read, so generated code arrives already shaped like the code around it — kebab-case files, E-prefixed enums and centralised error codes on the backend, single-line comments, named observer() components and the app → screens → shared import rule on mobile.

One convention worth calling out: mobile reviews leave AI-REVIEW: comments inline and the answer goes directly below as AI-ANSWER:, with the original question never removed. The reasoning behind a decision stays next to the code that embodies it instead of dying in a pull-request thread.

Delivery method

Two weeks, five people, three repositories — short enough that a sprint-based process would have spent more of the window on ceremony than on delivery. We ran continuous-flow Kanban on a GitHub Projects board, with the pieces of Scrum that pay for themselves at this length kept and the rest dropped: a single prioritised backlog, one owner per item, an explicit definition of done, a work-in-progress limit, and a written record of every decision.

Practice How we applied it
Board as the single source of truth Columns are Backlog → Ready → In progress → In review → Done. Nothing is worked on that is not an issue on the board, so status is read off the board instead of asked for
One owner, WIP limit of one Every issue has exactly one assignee, and an engineer takes a second item only when the first is in review. Parallel half-finished work across three repositories is the failure mode we were most exposed to
Vertical slices, not layers Work is cut so each issue lands something demonstrable end to end — "claim a coupon on Sepolia", not "write the claim service". Cross-repo slices carry the contract (the paymentRef derivation, the EIP-712 domain) as part of the same issue
Definition of done Merged into develop, reviewed by someone who did not write it, tests and coverage gate green in CI, and the documentation page for that area updated in the same pull request. An issue is closed by the pull request, not by hand
Clear decision ownership The team lead owns scope, priority and all client-facing communication — one voice outward. Technical decisions inside an area belong to that area's owner; anything crossing two repositories needs both owners to agree, in writing
Risk register instead of end-of-project surprises Known defects and accepted trade-offs were tracked as they were found, with severity and cause, and handed over as the Known gaps page rather than discovered during review

Cadences

Async-first: written by default, synchronous only where a call is genuinely cheaper than a thread.

Cadence When Purpose & output
Daily written check-in Every working day, async Three lines per person — shipped, next, blocked — posted in writing rather than gathered in a meeting. The board is updated before the check-in, so the check-in only carries what the board cannot show: blockers and intent
Cross-repo sync Twice a week, ~30 min The one call worth having with three repositories in flight: the shared contracts — REST shapes, the EIP-712 domain, paymentRef, deployed addresses. Output is a written decision and, where it needs one, a shared fixture
End-of-week demo & re-plan Weekly Working software on a device against the deployed backend, not slides. The demo sets the next week's priorities, so scope was re-cut twice inside the window rather than defended to the end
Retrospective End of delivery What we would keep and what we would change — written up as the Lessons learned and Next steps pages instead of staying in a call

Response times we held ourselves to

Not meetings — targets. A cadence says when we talk; these say how long something is allowed to sit. On a board with a work-in-progress limit, waiting is the expensive part.

Commitment Target Why it is the number that matters
Blocker escalation Same day, no waiting A blocked item is flagged on the board and raised to the team lead immediately rather than saved for the next check-in. Anything needing the client or the WDK team leaves as an email the same day, because their clock starts when ours stops
Pull-request review turnaround Within one working day Review latency is what stalls a WIP-limited board: with one item each, a review sitting for two days stops two engineers, not one. Cross-repo changes need both owners; CI gates the branch and nothing merges red

Channels

Channel Used for
Gmail The written record: daily check-ins, scope questions and decisions, and the support thread with the WDK team. Anything that changes scope or a shared contract ends up here, so a decision can be re-read months later
GitHub Project Issues Task distribution and management: every unit of work is an issue on the project board, assigned to one person, moved across columns, and closed by the pull request that implements it
GitHub pull requests Code review — every change is reviewed by someone who did not write it, and a change to anything two repos share (the paymentRef derivation, the EIP-712 domain, the REST shapes) needs the owners of both sides. CI gates the branch; nothing merges red

Branching follows the deployment: work branches into develop, develop into main, and Dokploy deploys main. CI does not deploy — it gates, so a red pipeline never reaches the branch the deployment watches. The full pipeline is on the Operations page.