Ivan DolgovTech Lead / Full-Stack Engineer

I design and ship complex web systems — from requirements and architecture to production.

Web systems · architecture · cloud · enterprise software

Current
Tech Lead — Next-Generation WMSFrameworx, Daiwa House Group
Experience
5+ years
Base
Tokyo, JapanJST (UTC+9)
Languages
  • Native
  • Professional working proficiency (JLPT N1)
  • Professional working proficiency
Status
Open to selected consulting and contract work: remote from Tokyo, or with teams outside Japan.
Fig. 1Where I work in a system’s life, with the projects that show each stage.

  1. Requirements

    Defining and documenting what the system has to do, with the client

    P04

  2. Architecture

    Choosing the technical approach and proving the risky parts first

    P01P02

  3. Implementation

    Building the clients, services, and infrastructure

    P02P03P04

  4. Release

    Code review, engineering standards, and getting releases out

    P02P03

  5. Operation

    Keeping it running: performance, migrations, production support

    P03P04

Selected work

Most recent first. Case studies explain decisions; briefs state only role, scope, and system facts that can be published.

P01In progress

Next-Generation WMS

Technical planning and architecture for a next-generation warehouse management system, spanning application layers, cloud, security, and warehouse-control integration.

Role
Tech Lead
Org
Frameworx, Daiwa House Group
Period
2026/09–Present · 2 mos
Read the brief

  1. A1Application

    • Frontend
    • Backend

  2. A2Platform

    • Cloud
    • Security

  3. A3Integration

    • WMS/WCS integration

  4. A4Governance

    • Technology selection
    • Architecture standards
    • Engineering guidelines
    • Architecture decisions
    • Technical PoCs
Areas of technical responsibility. This is a scope map, not the system architecture, which is not public.

P02Completed

AI Chat Game Platform

0→1 development of a consumer AI chat game platform, led as Project Lead and full-stack engineer in a 20-person cross-functional team.

Role
Project Lead / Full-Stack Engineer
Org
Ikigai Co., Ltd.
Period
2025/07–2026/05 · 11 mos
Team
20-person cross-functional team
Read the case study

  1. L1Client

    • React
    • TypeScript
    • Vite
    • TanStack

  2. L2Identity · own domain

    • Keycloak

  3. L3API & compute

    • API Gateway
    • Lambda
    • Go

  4. L4Data · shared

    • PostgreSQL

  5. L5Infrastructure as code

    • Terraform
A request's path, top to bottom. Sign-in runs through a Keycloak server on its own domain, meant as the shared entry point for a planned family of applications. Simplified reconstruction, not the production architecture diagram.

P03Completed

Packaging-Industry SaaS

Full-stack work on a production web and mobile SaaS for the packaging industry, where growing data had degraded responsiveness for every customer.

Role
Full-Stack Engineer
Org
Nagashima Konpo Co., Ltd.
Period
2024/12–2025/12 · 1 yr 1 mo
Team
Approximately 10 people
Read the case study

  1. L1Clients

    • React
    • Next.js
    • React Native
    • Expo

  2. L2API · GraphQL

    • AWS AppSync

  3. L3Heavy processing

    • Lambda

  4. L4Data & storage

    • DynamoDB
    • S3

  5. L5Platform · per repository

    • AWS Amplify
Web and mobile clients over one shared AWS backend, reconstructed from my own description. Not a production architecture diagram.

P04Completed

Client Project Delivery

Five client projects across five industries, from a two-month corporate site led end to end to an insurance system built by roughly forty people — web delivery, CRM, and enterprise backend work.

Role
Software Engineer / Project Lead
Org
Flaretech Co., Ltd. (formerly Marvel)
Period
2023/03–2025/05 · 2 yrs 3 mos
Team
5 to 40 people, by project
Read the brief

  1. S1Requirements

    • Client negotiation
    • Requirements definition
    • Documentation

  2. S2Build

    • React
    • Next.js
    • Java/Spring
    • PHP/Laravel

  3. S3Deploy

    • AWS deployment

  4. S4Operate

    • Production support
    • SEO and operational improvement
The stages I covered across these projects. Which stages I owned depended on the project: on the smaller ones all four, on the largest only the middle two.

All workFull chronology

Capabilities, with evidence

Each mark points to a project where the responsibility is documented. Unmarked does not mean unable; it means not shown here.

CapabilityP01P02P03P04
Requirements & client coordinationDefining and documenting what a system has to do, with the client
Architecture & technology selectionTechnical planning and technology decisions
Project leadershipPlanning and coordination of delivery teams
Frontend engineeringWeb and mobile client applications
Backend & APIsServer-side services and APIs
Cloud infrastructureCloud infrastructure and deployment on AWS
Authentication & securityAuthentication, authorization, and security as an architecture concern
System integrationWMS/WCS integration planning
Standards & code reviewEngineering guidelines, architecture standards, and code review
Release & production supportGetting changes into production and supporting them there

Working principles

  1. P-01

    Record decisions where the team can find them

    Architecture decisions, guidelines, and standards are written down so that a choice made once does not have to be re-argued in every review.

    Practice: Architecture standardization, engineering guidelines, and architecture decisions — Next-Generation WMS.

  2. P-02

    Prove risky choices with a small build first

    When a technology or integration is uncertain, a bounded proof of concept is cheaper than discovering the limitation in production.

    Practice: Technical PoCs — Next-Generation WMS and packaging-industry SaaS.

  3. P-03

    Use code review to spread standards, not only to catch defects

    Reviews are where conventions become shared practice across a team, including external developers.

    Practice: Code reviews and standards — AI chat game platform; reviews and external developer support — packaging-industry SaaS.

  4. P-04

    Treat requirements as engineering work

    Clarifying what a client or operator needs is part of the system design, not a hand-off that happens before it.

    Practice: Requirements definition and client coordination — Flaretech client projects and freelance work.