DEV Community: Grek Creator

How I Built a $58K GMV Yacht Marketplace and a MedTech AI in 6 Weeks: An AI-Augmented Architecture Deep Dive

Grek Creator — Sun, 08 Mar 2026 22:11:24 +0000

The term "vibecoder" is often used as an insult, implying a lack of fundamental knowledge. However, after shipping three production-grade systems in the last six months—one hitting $58,000 GMV in 6 weeks and another cutting clinic no-shows by 61%—I have realized that AI-augmented engineering is about amplifying architectural judgment, not cutting corners.

If your architecture is weak, AI simply helps you build broken systems faster. Here is the "Bespoke Engineering" framework I used to deliver team-level output as a solo Product Engineer.

The Technical Stack

Backend: Python 3.12, FastAPI, aiogram 3.4.
Frontend/Mobile: React 18 & React Native (Expo 50) via Turborepo monorepo.
Database: PostgreSQL (pgcrypto AES-256 for medical data) & Redis for distributed locking.
Infrastructure: AWS (ECS Fargate, RDS) and Selectel (for RU-localized data).
AI Pipeline: 3-tier Hybrid (Keyword Router → RAG → LLM).

Challenge 1: The "Double-Booking" Prevention (FinTech)

In the Dubai Yacht Marketplace project, the critical risk was concurrent bookings—two users attempting to pay for the same sunset cruise simultaneously.

The Solution: I implemented a Redis SET NX distributed lock.
When a user initiates checkout, the system creates a temporary 15-minute lock on that specific time slot. If the lock fails, the user is notified immediately before entering card details.

Outcome: 312 trips completed with zero double-bookings.

Challenge 2: 152-FZ Compliance (MedTech)

Medical data in Russia is a "special category" requiring strict in-region localization and encryption.

The Compliance Stack:

pgcrypto AES-256: Encrypting sensitive patient data directly in the database.
SHA-256 Hash Search: Searching via indexed hashes to maintain API latency under 50ms without full table decryption.
GigaChat API: Utilizing Sberbank's LLM to ensure no data ever leaves Russian territory.

Outcome: A legally audited system that recovered +$7,200/month in clinic revenue.

The 3-Tier Hybrid AI Architecture

LLMs are often slow and expensive. To process 95% of requests instantly, I utilize this funnel:

Tier 1: Keyword Router (0ms): 94-154 regex patterns for common intents. Cost: $0.
Tier 2: RAG + Cache (~100ms): ChromaDB + rubert-tiny2 for local embeddings to handle FAQs.
Tier 3: LLM Fallback (2-6s): Only complex, novel queries hit the LLM (OpenAI or GigaChat).

The Solo Engineer Advantage

Using AI-augmented workflows allowed me to share ~35% of code between Web and Mobile via Turborepo. I did not spend weeks on boilerplate; I spent them on Escrow logic, 152-FZ security, and Arabic RTL support.

The Core Lesson: Clients do not pay for code. They pay for ROI.

Yacht Marketplace: $58K GMV.
Medical Clinic: -61% no-shows.

Connect for High-Stakes Projects

I am currently available for architectural consulting and AI-automation projects starting from $3,000.

Website: grekcreator.com
Live Demo: app.grekcreator.com

Hi, I'm Grek — Full-Stack Python Developer & AI Engineer

Grek Creator — Wed, 04 Mar 2026 07:14:05 +0000

Short version: I build production-grade systems that solve business problems. Long version below.

Hey dev.to 👋

I'm Dmitrii Iakovlev, operating under the brand Grek Creator. I'm a Full-Stack Python Developer and AI Integration Engineer based in Saint Petersburg, working remotely with clients in UAE, EU, and Russia.

What I Actually Do

I don't just write code. I build systems that:

Reduce no-show rates from 21% to 8.1% (medical clinic)
Generate $58K GMV in first 6 weeks (Dubai yacht marketplace)
Compress 500–600 hours of development into 2 weeks using AI-augmented workflows (dating platform)

My stack: Python 3.12, FastAPI, aiogram 3, React 18, PostgreSQL, Redis, Docker, AWS.

But the tools are secondary. What matters is the outcome: production-grade reliability, measurable business impact, and compliance where it counts (152-FZ, GDPR, healthcare regulations).

Why Arabic RTL Matters (And Why I Built It Myself)

One thing I'm proud of: my portfolio site grekcreator.com supports RU / EN / Arabic RTL across all pages — including the PWA version at app.grekcreator.com.

Why? Because if I'm targeting UAE clients, I need to speak their language — literally.

# utils/i18n.py
def is_rtl_language(lang_code: str) -> bool:
    return lang_code in {"ar", "fa", "he", "ur"}

// React component — dynamic dir attribute
function PageLayout({ children, lang }) {
  return (
    <div dir={is_rtl_language(lang) ? "rtl" : "ltr"} className={`lang-${lang}`}>
      {children}
    </div>
  );
}

It's not just translation. It's layout mirroring, form validation adjustments, date formatting, and cultural UX considerations. And yes — I built it myself, because off-the-shelf solutions didn't cut it for my use case.

If you need a full website or PWA with Arabic RTL support — I've done it, I can do it again.

How I Work

Remote-first, 40+ hours/week, flexible across UAE/EU/US timezones
Fixed-price contracts with milestone-based delivery (no surprise invoices)
NDA-compliant — I respect client confidentiality
Production-grade code: type hints, error handling, comprehensive logging, Docker Compose deploys

I'm not a "code monkey". I'm a partner who thinks about your business metrics, not just GitHub stars.

What's on My Radar Right Now

gc-pwa Phase 2 — Frontend for my live AI demo at app.grekcreator.com
Arabic RTL expansion — Adding full RTL support to more projects
Local LLM optimization — Making Qwen2.5-3B run faster on CPU for cost-sensitive clients

Let's Connect

If you're building something interesting — especially in UAE, healthcare, or AI automation — I'd love to hear about it.

🌐 grekcreator.com — Portfolio (EN/RU/AR RTL)

🧪 app.grekcreator.com — Live AI demo (PWA)

📧 hello@grekcreator.com

P.S. If you found this useful, follow me for more technical deep-dives on AI architecture, compliance engineering, and shipping fast without breaking things.

3 Production Cases: How I Built AI Systems That Actually Make Money

Grek Creator — Wed, 04 Mar 2026 06:52:11 +0000

No theory. No "in this article we'll learn". Just 3 shipped projects, real code snippets, and metrics that matter.

I'm a Full-Stack Python Developer who ships production systems. Over the last 6 months, I delivered 3 projects across healthcare, luxury tourism, and social tech — all under NDA, all with measurable business results.

Here's what I built, how I built it, and the code patterns that made it work.

CASE 1: DUBAI YACHT MARKETPLACE ($58K GMV IN 6 WEEKS)

The problem: Dubai's yacht rental market ran on WhatsApp and cash. No transparency, no price guarantees, no protection for either side.

The solution: A two-sided marketplace with verified owners, Stripe escrow, Arabic RTL, and iOS+Android+Web from a single Turborepo monorepo.

Key Engineering Challenge: Zero Double-Bookings

Race conditions are brutal in booking systems. Two users clicking "Reserve" on the same time slot simultaneously — who wins?

# services/booking_service.py
import redis
from contextlib import contextmanager
from datetime import datetime

class BookingService:
    def __init__(self, redis_client: redis.Redis):
        self.redis = redis_client

    @contextmanager
    def slot_lock(self, yacht_id: int, slot_start: datetime):
        """Distributed lock via Redis SET NX — prevents double-booking"""
        lock_key = f"booking:lock:{yacht_id}:{slot_start.timestamp()}"
        acquired = self.redis.set(lock_key, "1", nx=True, ex=900)  # 15 min TTL

        if not acquired:
            raise BookingConflictError("Slot already reserved")

        try:
            yield
        finally:
            # Only delete if we still hold the lock
            if self.redis.get(lock_key) == "1":
                self.redis.delete(lock_key)

    async def create_booking(
        self,
        user_id: int,
        yacht_id: int,
        slot: datetime
    ) -> Booking:
        with self.slot_lock(yacht_id, slot):
            # Double-check availability in DB (defense in depth)
            if not await self._is_slot_available(yacht_id, slot):
                raise BookingConflictError("Slot taken during lock acquisition")

            async with db.transaction():
                booking = await Booking.create(
                    user_id=user_id,
                    yacht_id=yacht_id,
                    slot_start=slot,
                    status="PENDING"
                )
                # Reserve slot in availability cache
                await self.redis.setex(
                    f"availability:{yacht_id}:{slot.timestamp()}",
                    900,
                    "reserved"
                )
            return booking

Result: Zero double-bookings in production across 312 completed trips.

Stripe Connect Escrow: 7 Financial Edge Cases

Marketplace payments are messy. No-shows, weather cancellations, disputes, partial refunds — each requires different logic.

# services/payment_service.py
import stripe

async def handle_booking_completion(self, booking_id: int):
    """Capture payment 24h after trip ends — escrow logic"""
    booking = await Booking.get(booking_id)

    # Only capture if no dispute opened
    if booking.dispute_status != "OPEN":
        await stripe.PaymentIntent.capture(
            booking.stripe_payment_intent_id,
            amount_to_capture=booking.amount_captured
        )

        # Split payout: 88% owner, 12% platform
        await stripe.Transfer.create(
            amount=int(booking.amount_captured * 0.88),
            currency="aed",
            destination=booking.owner_stripe_account_id,
            source_transaction=booking.stripe_payment_intent_id
        )

Key insight: Don't trust webhooks alone. Always double-check via API before state transitions.

Tech Stack

Backend: Python 3.12, FastAPI, Celery 5 + Redis, SQLAlchemy 2.0 async
Frontend: React 18 + TypeScript + Zustand + Tailwind + Mapbox GL JS
Mobile: React Native 0.73 + Expo SDK 50 (Turborepo monorepo)
Infra: AWS ECS Fargate, RDS Multi-AZ, ElastiCache Redis, Terraform
Payments: Stripe Connect Marketplace (escrow, split payments, disputes)
KYC: Sumsub API (UAE-specific: DCCA license, Emirates ID)
AI: GPT-4o-mini Route Advisor (EN/AR), ML Price Recommendation

Results (First 6 Weeks Production)

Metric	Value
GMV	$58,000 USD (214,000 AED)
Completed trips	312 · 97.4% success rate
Double-bookings	0 (Redis distributed lock)
Uptime	99.7% · API avg 94ms p50
Mobile app rating	4.6⭐ App Store · 4.5⭐ Google Play
Active yachts	47 · 38 verified captains

CASE 2: MOSCOW CLINIC AI (21% → 8.1% NO-SHOW RATE)

The problem: Private clinic losing 21% of appointments to no-shows. Admins spending 5–6 hours/day on manual scheduling.

The solution: Telegram bot + PWA with AI symptom triage, 152-FZ compliance, and 1C:Medicine integration.

152-FZ Compliance: Encrypting Personal Data Without Killing Performance

Russian law requires encryption of personal data. But encrypting every field makes search impossible.

# models/patient.py
from sqlalchemy import Column, Integer, String
from sqlalchemy.ext.hybrid import hybrid_property
import hashlib

class Patient(Base):
    __tablename__ = "patients"

    id = Column(Integer, primary_key=True)
    # Encrypted fields (pgcrypto AES-256)
    _full_name = Column("full_name", String(255))
    _phone = Column("phone", String(20))
    # Hash fields for search (SHA-256, indexed)
    phone_hash = Column(String(64), index=True)

    @hybrid_property
    def phone(self) -> str:
        """Decrypt on read — only when needed"""
        if not self._phone:
            return None
        return pg_decrypt(self._phone, get_encryption_key())

    @phone.setter
    def phone(self, value: str):
        """Encrypt on write + update hash for search"""
        self._phone = pg_encrypt(value, get_encryption_key())
        self.phone_hash = hashlib.sha256(value.encode()).hexdigest()

    @classmethod
    async def find_by_phone(cls, phone: str):
        """Search via hash — no decryption needed"""
        phone_hash = hashlib.sha256(phone.encode()).hexdigest()
        return await cls.query.filter(cls.phone_hash == phone_hash).first()

Result: Search latency p95 = 47ms (acceptable), full 152-FZ compliance, zero data leaks.

Circuit Breaker for 1C:Medicine Integration

External APIs fail. Your system shouldn't.

# services/mis_client.py
from enum import Enum
import time

class CircuitState(Enum):
    CLOSED = "closed"      # Normal operation
    OPEN = "open"          # Failing — reject requests
    HALF_OPEN = "half_open"  # Testing recovery

class MISClient:
    def __init__(self, base_url: str):
        self.base_url = base_url
        self.state = CircuitState.CLOSED
        self.failure_count = 0
        self.last_failure_time = None

    async def call(self, endpoint: str, **kwargs):
        if self.state == CircuitState.OPEN:
            # Check if recovery window passed
            if time.time() - self.last_failure_time > 300:
                self.state = CircuitState.HALF_OPEN
            else:
                raise MISUnavailableError("Try phone booking")

        try:
            result = await self._make_request(endpoint, **kwargs)
            self._on_success()
            return result
        except Exception as e:
            self._on_failure()
            raise

    def _on_success(self):
        self.failure_count = 0
        self.state = CircuitState.CLOSED

    def _on_failure(self):
        self.failure_count += 1
        self.last_failure_time = time.time()
        if self.failure_count >= 3:
            self.state = CircuitState.OPEN

Result: Graceful degradation — when MIS fails, bot offers phone booking instead of crashing.

3-Tier AI Triage Pipeline

# services/triage_service.py
class TriageService:
    async def triage(self, symptoms: str) -> str:
        # L1: Keyword Router (0ms, 78% of requests)
        if route := self.keyword_router.match(symptoms):
            return route

        # L2: RAG + Cache (~100ms, 17% of requests)
        if response := await self.rag_service.query(symptoms):
            return response

        # L3: GigaChat API (2–6s, 5% of requests)
        return await self.llm.generate(symptoms)

Result: 89.7% correct specialist routing, data stays in Russia (GigaChat API).

Tech Stack

Bot: Python 3.12, aiogram 3.4 async, APScheduler 3.10 (12 jobs)
Backend: FastAPI + SQLAlchemy 2.0 async, pgcrypto AES-256
AI: Keyword Router (94 patterns) → ChromaDB RAG + rubert-tiny2 → GigaChat API
PWA: React 18 + TypeScript + Vite, Service Worker offline cache, Web Push API
Integration: 1C:Medicine REST API + circuit breaker, 1C:Buhgalteriya export
Infra: Selectel VPS (Saint Petersburg, RF), LUKS full disk encryption

Results (First 5 Weeks Production)

Metric	Value
No-show rate	21% → 8.1% (–61%)
Recovered revenue	+660,000 ₽/month (+$7,200/mo)
Online bookings share	74% (was 0%)
Registered patients	1,134 · 1,847 appointments
AI triage accuracy	89.7% correct specialist routing
PWA installs	312 (Add to Home Screen)

CASE 3: AI DATING PLATFORM (95% REQUESTS INSTANT)

The problem: Scientific matchmaking needs AI for conversation, but LLM latency kills UX.

The solution: 3-tier hybrid architecture with local LLM, RAG, and TTS for voice messages.

The Pre-Router: Solving Callback Conflicts in aiogram

When you have 9+ routers handling callbacks, conflicts happen.

# routers/pre_router.py
from aiogram import Router
from aiogram.types import CallbackQuery

class PreRouter(Router):
    """Routes callbacks before they hit specific routers — prevents conflicts"""

    def __init__(self):
        super().__init__()
        # Pattern-based routing: callback data starts with prefix
        self.patterns = {
            "somatype_": self._route_somatype,
            "pc_": self._route_pc,
            "meeting_": self._route_meeting,
            "payment_": self._route_payment,
        }

    async def process_callback(self, callback: CallbackQuery):
        data = callback.data
        for prefix, handler in self.patterns.items():
            if data.startswith(prefix):
                return await handler(callback)
        # Fallback: let other routers try
        return await super().process_callback(callback)

Result: Clean separation of concerns, zero callback conflicts, easy to add new features.

Hybrid AI: 95% Instant, 5% LLM

# services/hybrid_ai.py
import asyncio
import hashlib
from llama_cpp import Llama

class HybridAIAgent:
    def __init__(self):
        self.keyword_router = KeywordRouter()
        self.cache = ResponseCache(max_size=200)
        self.llm = Llama(model_path="Qwen2.5-3B-Instruct-Q4_K_M")

    async def respond(self, user_id: int, text: str) -> str:
        # Tier 1: Keyword Router (0ms)
        if response := await self.keyword_router.route(text):
            return response

        # Tier 2: Cache (0.001s)
        cache_key = self._normalize(text)
        if cached := await self.cache.get(cache_key):
            return cached

        # Tier 3: LLM + RAG (6–19s, but only 5% of requests)
        rag_context = await self.rag_service.get_relevant_chunks(text)
        prompt = self._build_prompt(text, rag_context)

        response = await asyncio.wait_for(
            asyncio.to_thread(self.llm.generate, prompt),
            timeout=15.0
        )

        # Cache successful responses
        await self.cache.set(cache_key, response, ttl=3600)
        return response

    def _normalize(self, text: str) -> str:
        """MD5-normalize for cache: identical questions = same key"""
        normalized = re.sub(r"[^\w\s]", "", text.lower().strip())
        return hashlib.md5(normalized.encode()).hexdigest()

Result: 95% of user messages get instant responses. The 5% that need LLM get thoughtful answers — without burning API credits.

Tech Stack

Bot: Python 3.11, aiogram 3 async, FSM state machines
Web: FastAPI + Jinja2 + vanilla JS 15KB (somatype test)
AI: 3-tier Hybrid (L1: 154 patterns → L2: LRU Cache MD5 → L3: Qwen2.5-3B + ChromaDB RAG)
TTS: Long AI responses synthesized as voice messages
DB: PostgreSQL 16 native, RPC find_match() — full matching algorithm in database
Payments: Alfa-Bank REST API (HMAC webhook verification, idempotency)
Infra: Beget VPS, systemd services, Nginx SSL, 24 security measures

Technical Metrics

Metric	Value
AI router coverage	95% requests served instantly (no LLM)
Error monitoring	66 error codes · 12 domains · 627-line catalog
Database	12 tables · 16 FKs · 39 indexes · 5 triggers · 7 RPCs
Scheduler	11 APScheduler jobs · gender-differentiated check-ins
Security	24 hardening measures · 152-FZ compliant

WHAT'S NEXT?

I'm currently available for new projects — 40+ hours/week, remote, UAE/EU/US timezones.

What I build:

AI-powered automation systems (chatbots, triage, routing)
Cross-platform marketplaces (iOS + Android + Web from monorepo)
Enterprise backend with compliance (152-FZ, GDPR, healthcare, fintech)

Minimum project size: $3,000 USD

Optimal range: $5,000–15,000 USD per project

If you're a founder, CTO, or business owner looking to ship a production-grade system in 6–8 weeks — let's talk.

📧 hello@grekcreator.com

🌐 grekcreator.com

💬 Telegram: @greknamed

All projects delivered under NDA. Case study details verified and available on request.

Why I Became a 'Vibecoder' (And Why It's Not Lazy Coding)

Grek Creator — Tue, 03 Mar 2026 22:39:35 +0000

"You just let AI write your code?" — Yes. And here's why that makes me more of an engineer, not less.

The term "vibecoder" gets thrown around as an insult lately. It implies you're lazy, that you don't understand what's happening under the hood, that you're just prompting your way to technical debt.

I'm here to tell you something different: vibecoding isn't about replacing engineering. It's about removing friction between idea and revenue.

What Changed in Late 2024

For years, I built REST APIs the traditional way: Flask/Django, manual CRUD, boilerplate authentication, repetitive validation logic. Solid work. Reliable. Slow.

Then I hit a wall: a client needed a Telegram bot with AI symptom triage, 152-FZ compliance, PWA fallback, and 1C:Medicine integration — in 3 months.

Traditional approach: ~800 hours. Deadline: impossible.

So I adapted. I built workflows. I learned where AI accelerates and where human judgment is non-negotiable.

Result: 420 hours. Production launch. Zero compliance violations.

The 3-Tier Hybrid Pattern (With Code)

Here's the architecture I now use for every AI-powered system. It's not sexy, but it works in production.

Tier 1: Keyword Router (0ms, ~78–95% of requests)

# routers/keyword_router.py
import re
from typing import Optional, Callable

class KeywordRouter:
    def __init__(self):
        self.routes: dict[str, tuple[re.Pattern, Callable]] = {
            "symptom_headache": (
                re.compile(r"(голова болит|мигрень|цефалгия)", re.I),
                self._route_neurology
            ),
            "booking_cancel": (
                re.compile(r"(отменить запись|отмена|перенести)", re.I),
                self._route_appointment
            ),
        }

    def route(self, text: str) -> Optional[str]:
        text_norm = text.lower().strip()
        for route_name, (pattern, handler) in self.routes.items():
            if pattern.search(text_norm):
                return handler(text_norm)
        return None

Why this matters: No LLM call. No latency. No API cost. 78% of medical queries and 95% of dating bot conversations are handled here.

Tier 2: RAG + Cache (~100ms, ~17% of requests)

# services/rag_service.py
from chromadb import Client
from sentence_transformers import SentenceTransformer
import hashlib

class RAGService:
    def __init__(self, collection_name: str):
        self.chroma = Client().get_collection(collection_name)
        self.embedder = SentenceTransformer("rubert-tiny2")
        self.cache: dict[str, str] = {}

    def _normalize_key(self, query: str) -> str:
        normalized = re.sub(r"[^\w\s]", "", query.lower().strip())
        return hashlib.md5(normalized.encode()).hexdigest()

    def get_response(self, query: str) -> Optional[str]:
        key = self._normalize_key(query)
        if key in self.cache:
            return self.cache[key]
        query_vec = self.embedder.encode([query])[0]
        results = self.chroma.query(
            query_embeddings=[query_vec.tolist()],
            n_results=3,
            include=["documents"]
        )
        if results["documents"][0]:
            response = self._synthesize(results["documents"][0][0])
            self.cache[key] = response
            return response
        return None

Tier 3: LLM Fallback (2–6s, ~5% of requests)

# services/llm_service.py
import asyncio
from llama_cpp import Llama

class LocalLLM:
    def __init__(self, model_path: str):
        self.llm = Llama(
            model_path=model_path,
            n_ctx=4096,
            n_gpu_layers=0,
            verbose=False
        )

    async def generate(self, prompt: str, timeout: float = 15.0) -> str:
        try:
            return await asyncio.wait_for(
                asyncio.to_thread(self._generate_sync, prompt),
                timeout=timeout
            )
        except asyncio.TimeoutError:
            return "I'm taking too long — let me connect you to a human."

    def _generate_sync(self, prompt: str) -> str:
        output = self.llm(prompt, max_tokens=512, stop=["\n\n"])
        return output["choices"][0]["text"].strip()

Where AI Helps — And Where It Doesn't

AI accelerates:

Boilerplate CRUD endpoints
Regex pattern generation
Documentation drafts
Test data generation
Error message localization

Human judgment is non-negotiable:

Architecture decisions (3-tier vs monolith)
Compliance logic (152-FZ, GDPR, 323-FZ)
Payment flows (idempotency, webhook verification)
Error handling strategy
Business logic edge cases

The Irony: More AI = More Engineering Discipline

The more I used AI, the more I realized: if your architecture is weak, AI helps you build broken systems faster.

So I built guardrails:

No AI-generated code without human review (especially payments/auth)
Architecture first, code second (sketch on paper before prompting)
Test critical paths manually (AI can write tests, but I verify business logic)
Error monitoring from day one (66 error codes catalogued in one project)

Results: Speed Without Sacrificing Reliability

Metric	Traditional	AI-Augmented
Delivery time	8 weeks	3.5 weeks
Boilerplate hours	~300	~40
Production bugs (first month)	12	3
Uptime (first 6 weeks)	98.1%	99.7%

The projects didn't just ship faster — they shipped better, because I spent time on architecture instead of typing @app.post("/users") for the 47th time.

Vibecoding Is a Philosophy, Not a Shortcut

Call it what you want: AI-augmented engineering, high-velocity development, vibecoding. The label doesn't matter. The outcome does.

I'm not here to win arguments on Twitter. I'm here to ship products that make money — with production-grade reliability, compliance, and maintainability.

Built AI-powered systems for healthcare, luxury tourism, and social tech. Portfolio: grekcreator.com

How I reduced medical no-shows from 21% to 8.1% with an AI Telegram bot

Grek Creator — Sun, 01 Mar 2026 18:44:26 +0000

A Moscow medical clinic was losing money every day. 21% of appointments ended in no-shows — patients who booked but never came. Staff spent hours on manual reminder calls. The booking process was 100% phone-based.

They hired me to fix it. Here's what I built and what happened in the first 5 weeks.

The actual business problem

No-shows in medical clinics aren't just annoying — they're expensive. An empty slot that could have been filled is pure revenue loss. At this clinic, 21% no-show rate translated to roughly $7,200/month in lost revenue.

The root causes were straightforward:

Patients forgot appointments (no automated reminders)
Rebooking required a phone call during working hours
Staff had no visibility into who was likely to no-show

Architecture

Bot: Python 3.12 + aiogram 3 (Telegram)
Backend: FastAPI + PostgreSQL 15 + Redis
AI: GigaChat API (Russian language, data stays in Russia — required for medical data under 152-FZ)
Vector search: ChromaDB + rubert-tiny2 embeddings
EHR integration: 1C:Медицина REST API with circuit breaker
Billing integration: 1C:Бухгалтерия OData
Scheduling: APScheduler with 12 jobs
Notifications: React PWA + Web Push
Compliance: 152-FZ (Russian medical data law), AES-256 encryption via pgcrypto, LUKS disk encryption

GigaChat instead of OpenAI was a hard requirement — Russian medical regulations prohibit sending patient data to foreign servers.

The reminder system

The core of the no-show reduction was a multi-touch reminder sequence:

T-48h: "You have an appointment in 2 days. Confirm or reschedule?"
T-24h: "Reminder: tomorrow at 14:00 with Dr. Ivanova. Reply to confirm."
T-2h:  "Your appointment is in 2 hours. We're expecting you."
T+30m: If no-show detected → automatic slot release + waitlist notification

Each message has inline keyboard buttons: Confirm / Reschedule / Cancel. Cancellations automatically trigger waitlist fulfillment.

AI triage

Patients can describe symptoms in free text. The bot uses a RAG pipeline (ChromaDB + rubert-tiny2 + GigaChat) to match symptoms against a curated medical knowledge base and suggest the appropriate specialist.

async def triage_patient(symptom_text: str) -> TriageResult:
    embeddings = await encoder.encode(symptom_text)
    similar_cases = await chroma.query(embeddings, n_results=5)
    prompt = build_triage_prompt(symptom_text, similar_cases)
    response = await gigachat.complete(prompt)
    return parse_triage_result(response)

Accuracy after 5 weeks: 89.7% correct specialist routing (validated against actual doctor assignments).

1C integration headaches

1C:Медицина has a REST API that's... not great. Endpoints time out randomly. The solution was a circuit breaker pattern:

3 consecutive failures → circuit opens, fallback to cached data
30-second cooldown → circuit half-opens, single probe request
Success → circuit closes, normal operation resumes

Without this, a 1C outage would have taken down the entire booking flow.

Compliance (152-FZ)

Russian medical data law is strict:

All patient data must be stored on Russian servers (Selectel VPS)
Encryption at rest required (pgcrypto AES-256 + LUKS)
Audit log for every data access
Data retention and deletion procedures

This added roughly 40 hours to the project but was non-negotiable.

Results after 5 weeks

Metric	Before	After
No-show rate	21%	8.1%
Online bookings	0%	74%
Monthly recovered revenue	—	+$7,200
Patients in system	0	1,134
Total appointments	0	1,847

The clinic recovered the development cost in under 3 weeks.

What I'd do differently

Build the admin panel earlier. Clinic staff needed dashboards from day one — I delivered them in week 3. Earlier delivery would have accelerated adoption.

Stress test the APScheduler jobs. With 12 scheduled jobs running simultaneously at peak hours, there were occasional delays. Moving to Celery Beat for the high-priority reminder jobs would be cleaner at scale.

More granular no-show prediction. The current system sends reminders to everyone equally. A simple ML model scoring no-show probability per patient (based on history, appointment type, day of week) would let you prioritize aggressive reminders on high-risk slots.

Stack summary

Layer	Technology
Bot	Python 3.12, aiogram 3
Backend	FastAPI, APScheduler
Database	PostgreSQL 15 + pgcrypto, Redis
AI	GigaChat API, ChromaDB, rubert-tiny2
Integrations	1C:Медицина, 1C:Бухгалтерия
Frontend	React PWA, Web Push
Infrastructure	Selectel VPS, LUKS, Docker
Compliance	152-FZ

Questions about the architecture, GigaChat integration, or 1C circuit breaker pattern — ask in the comments.

How I built a yacht rental marketplace in Dubai that generated $58K GMV in 6 weeks

Grek Creator — Sun, 01 Mar 2026 18:29:17 +0000

In late 2024 I got a contract to build a full-stack yacht rental marketplace for a Dubai-based client. The requirement was simple on paper: iOS app, Android app, web platform, captain management, real-time availability, payments, KYC verification — and Arabic RTL support throughout.

Budget: $18,500. Timeline: 3.5 months.

Here's what I built, the technical decisions I made, and what happened after launch.

The business problem

Yacht rental in Dubai is a high-trust, high-friction business. Customers want to book online but can't verify if a yacht is actually available. Double-bookings destroy reputation. Captains need a separate workflow. And if you're operating in the UAE, your platform must feel native in Arabic — not just translated, but properly right-to-left.

The client had been running everything through WhatsApp and spreadsheets. They were losing bookings to competitors with actual platforms.

Architecture overview

I chose a monorepo approach with Turborepo:

Backend: Python 3.12 + FastAPI + PostgreSQL 15 + Redis + Celery
Web: React 18 (TypeScript)
Mobile: React Native (iOS + Android from one codebase)
Infrastructure: AWS ECS Fargate + RDS Multi-AZ + ElastiCache + Terraform
Payments: Stripe Connect with escrow logic
KYC: Sumsub (supports UAE Emirates ID and passport)
Maps: Mapbox
Notifications: Firebase FCM
Captain management: Telegram bot (aiogram 3)
AI: GPT-4o-mini Route Advisor + ML price recommendation

The double-booking problem

This was the hardest technical challenge. Yachts can be booked from web, iOS, and Android simultaneously. A naive implementation creates race conditions.

The solution: Redis distributed lock per yacht + time slot. When a user starts checkout, a 10-minute lock is acquired. If payment fails or times out, the lock releases. No database-level conflicts possible.

async def acquire_booking_lock(yacht_id: int, slot: str, ttl: int = 600) -> bool:
    key = f"booking_lock:{yacht_id}:{slot}"
    return await redis.set(key, "1", nx=True, ex=ttl)

Result: 0 double-bookings across 312 trips in production.

Arabic RTL

Most developers treat RTL as an afterthought — flip direction: rtl and call it done. That breaks layouts in subtle ways.

What actually works:

Use CSS logical properties (margin-inline-start instead of margin-left)
Tailwind has RTL variant support — use it from day one, not as a patch
Test on real Arabic content, not placeholder text — Arabic words are longer than their English equivalents and break grids

Stripe Connect escrow

The client wanted funds held until trip completion — not paid directly to yacht owners on booking. This is Stripe Connect's "destination charges" model with manual transfer timing.

The flow: customer pays → funds held in platform account → trip confirmed by captain → automatic transfer to owner's Stripe account within 24h.

Results after 6 weeks in production

$58,000 GMV (214,000 AED) across 312 trips
47 verified yachts, 38 verified captains onboarded
0 double-bookings
99.7% uptime, 94ms average API response
4.6⭐ App Store, 4.5⭐ Google Play

The client broke even on the development cost in week 4.

What I'd do differently

Terraform from day one. I added infrastructure-as-code midway through. Starting with it would have saved a full day of manual AWS configuration.

Separate captain app earlier. Captains ended up needing enough distinct functionality that a dedicated React Native app (not just the Telegram bot) would have been cleaner.

Load test the KYC webhook. Sumsub sends verification results as webhooks. Under load, the queue backed up. Added a dedicated Celery worker for KYC processing in week 2.

Stack summary

Layer	Technology
Backend	Python 3.12, FastAPI, Celery
Database	PostgreSQL 15, Redis
Mobile	React Native (Turborepo)
Web	React 18, TypeScript
Infrastructure	AWS ECS Fargate, RDS, ElastiCache, Terraform
Payments	Stripe Connect
KYC	Sumsub
AI	GPT-4o-mini, custom ML pricing model

If you're building something similar or have questions about any part of this stack — happy to discuss in the comments.