SultanaExpress

Building in the Open

We build in the open.

SultanaExpress is a B2B sourcing platform for the Türkiye→Europe corridor, rebuilt step by step in public. 649 steps planned. 304 done. Every number on this page is counted, dated and re-derived at publish — never estimated.

—

Why in the open

We are pre-launch. Beta opens September 2026. A platform that is not yet live and asks factories and buyers for trust has exactly one honest proof available: the work itself. So we publish it — the plan, the counts, the dates, and the checks every change must pass.

Nobody in this category does this. Sourcing platforms typically advertise undated totals — "55,000+ companies", no date, no source. We publish the opposite: counters derived from a generated status board, stamped "as of". When a number on this page moves, it moves because the work moved.

What you are looking at is a rebuild. We built and ran this marketplace once already, audited it line by line, and started over. The full story is on the story page. This page tracks the rebuild.

01

The build, counted

As of 2026-08-01. Counted from the generated status board — re-derived at every publish. Never estimated, never animated up from zero.

  • 7 / 18build stages closedFoundations, accounts, the core marketplace, the money engine, the web foundation, the design system, the component library.
  • 62 / 145phases completeEach phase ends with a closing step that proves the phase's central claim — permanently.
  • 304 / 649planned steps doneEvery step carries a written definition of done.
  • 52automated checks on every change38 on the backend, 14 on the web platform. All merge-blocking, all machine-run.

These numbers are rendered into the page as static text at publish time. Read this page without JavaScript and you get the same numbers.

02

How we build

Eight practices, each with the guarantee it buys. Plain language here; the technical record behind every claim lives in the plan.

  1. 01

    Nothing merges without passing 52 automated checks.

    Every proposed change must clear 52 machine-run checks — 38 on the backend, 14 on the web platform — before it can join the main codebase, and the list is enforced at the organization level, not by convention. Some are standard hygiene: secret scanning, dependency vulnerability scanning, race testing, a test-coverage floor. Thirty-one are business-rule checks written for this platform alone: one proves money always balances to the kuruş, one proves a repeated payment request can never charge twice, one proves no query can read another company's data, one proves personal data never reaches a log line. The guarantee: a defect in a rule this platform depends on cannot silently ship. The build refuses.

  2. 02

    Four independent AI reviewers examine every slice — and their record is public.

    Security, correctness, API contract, privacy: four separate read-only reviewers with different mandates examine each unit of work before it is proposed for merge. 443 review passes to date, producing 2,650 findings — 58 critical, 916 warnings, 1,676 suggestions. Every finding with a code action attached was applied before merge and written into the permanent record with the reasoning. The reviewers cannot edit code; they can only read and report. The guarantee: no change ships on one person's judgement, and every issue ever raised stays auditable years later.

  3. 03

    The AI is never allowed the last word.

    Most teams get this backwards. Machine review is fast but non-deterministic, so we hold it to advisory only — the authoritative wall is always the deterministic test suite at the merge boundary. That is not a policy memo; it is enforced in code. A test scans the merge rules and fails the build if any AI-named check ever appears among the required ones. For money and personal data, a human-written, deterministic test is always the gate. The guarantee: AI accelerates the work. It never certifies it.

  4. 04

    The safety checks test themselves.

    Every custom business-rule check plants known violations into the codebase on each run, confirms it catches all of them by name, then restores the code byte-for-byte. The sector gate plants seven violations per execution; the data-isolation check carries fifteen must-fail cases. This exists because a check that quietly passes everything is worse than no check at all. The guarantee: a safety check that has stopped working is detected the same day — not the day it was needed.

  5. 05

    The interface between systems cannot drift.

    The platform's public API is a single machine-readable contract — 346 operations. Every merge regenerates the client code from it and fails if the result differs by one character, and a breaking-change detector rejects any modification that would break an existing client. The 108 background event types get the same treatment: each carries a frozen sample message, and a test compares the exact bytes a live producer emits against that sample. The guarantee: a backend change can never silently break an app in a customer's hands.

  6. 06

    Money and personal data follow structural rules, not careful coding.

    Amounts are stored as whole currency units — the code physically cannot express a rounding-prone decimal, and a compiler-level check enforces it. The accounting ledger is append-only and must balance at commit: an entry that does not sum to zero is rejected whole, so money can never half-move. Verified business documents are immutable — not by policy, but because the database refuses the update, including from us. Personal data is encrypted per record with a key that can be destroyed, which makes a deletion request provable. The guarantee: the most expensive failure modes are structurally unavailable, not tested-for after the fact.

  7. 07

    Design quality is a merge requirement, not a meeting.

    Every screen is photographed automatically at three widths — phone, tablet, desktop — in light and dark themes, in left-to-right and right-to-left languages, and compared pixel-for-pixel against 2,822 approved reference images. A change that shifts anything unintended, or that produces horizontal scrolling on a 375-pixel phone, fails the build. Separately, an accessibility engine holds every component to the WCAG 2.2 AA standard, and a lint wall rejects any hand-typed color, spacing or shadow value not drawn from the shared design tokens. The guarantee: the product is verified on a phone, in dark mode, and in Arabic — on every change, not by sampling.

  8. 08

    Every phase closes with proof, and the proof is permanent.

    The plan is 649 numbered steps, each with a written definition of done, and every phase ends with a closing step whose only job is to prove the phase's central claim in a way that keeps holding. When we added a second industry to the platform, the closing step shipped a permanent check that scans the engine, the database and the module tree for any code special-cased to that industry — proving the claim "this vertical needed zero engine code" and preventing it from ever becoming false. The guarantee: architectural promises are converted into automated tests on the day they are made.

03

Build log

Dated entries, newest first. Adding an entry here is itself a tracked change in the repository — like everything else we ship.

  1. Discipline

    2,822 reference screenshots — and the bookkeeping of blast radius

    Every visual change on the web platform is now compared against 2,822 approved reference screenshots: every screen at three widths, in light and dark themes, left-to-right and right-to-left. The number matters less than the bookkeeping. Each change's record states how many pictures changed and how many did not. When one supplier flow grew its reference set from 136 to 220 screens, the record notes that not one unrelated picture changed. That is the point — we measure blast radius, not just pass or fail.

  2. Milestone

    The money engine is closed

    Stage 3 closed: the double-entry ledger, payments, search-and-matching, and the manufacturing chain — tech packs, the sample approval gate, capacity booking, quality inspections — are built, tested and merged. Escrow is an accounting state on an append-only ledger; balances are always derived; corrections are reversing entries. At close, all 92 event types then declared were byte-compared against their frozen samples: zero drift across the entire range. Real money stays switched off until our payment counsel, CPA and payment provider sign off — that gate blocks go-live, never the build.

  3. Milestone

    Component library certified complete

    Stage 8 closed: the shared component library that the buyer and supplier apps are assembled from is complete. Every component renders across each interaction state, in light and dark themes, in left-to-right and right-to-left languages — and every rendering is pinned as an approved reference image. Accessibility is checked against WCAG 2.2 AA on every build, and a lint wall rejects any color, spacing or shadow not drawn from the shared design tokens. From here on, product screens are assembled from certified parts. A screen cannot ship a color the system does not define.

Follow the build

One email when something worth reporting closes. Dated, counted, no marketing gloss. Double opt-in; unsubscribe any time.