<- All cases

Doveryai case

Doveryai (formerly DD Phones) sells new devices with a warranty. We built the company a platform from scratch: a customer storefront, a B2B portal for partners, an admin console, service centers for device repair, and courier delivery.

Context

The business had outgrown third-party listing sites and someone else's CRM: stock, partners, orders, delivery, and repairs lived in different places and never joined into one process. They needed their own platform, where a partner registers an item, an operator checks it, a buyer sees a correct offer, a courier delivers the order, and a service center takes the repair — one chain, with statuses and history.

What we built

  • The customer marketplace: catalog, product page, checkout.
  • The B2B portal: a partner registers one exact physical device and sends it to the marketplace.
  • The admin console: operators check items, work orders, and the state of the catalog.
  • Service centers: intake for repairs and status-driven work tracking.
  • Courier delivery: routes and delivery statuses for orders.
  • Platform infrastructure: customer accounts, payments, and the loyalty program.

How the platform works

An item's path from partner to buyer

The platform is assembled from separate services, but for the business it is one chain: an item is registered once and then moves through statuses without losing its history.

Step 1

A partner registers an item

In the B2B portal a partner creates a record for one exact physical device, not an abstract catalog position.

Step 2

An operator checks it

In the admin console an operator reviews the item and decides whether it is ready to publish. Questionable items never reach the storefront.

Step 3

The item reaches the marketplace

A checked item appears in the customer catalog with an accurate condition and price.

Step 4

A buyer places an order

The storefront carries the buyer from product page to order; accounts, payments, and courier delivery live in separate services.

Step 5

A service center takes the repair

The post-sale side is closed inside the same platform: devices are taken in for repair and the work is tracked by status.

What this gave: stock, partner, order, delivery, and repair stopped living in separate systems. One chain, one set of statuses, one history — with no manual reconciliation between platforms.

Scale

~800,000

lines of code in the platform today

20-30%

written by our system: the marketplace and CRM core, still running today

2 weeks

of non-stop autonomous work by the system on that core

What is running now

How it was built

Two weeks of non-stop autonomous work. In March-May 2026 none of our IDE competitors could do that: neither Claude Code nor Codex held a long run — they lasted a session, not two weeks. Our system took a product goal and spent that whole time writing the marketplace and CRM core for Doveryai. That code is still in production — roughly 20-30% of today's codebase. People wrote and rewrote the rest.

Now the honest part. After the autonomous run it took another two months of human work. The code ran, but it was hard to maintain: the system wrote excessive test coverage, and a single change dragged several test fixes with it. While you are changing markup, that is tolerable. When business logic changes, it hurts.

From a business standpoint the result is debatable: two months of manual follow-up ate part of the gain. For an early-stage startup it is acceptable — the platform exists and it works.

The main lesson went straight into the product. That run predates the /goal command: an operator could not yet hand the system a global goal that is held across an entire long run and that every piece of work is checked against. Without that anchor the system could not answer "is this even needed?" — so it hedged with tests. /goal exists as a direct consequence of this case.

Where it is now

The Doveryai platform runs in production and keeps growing. Every system linked above is live.