A partner registers an item
In the B2B portal a partner creates a record for one exact physical device, not an abstract catalog position.
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.
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.
How the platform works
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.
In the B2B portal a partner creates a record for one exact physical device, not an abstract catalog position.
In the admin console an operator reviews the item and decides whether it is ready to publish. Questionable items never reach the storefront.
A checked item appears in the customer catalog with an accurate condition and price.
The storefront carries the buyer from product page to order; accounts, payments, and courier delivery live in separate services.
The post-sale side is closed inside the same platform: devices are taken in for repair and the work is tracked by status.
lines of code in the platform today
written by our system: the marketplace and CRM core, still running today
of non-stop autonomous work by the system on that core
Customer-facing storefront for phones and accessories.
doveryai.dodvir.comWholesale orders and partner accounts.
doveryaib2b.dodvir.comCatalog, orders, and operations console.
doveryai-admin.dodvir.com/itemsThe post-sale side: device repair.
service.dodvir.comTwo 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.
The Doveryai platform runs in production and keeps growing. Every system linked above is live.