Claude построил мой бизнес с НУЛЯ до МИЛЛИОНА рублей

Business outcome (what changed)

• Took an existing codebase (“plot code”) from a previous project and shipped a new marketplace analytics/ad service in 58 days.
• Reported early commercial results:
  • Revenue (total generated): 1,717,000 RUB (turnover mentioned as ~1.7M shortly after promotion)
  • After launch week/promo: earned ~1.7M RUB turnover in the first week after promotion ended
  • Users: 1,573 users (current at the time of the talk)
  • MRR: 543,000 RUB
  • Projected/aspiration: hoping it will reach 2M (turnover referenced around end of month / the 26th)

Why the prior team effort failed (diagnosis)

• For ~2 years with a team of five, the service didn’t reach target economics:
  • Never earned even half a million RUB net per month
  • Had users, but lacked “killer features” to drive retention and word-of-mouth
• Competitive mismatch: couldn’t out-iterate larger marketplace incumbents (e.g., “Ozon was faster every time”)
• Operational bottleneck: when the marketplace data source (Ozon) lagged, the service lagged too—hurting reliability
• Management/strategy issue: even with developers, they “couldn’t manage to do any function properly,” implying weak execution cadence and product iteration

Execution playbook used to win (solo shipping + AI development loop)

Rapid productization from an existing foundation

• Reused architecture/code from a prior self-built “wipe-coding” app into the new product
• Goal: avoid rebuilding basic flows (login/registration) and maximize velocity

Ultra-fast deployment loop

• Feb 23: first deployment attempt caused repeated crashes/redeploys
• ~27 fixes/comments were applied to get the Docker container running
• Security/scaling limits were treated as manageable because AI helped implement “real” constraints automatically

MVP focused on adoption (not paid trial)

• MVP = a free browser extension that installs organically
• Paid capabilities were added later
• Free layer was optimized for volume growth and habit formation

Product + unit economics design (what exactly was built)

Core value proposition

• Marketplace sellers had analytics scattered across multiple reports (e.g., 10 separate Ozon reports)
• The service:
  • Pulls data from the store
  • Consolidates it into smart dashboards and customizable analytics
  • Saves “hours/day” versus Excel
• Addressed an earlier limitation narrative:
  • Claims that some data required premium access were refuted
  • The same data could be downloaded, implying earlier issues were implementation-related—not true product constraints

Free extension concept (adoption engine)

• Extension lets sellers download and add unit economics for any product from the marketplace
• Admin-configurable advertising inputs; seller enters:
  • product link
  • cost price / unit inputs (example: 0.1 L volume)
• Output:
  • auto-calculated expenses
  • net profit / profitability per product
• Strategy: keep the extension completely free initially to drive installs and trust

KPIs & targets mentioned (with timeline)

Acquisition / usage

• March 5 (launch of extension): 314 installations on day 1
• Early distribution channel:
  • Used a Telegram subscription CTA for organic installs, later turned off due to Telegram issues in Russia
• Current/day rate (approx.):
  • ~20 installations/day (plus additional registrations inside the app)

Commercial / payment performance (explicit figures)

• Total payment attempts (entire period): 171 unsuccessful payments
• Abandoned carts: 42%
  • 34% due to technical problems
  • 22% due to payment/card/payment-method limit exceeded
• Sales timeline:
  • Apr 14 (evening): tariffs published
  • Apr 15: payments began (initially card payments)
  • Apr 15–20: peak example
    • Apr 20 peak: 340,000 RUB (card payments only)
    • Revenue from OZON bank: 700,000 RUB (reported alongside card revenue)
• Pricing/payment summary:
  • MRR: 543,000 RUB
  • Average subscription bill: 4,216 RUB
  • Revenue: ~1.7M RUB around the first month window cited

Reliability / ops costs (developer effort proxy)

• AI infra/token usage costs:
  • March 12: ran out of $200/month Claude subscription limit
  • Additional tokens: $100 for 5 hours
  • Total AI spend during that period: ~$500 (plus other expenses later)

Marketing & Go-to-Market (GTM) decisions that mattered

Channel strategy

• Primarily organic via his own marketplace niche audience (YouTube/TG)
• Promotion mechanics:
  • extension installed free for a period
  • updates posted to his personal channel (“broadcast each service update”)
• Reported reach:
  • 1,000 views used for promotion (as stated)

Pricing as core marketing (conversion + trust)

• Tariffs based on seller turnover:
  • Free tier for sellers up to 100,000 RUB turnover
  • Paid subscriptions: 4,000–7,000 RUB
  • Annual discount framed as the most important marketing decision:
    • “buying an annual plan 50% cheaper”
• Habit-building funnel:
  • Start free when turnover is small → become habitual → upgrade as store grows
• Upsell edge case:
  • Some users wanted higher plans immediately due to anticipated turnover growth (to avoid losing annual discount)
  • Required admin-panel flexibility to allow changing higher-rate offerings during signup

Crisis management & product resilience (execution under failure)

Major reliability incident

• Apr 4, 2:00 AM: upload errors observed; assumed AI broke things
• ~11:00 AM: root cause confirmed: Ozon servers crashed
• Response:
  • communicated to users that the service wasn’t working
  • to maintain output during source outages, changed the pipeline:
    • task code to use an alternative export/data acquisition method
• Turnaround:
  • new method appeared in ~5 hours
  • service continued while the primary Ozon method failed
• Strategic takeaway: AI-based iteration cycle outpaced team/programmer iteration time

Payment system incidents

• Apr 15: autopayment check didn’t run → payments didn’t start at first; fixed in ~1 hour
• Apr 16: payments blocked for one day by “YooKassa”
  • Mitigation: proactive, personal outreach to users to preserve trust/loyalty

Security / stress testing

• Ongoing attacks/attempts to stress payment/data:
  • “hacking payment system” / “flood database”
• Claim:
  • rapid bug fixes + stress testing closed holes before user impact
• Operational benefit:
  • stability testing improved security posture

Concrete results vs prior baseline (comparison narrative)

• Prior team product:
  • launched paid version after ~8 months
  • first month revenue only “several hundred thousand”
• New solo product:
  • shipped faster
  • early revenue started immediately after promo period and first paid day(s)
  • currently has more paid subscribers than the earlier team-based service

Frameworks / playbooks explicitly implied (bullet summary)

• Adoption MVP (free extension) + paid upgrade later
• Unit economics embedded into the workflow
• Pricing segmented by customer turnover
• Habit-building funnel
• Reliability-first data abstraction
  • If primary exporter fails → switch to an alternate export method
• Rapid incident response loop
  • Diagnose → isolate external dependency failure → hot-swap method in hours

Presenters / sources

• Roma Raid (main presenter)