Feature
Number One

00 — Who we are

Payment orchestration platform

01 — Equalizer

AI is the EQUALIZER

You don't need to string copper wires when the technology has already moved on. Countries that skipped the wired era are winning today as much as the ones that laid those wires for a hundred years.

The moats are gone. Every company is on the same field. The only question left — how are you building?

02 — DIFFERENTIATOR

Quality will be the DIFFERENTIATOR

When anyone can ship, shipping is no longer the advantage. The product that works reliably, behaves predictably, and doesn't surprise its users — that's the one that survives. That's Feature Number One.

03 — Feature Number One

Our Feature Number One

Not a vibe. Not a slogan. Three numbers that move with the product.

• 99.9999% uptime + one slow-running defect → GMV still bleeds.
• GMV and uptime green, but a merchant sees a UI defect → they stop trusting the processing too.
• Only when all three are green do we actually ship trust, not just uptime.

03 — Yours

What's your One?

Every product has one thing it cannot get wrong. Not features. Not speed. The one promise that, if broken, breaks the whole product.

Find your One. Defend it. That's your Feature Number One.

04 — New challenge

There is no Best-Practices Playbook

AI-assisted engineering is less than two years old. Agentic workflows — where the AI drives the tools — are barely a year. Nobody knows the right way yet. What worked yesterday might break tomorrow — models, context, and tools shift every month. The experience hasn't crystallised into canon — we're in the trial era, not the textbook era. Every team building today is an expedition.

06 — New challenge

A quarter's work in days

Rebuild a whole feature. Tweak every UI element. Restyle the entire product — in a single sitting. What took a quarter now takes an afternoon. The old processes were built for expensive change: long planning, staged approvals, big-batch releases. At this speed those rituals don't protect quality — they just slow it down.

When change is this fast, the old process is the bottleneck.

08 — Foundation

Input quality is the foundation

Domain. Architecture. Features. Three vertices of a triangle — each holds up the other two.

Brief is for search. Detailed is for work. AI generates from exactly what's here.

09 — Living architecture

Architecture that answers back

{
  "flow": "card_payment",
  "steps": [
    {"n": 1, "from": "pf-fe",    "to": ["pf-be", "track"]},
    {"n": 2, "from": "pf-be",    "to": "cardgate"},
    {"n": 3, "from": "cardgate", "to": ["tokenizer", "geoip"]},
    {"n": 4, "from": "cardgate", "to": "psp", "via": "kafka"},
    {"n": 5, "from": "psp",      "to": "adyen-hw"},
    {"n": 6, "from": "adyen-hw", "to": "adyen", "external": true}
  ]
}

10 — Code Review

Agent-driven code review

Most defects live in the code itself — an agent that reads the diff catches the obvious ones without running a single test. One per defect class, in parallel on every MR, so the defect dies before a human opens it.

• Unoptimized queries that fall over at production scale
• Payloads that violate the specification
• Tests written to pass, not to prove
• Access granted without a permissions check

The earliest review is the cheapest. The cheapest? Reviewing code you never wrote.

11 — Definition of done

Untested code is unfinished work

Tests aren't a follow-up task. A feature without them is a draft — it works until the first change. AI made tests cheap to write; the last excuse is gone. Code and its tests ship in the same merge request.

Done means tested.

12 — Test Coverage

How many tests is enough?

One question to the great master: "What code coverage should I aim for?" Three answers.

The third wanted a simple answer — and wasn't going to follow it anyway.

13 — Coverage with context

Test Coverage with Context

You could always hit 80% with tests that prove nothing — no real-world cases, no acceptance criteria behind the green. Reviewing every test for actual value never scaled for humans. With AI it does. The gate stops being a number and becomes confidence.

Golden rule: E2E never changes without review.

14 — Testing levels

Shift left — cover right

A real page: a list of orders. 15–20 filters — email, ID, date ranges, statuses — plus results, sorting, pagination.

Cover it all with E2E? Real data for every validation, every filter, every range and every page — slow to write, slow to run, brittle forever.

Same confidence — a fraction of the cost. Cover each behavior at the lowest level that can catch it.

15 — Architecture First

Quality can't be tested in. It's engineered.

Quality lives in the decisions you make at design time: where to draw the boundaries, how to structure the system, which contracts to set. Tests only verify what those decisions already made true.

• A clean boundary removes a whole class of bugs. A test catches one instance of it.
• Where state lives, how services talk, what's coupled — that's where quality is won or lost.
• Changeability, observability, failure behavior — designed in, or absent. Tests can't add them after.

You can't out-train a bad diet — and you can't out-test a bad design.

16 — Ownership

Quality is owned by engineers

AI can write the tests. Only the engineer who ran the flow end-to-end knows if the product actually works — and knows the product well enough to make the next iteration easier.

• No automation smells bad UX: a flow that sounds great in the ticket can feel terrible in the hand.
• Exhaustive testing is impossible — you'll never cover every case. At least not yet.
• The 3–5 person chain collapsed to one owner, end to end — accountability is a name, not a team.

17 — Automation at scale

Harness engineering

AI does the task, automated checks judge the result. Failed — AI retries, up to N attempts. Still red — the harness calls the engineer. Only verified work comes out, and nobody babysits the steps in between.

• Mass changes across the codebase
• Minor bugs that live in the backlog forever
• Backfilling specific test coverage
• Dependency upgrades rolled out across every service

A task repeated a hundred times is one harness, not a hundred tasks.

23 — Ward

Reads everything. Invents nothing.

$0.19

avg investigation

$0.40

budget cap per run

5 min

hard timeout

• Read-only: metrics, logs, deploys, Sentry, service map.
• Three reply styles per channel: concise · verbose · structured.
• Lessons: the team teaches it per channel — saved guidance overrides assumptions.

Yurii Zaiveliev

One of our best DevOps

Vladyslav Pavlenko

One of our best Engineers

What made the difference

So what made the difference?

At Michigan, Brady was the backup's backup. The starter got 20 practice reps. The backup got 10. Brady got 2. He complained to Greg Harden, the team's sports psychologist — and the answer became the rule of his career. Brady sprinted into every practice snap like it was the Super Bowl. Two reps became four, four became ten — ten became the starting job.

“You'll never achieve greatness doing average most of the time.”

One last thing

What is YOUR Super Bowl?