Mikhail Nekrasov, Full-stack developer

Mikhail Nekrasov
Available for work

Someone who
burns for
the craft

Developer who doesn't walk away from a problem until it actually works — 9am or 3am, doesn't matter.

5+ years experienceReact · Node.js · TypeScriptRemote, any timezone
Journey

How I got to the current stack

Four milestones on one timeline: where I started, where I moved and where I am now. Below it, what I actually built by hand.

  1. Self-employed

    2019–present

  2. Independent contractor

    2021–present

  3. Worked at a startup

    2025–present

  4. Hackathon participant

    Jun 7, 2026

In my projects, at home and for clients

  • Built complex multi-boxing automation for several game servers
  • Designed and built e-commerce online stores
  • Built auto-posting and multi-account automation systems for social media
  • Ran game servers for a range of different games
  • Homelabbing as a hobby
  • Built home automation systems in C (Arduino & ESP32)
  • Reflashed 3D printers onto different microcontrollers
Cases04

Four sites, four different styles

Every screen below is a separate case, built for real in React and Tailwind. Not mockup images — working markup. Scroll and see for yourself.

Scroll down
01/04

Digital agency

02/04

Mimo Profile Widget

03/04

Wamflag

04/04

Tavlo: fintech landing

Working with AI

The model writes the draft. What ships is MY code.

I split the task into microtasks and hand the model exactly one piece at a time. Every fragment then runs through 12 checks. Scroll the block: this is my actual pipeline, step by step.

The pipeline runs on scroll
  1. 01Done by me

    Decomposition

    The task is cut into microtasks. Each one fits in my head whole and can be verified in a single pass.

  2. 02Done by me

    Context boundaries

    The model gets exactly one piece plus the project rules, never a "here is the repo, figure it out".

  3. 03Done by me

    Architecture and contracts

    Layers, module boundaries and signatures are designed before the first prompt is ever sent.

  4. 04Done by the model

    Draft from the model

    The one stage where the model does the work. What comes back is a draft, not a solution.

  5. 05Done by me

    Line by line

    I read every line and explain to myself why it is there. A line I cannot explain does not move on.

  6. 06Done by me

    Logic and types

    Invariants, types and states get checked. Code that compiles is not the same as code that is correct.

  7. 07Done by me

    Edge cases

    Empty data, races, dropped connections, double clicks. Exactly what a model tends to forget about.

  8. 08Done by me

    Tests

    First a failing test for the bug I caught by eye, then a green run.

  9. 09Done by me

    Performance

    Extra re-renders, per-frame allocations, queries in a loop. Cleaned up before the merge, not after complaints.

  10. 10Done by me

    Security and dependencies

    Input validation, secrets, new packages. A dependency I can avoid is a dependency I do not add.

  11. 11Done by me

    Refactor into the project

    Naming, structure, style. After this step the code is indistinguishable from the rest of the repo.

  12. 12Done by me

    Ownership

    My name is on the commit. Defending any line in review is my job, not the model’s.

  1. Decomposition: The task is cut into microtasks. Each one fits in my head whole and can be verified in a single pass.
  2. Context boundaries: The model gets exactly one piece plus the project rules, never a "here is the repo, figure it out".
  3. Architecture and contracts: Layers, module boundaries and signatures are designed before the first prompt is ever sent.
  4. Draft from the model: The one stage where the model does the work. What comes back is a draft, not a solution.
  5. Line by line: I read every line and explain to myself why it is there. A line I cannot explain does not move on.
  6. Logic and types: Invariants, types and states get checked. Code that compiles is not the same as code that is correct.
  7. Edge cases: Empty data, races, dropped connections, double clicks. Exactly what a model tends to forget about.
  8. Tests: First a failing test for the bug I caught by eye, then a green run.
  9. Performance: Extra re-renders, per-frame allocations, queries in a loop. Cleaned up before the merge, not after complaints.
  10. Security and dependencies: Input validation, secrets, new packages. A dependency I can avoid is a dependency I do not add.
  11. Refactor into the project: Naming, structure, style. After this step the code is indistinguishable from the rest of the repo.
  12. Ownership: My name is on the commit. Defending any line in review is my job, not the model’s.

What this means in practice

The model speeds up drafts and routine work. Everything that decides quality (decomposition, architecture, review, ownership) stays with me. Nothing lands in a project that I cannot explain line by line.

11/12pipeline stages I run myself
1stage handed to the model: the draft
0lines shipped without a line-by-line read
100%of the code I can defend in review

What I live for outside the house

I pump iron

I play guitar and sing in a band

Always on the move

Me in an all-white outfit and a hat at an outdoor concert

I live for concerts

My Flying Bear Ghost 5 3D printer

I 3D print stuff

I study world fashion

A disassembled smartphone showing the charging port board

I revive electronics