Forem: Artur Goncharov

Two months, one engineer, one production B2B marketplace — what AI-directed full-stack actually looks like

Artur Goncharov — Mon, 20 Apr 2026 21:02:37 +0000

I shipped a production B2B marketplace for the Russian HVAC industry — wentmarket.ru — alone, in two months, end to end. Not an MVP. Full commerce, seven external integrations, seventeen engineering calculation engines, 101 Prisma models, 446 test files, real paying customers.

This post is the breakdown of what was actually in it, how the work was split between me and Claude Code, and the parts I would not delegate again.

If your first reaction is "solo-built in two months is a red flag, not a feature" — good, mine would be too. Stick around. The answer is disclosure plus a list of concrete things that are in the repo.

What "AI-directed engineering" actually means here

The division of labor across the two months:

Me: product scope, domain model, database schema, integration architecture, performance budget, edge cases, production QA, every decision that touches revenue or data integrity.
Claude Code: CRUD handlers, first-pass tests, boilerplate React components, email templates, refactors I specify line by line, anything with an obvious shape.

This is not autocomplete. It is a workflow: I write the spec, Claude writes the first draft, I review and rewrite maybe 30–50% of it, Claude applies the rewrite, I ship. The failure mode is not "AI writes broken code" (current models rarely do on well-scoped tasks), the failure mode is "AI writes working code for the wrong problem." That is a human problem and it does not go away with better models.

In exchange for the discipline of writing clear specs, I get maybe a 3× throughput improvement on everything that is not an architecture decision. On a two-month solo sprint that compounds into roughly a team-of-four's worth of output — which is the number I actually felt.

The product, itemized

wentmarket is a two-sided marketplace for HVAC (ventilation equipment). B2B procurement, B2C retail, and a contractor-oriented engineering layer that helps specify the right fan / air handling unit / silencer for a duty point.

Commerce

584 products, 2,308 configurable product variants, 2,139 motor options, 62 categories
B2B portal with client-specific pricing pulled from 1C ERP, quote workflow, PDF submittal generation
B2C checkout with CDEK delivery rates, Yookassa payment with 54-FZ fiscal receipts and idempotent webhooks
35-section admin panel for moderation, inventory, orders, manual overrides

Engineering

17 calculation engines total, including:
- Fan selection by duty point (flow + pressure) across 18,141 polynomial pressure–flow curves indexed in Postgres, 4 ms average match time
- Air-handling-unit configurator with 10 sub-engines (psychrometric, ε-NTU heat-exchanger sizing, octave-band acoustics, filter selection, recuperator, fan-block, silencer, damper, control, life-cycle cost)
- Silencer selector (acoustic sum across 6 components)
- Life-cycle-cost calculator (15-year horizon, energy + maintenance)
- VFD (variable-frequency drive) sizing
- Duct pressure-loss calculator
- BIM model generator for engineering deliverables
385 automated engineering tests against manufacturer reference data; CI blocks merges at >0.5% deviation

Integrations (each with retry, timeout, HMAC/signature verification, graceful degradation)

1C ERP — bidirectional product and order sync over Russian SOAP
Bitrix24 CRM — full service layer, ~1,500 LOC, lead + deal + customer + funnel analytics
Yookassa — payment processing, 54-FZ fiscal receipts, SHA-256 idempotency
CDEK — delivery cost calculation, order creation, courier dispatch, PDF waybill
Meilisearch — typo-tolerant search with Russian synonyms, Prisma fallback if Meilisearch is down
Telegram — bot with 40+ commands + Mini App with HMAC-verified initData auth
DaData — company lookup by INN, Sentry for error monitoring

Stack
Next.js 16 (App Router, Turbopack), React 19, TypeScript strict, Prisma ORM, PostgreSQL, Redis, BullMQ, NextAuth v5, Docker, GitHub Actions, Vitest (unit + integration), Playwright (E2E across desktop + mobile viewports). Linux VPS, systemd service, Nginx reverse proxy with 50 r/s rate limiting. Redis L2 cache, BullMQ job queues, distributed rate limiting, PostgreSQL soft-delete via Prisma $extends.

Testing

446 test files total
1,574 unit tests (Vitest, 60%+ coverage)
165 Playwright E2E tests across 17 user-journey spec files
385 engineering tests, manufacturer-reference-data parity

That is not decoration. The 385 engineering tests exist because fan selection is a safety-adjacent decision — a mis-sized fan in a kitchen ventilation system is an actual fire risk.

The parts that took longer than they should have, honestly

1C ERP integration. Russian accounting software speaks a SOAP dialect that is half ISO-20022 and half vibes. The schema is publicly undocumented in English. Took about two weeks including a very educational detour into Microsoft Windows character encoding on the wire. If you have not touched windows-1251 in a while, it is still there, waiting.
Polynomial curve ingestion. 18,141 curves came from manufacturer PDFs, scraped HTML tables, Delphi data files, and Excel sheets with merged cells. Each format needed its own parser and a verification harness that plotted the result against the original datasheet to catch fit drift. Curves are stored as double precision[] coefficient arrays in Postgres; Horner's-method evaluation evaluates each at ~30 ns. Wrote that up separately here with the OSS extract at polynomial-fan-matcher.
The AHU configurator UX. First version was a drag-and-drop canvas. Showed it to three HVAC engineers, they bounced off it in 30 seconds. Rebuilt around what they actually do: enter a duty point, receive three matching AHUs, override individual components in focused forms. Time-to-first-viable-configuration went from ~12 min to ~40 sec on the same users. Killed six weeks of work making that call. I would do it again.
Testing the engineering engines. This is where the "Claude does tests" claim has to be qualified. Claude writes test scaffolding and first-pass assertions — but the actual reference data (expected outputs) comes from manufacturer datasheets that I had to digitize by hand, and the tolerance bands come from ASHRAE / СП 60.13330. That calibration is irreducibly human, irreducibly domain-specific, and it is where the value is.

What I would not delegate to Claude, even next time

Domain model decisions. A Product vs. a ProductSeries vs. a ProductVariant vs. a MotorOption is not a naming problem, it is a commercial model. Getting that wrong costs you the next six months.
Integration contracts. What exact payload do we send to 1C when a B2B client places a quote that has not yet been approved? The answer depends on the customer's internal workflow, not on the 1C documentation. A model cannot solve that for you.
Error-handling philosophy. Fail fast or degrade gracefully? The answer is different for the payment webhook (fail fast, write to the incident table, the human decides) and for the search index (degrade gracefully, fall back to Prisma LIKE, never block commerce on search availability). Picking the right mode per surface is an architecture call.
What not to build. Every feature I did not build saved me more time than the ones I did build. "Should we add a chatbot" / "should we build a mobile app" / "should we add multi-currency pricing" all got answered "not in V1" and that is why V1 shipped.

Numbers that matter, briefly

584 products, 2,308 variants, 2,139 motor options, 62 categories
101 Prisma models, 40+ enums, 35-section admin panel
18,141 polynomial curves, 4 ms duty-point match, 385 engineering tests
446 test files, 60%+ unit coverage, 165 E2E specs across desktop + mobile
7 production integrations, each with retry / timeout / HMAC / graceful fallback
Two months, one engineer, with Claude Code as a build-accelerator
Live, paying customers

Why I am posting this

Two honest reasons.

One: I think the industry is still calibrating what "AI-accelerated solo engineering" actually looks like on a serious product. A lot of the public discourse is either "solo founders ship magical 10× speed with AI now" or "it is a glorified autocomplete, nothing has changed." Neither is useful. The real thing is closer to: with the right discipline, one competent senior engineer can ship what a team of four used to ship, on a real B2B product with real integrations, in a short window. I wanted to describe that specifically rather than generically.

Two: I am looking for offers. Open to engineering roles (remote or relocation), licensing the engineering engines to a Western HVAC or building-simulation vendor, partnership conversations, or acquisition discussions. I am in Russia (UTC+3), fluent in written English, speaking still developing so I work async-first.

If any of that is interesting:

Live product: wentmarket.ru
OSS extract (fan-matching polynomial engine): polynomial-fan-matcher
5-min demo video: youtu.be/sZnvwEfCwVk
Contact: goncharov.artur.02@gmail.com

Happy to go deeper on any specific engine, integration, or architectural decision in the comments.

How I indexed 18,141 polynomial fan curves in Postgres and matched a duty point in 4 ms

Artur Goncharov — Mon, 20 Apr 2026 08:24:19 +0000

If you work in building HVAC, you know the ritual. You need a fan that will push 5000 m³/h at 400 Pa. Your manufacturer rep emails you a 400 MB installer — usually Windows-only, often Delphi, almost always from 2007 — and you click through dialog boxes until the program picks a fan for you. The selection engine is a black box. You cannot embed it. You cannot query it. You cannot even link to a result.

The math underneath is not complicated. It has been public for decades. It is just locked behind a desktop binary.

I have been building a web-native alternative for a Russian HVAC marketplace. The selection engine now indexes 18,141 real manufacturer pressure–flow curves across 13 fan families, and picks a matching fan for a given duty point in about 4 ms on a single Postgres row read plus in-memory evaluation. This post walks through the storage model, the evaluation math, the matching loop, and the three gotchas that each cost me roughly a week.

Full working code: github.com/goncharovart/polynomial-fan-matcher. Everything below runs in production on wentmarket.ru.

The problem, stated precisely

A fan has a characteristic curve: for every volumetric flow rate Q (in m³/h) the fan is capable of producing, there is a corresponding static pressure P(Q) (in Pa) it can develop. As Q goes up, P goes down. The curve is smooth and roughly quadratic.

Given a target duty point — say Q_target = 5000 m³/h at P_target = 400 Pa, with a tolerance band of ±15% on pressure — I want to, against a catalog of ~18,000 curves, return the subset that:

Physically covers the target flow (the curve is defined at Q = 5000).
Produces a pressure at that flow inside [340, 460] Pa.
Is ranked by efficiency η(Q_target), because two fans that both "work" are not the same fan — the one consuming 2.2 kW instead of 4.0 kW pays for itself in 18 months.

Why a lookup table is the wrong answer

The naive move is to store each curve as a list of sampled (Q, P) points — say 100 evenly spaced samples between Q_min and Q_max. Matching then becomes "find the row, interpolate linearly between the two nearest samples."

For 18,141 curves at 100 samples each, that is 1.8 million rows. Postgres can chew through that, but you are paying three costs you did not have to pay:

Storage is inflated. Each curve that actually fits in 5 floats is now 200 floats.
Every read is an interpolation, which introduces piecewise-linear error between sample points.
Scaling the curve becomes awkward. Fans run at variable speeds via VFDs; affinity laws say Q ∝ n and P ∝ n². Applied to a polynomial, that is a one-line coefficient transform. Applied to 100 samples, it is 100 multiplications plus a full re-sampling grid.

Storage: a tiny array of coefficients

A fan curve is well-approximated by a polynomial of modest degree:

P(Q) = a_0 + a_1·Q + a_2·Q² + a_3·Q³ + ... + a_n·Qⁿ

In practice, degree 3–5 is enough. Catalogs I imported use degree 6 at the high end. Each curve is stored as an array of 7 floats.

CREATE TABLE fan_curves (
  id             bigserial PRIMARY KEY,
  fan_id         bigint   NOT NULL,
  label          text     NOT NULL,
  coeffs         double precision[] NOT NULL,
  q_min          double precision NOT NULL,
  q_max          double precision NOT NULL,
  eta_xpoints    double precision[] NOT NULL,
  eta_values     double precision[] NOT NULL,
  n_nominal      double precision NOT NULL,
  fan_type       text     NOT NULL
);

CREATE INDEX fan_curves_q_range_idx ON fan_curves (q_min, q_max);

Evaluation: Horner, not `Math.pow`

The wrong way:

// DON'T do this
let p = 0;
for (let i = 0; i < coeffs.length; i++) {
  p += coeffs[i] * Math.pow(q, i);
}

Horner's method: same polynomial, computed right-to-left with one multiply and one add per coefficient. No pow:

export function evaluatePolynomial(coeffs: number[], q: number): number {
  if (coeffs.length === 0 || !Number.isFinite(q)) return 0;
  let result = 0;
  for (let i = coeffs.length - 1; i >= 0; i--) {
    result = result * q + coeffs[i];
    if (!Number.isFinite(result)) return 0;
  }
  return result;
}

On an M2 laptop this evaluates degree-6 in ~30 ns. For 18,141 curves the full batch is ~540 µs. The rest of the 4 ms budget is Postgres I/O.

The matching loop

export function matchDuty(curves: Curve[], duty: Duty): Match[] {
  const { qTarget, pTarget, tolerance } = duty;
  const pMin = pTarget * (1 - tolerance);
  const pMax = pTarget * (1 + tolerance);
  const results: Match[] = [];

  for (const c of curves) {
    if (qTarget < c.qMin || qTarget > c.qMax) continue;
    const p = evaluatePolynomial(c.coeffs, qTarget);
    if (p < pMin || p > pMax) continue;
    const eta = interpolateEta(c.etaXpoints, c.etaValues, qTarget);
    results.push({ curve: c, pressureAtQ: p, deviation: (p - pTarget) / pTarget, eta });
  }

  results.sort((a, b) => (b.eta - a.eta) || (Math.abs(a.deviation) - Math.abs(b.deviation)));
  return results;
}

Benchmark on production catalog:

Stage	Mean time
Postgres range-filter + row transfer	2.8 ms
Horner evaluation, 2,100 rows mean	0.6 ms
η interpolation and sort	0.5 ms
Total (warm cache)	3.9 ms

The three gotchas that each cost a week

1. Pressure and efficiency are separate functions

Assuming η(Q) can be derived from P(Q) via a shaft-power formula is the single most common mistake in naive fan-selector tutorials. It cannot. Pressure drops roughly quadratically; efficiency has a bell shape peaking around 70% of Q_max. Two curves with similar pressure at a duty point can have drastically different efficiencies there. Store η as its own thing — my data ships as vectors of sampled measurement points, linearly interpolated.

2. Polynomial degree varies per manufacturer

One catalog fits degree-3. Another fits degree-5. A third went with degree-6. Zero-pad every curve to the max degree so the hot loop has a fixed shape and the JS engine keeps the inner loop monomorphic:

const MAX_DEGREE = 6;
function normalizeCoeffs(coeffs: number[]): number[] {
  const out = new Array(MAX_DEGREE + 1).fill(0);
  for (let i = 0; i < coeffs.length && i <= MAX_DEGREE; i++) out[i] = coeffs[i];
  return out;
}

Measured: ~30% faster on the full batch after zero-padding.

3. Extrapolation is silently wrong

A polynomial evaluated outside its fit domain does not return an error. It returns a physically meaningless number — often negative pressure or a value implying the fan produces more air at higher static pressure, which is not how fans work. The domain check is a correctness guarantee, not an optimization:

if (qTarget < c.qMin || qTarget > c.qMax) continue;

I skipped this originally. A user asked for 200 m³/h on a fan whose curve started at 800. Engine reported 1200 Pa. The fan would stall in reality.

Scaling across RPM — the affinity law bonus

export function scaleByRpm(coeffs: number[], nBase: number, nTarget: number): number[] {
  const r = nTarget / nBase;
  return coeffs.map((a, i) => a * Math.pow(r, 2 - i));
}

One pass over the array. The stored curve stays unmodified.

Benchmarks, cold and hot

Scenario	p50	p95	p99
Cold cache, first query	38 ms	62 ms	94 ms
Warm cache	4.2 ms	6.1 ms	9.8 ms
Warm + query cache hit	0.9 ms	1.4 ms	2.3 ms

What is in the repo, and what is next

The polynomial-fan-matcher repo extracts the evaluation and matching core from production. It ships:

evaluatePolynomial(coeffs, q) — Horner in 10 lines
scaleByRpm(coeffs, nBase, nTarget) — affinity-law transform on coefficients
matchDuty(curves, duty) — the matching loop from this post
Tests against manufacturer reference data

This OSS module is one subsystem extracted from wentmarket.ru — a vertical B2B HVAC portal I built over ~2 months. The full platform combines a marketplace (2K+ SKUs, B2B/B2C commerce with 1C ERP and Bitrix24 CRM integration), an engineer's toolkit (17 calculation engines: fan selection, VFD, LCC, acoustic silencers, AHU designer, duct losses, 3D BIM exports), and a Telegram ecosystem (27 bot commands + Mini App). I used Claude Code as a tool-accelerator for boilerplate, test generation, and first-pass bug hunting — architecture, stack choices, HVAC domain modeling, and production QA are mine. If you work on HVAC tooling in the West and want to talk about collaboration, licensing, or engineering work, I am reachable at goncharov.artur.02@gmail.com.

Summary

Store fan curves as polynomial coefficient arrays in Postgres, not sampled lookup tables.
Evaluate with Horner's method; 10 lines, no Math.pow, stable floating-point.
Index on (q_min, q_max) and domain-check every query.
Keep pressure and efficiency as independent curves.
An extract of the production engine is open source at github.com/goncharovart/polynomial-fan-matcher; it matches 18k curves in ~4 ms.