Перейти к основному содержимому

Development Roadmap — Путь развития платформы от архитектурного baseline к промышленной эксплуатации

Версия: 2.0 (архивная)
Дата архивации: 27.04.2026
Статус: Черновик (архивный, не source of truth)

Архивный документ. Этот документ был активной версией roadmap до 27.04.2026. После публикации правила 00000 (платформа главенствует над поставщиками) и завершения фаз 4–6 каноничной архитектуры (16 новых reference- и operations-документов) старый roadmap содержит несовместимые элементы: Year-1 calendar timeline с привязкой к месяцам и hardcoded MRR-целями, фиксированные revenue projections, customer acquisition tactics с hardcoded датами, market entry strategy с конкретными географическими шагами по месяцам.

Актуальный roadmap: roadmap.md — переработан в чистую stages model на каноничных документах архитектуры.

Текст ниже сохраняется без изменений для исторической справки.

Назначение документа​

Этот документ фиксирует не маркетинговый timeline, не обещание “запуска через 12 месяцев” и не жёсткий staffing-plan.

Его задача — определить правильный порядок развития vitiana-api-platform как реальной промышленной платформы:

  • от уже собранного архитектурного и документного baseline;
  • к управляемому implementation baseline;
  • к ограниченному production-capable запуску;
  • к зрелой эксплуатационной, коммерческой и интеграционной модели.

Этот roadmap должен быть согласован с текущей архитектурной реальностью проекта, а не с ранними ожиданиями первого слоя документации.

Опорные документы​

Что Исправляет Новый Roadmap​

Предыдущая версия roadmap исходила из слишком ранней уверенности в следующих вещах:

  • уже окончательно выбранный технологический стек;
  • уже определённая production-топология;
  • уже стабильный MVP scope;
  • уже понятный fixed team structure;
  • уже обоснованный месячный timeline;
  • уже подтверждённая market-entry модель.

Для текущей зрелости проекта это слишком рано и слишком жёстко.

Новый roadmap строится из другой последовательности:

  1. сначала удержать архитектурный центр платформы;
  2. затем довести reference-layer до состояния непротиворечивого baseline;
  3. затем закрепить execution- and operations-ready модель;
  4. затем определить production-capable implementation baseline;
  5. только после этого переводить платформу в ограниченный управляемый запуск и дальнейшее масштабирование.

Текущий Статус Платформы​

На текущий момент проект уже прошёл важную часть пути, которую нельзя недооценивать.

Уже собран архитектурный и документный baseline:

  • зафиксирован platform core;
  • собрана каноническая доменная модель;
  • описаны tenancy, identity и access boundaries;
  • описана семантика offer, quote, booking;
  • выделен самостоятельный commercial model;
  • выделены partner finance, tenant enablement, API metering и offer integrity as separate controlled domains;
  • выделен самостоятельный post-booking lifecycle;
  • выделен самостоятельный tour builder domain;
  • выделен data governance and matching;
  • синхронизированы основные reference-документы;
  • собран execution-layer по deployment, settlement, observability и release discipline.

Это означает, что roadmap больше не должен начинаться с “сначала придумать архитектуру”.

Теперь правильная отправная точка другая:

архитектурный baseline уже есть, и основной риск сместился в сторону implementation discipline, controlled execution и сохранения связности при переходе от документации к реальной системе.

Главный Принцип Развития​

Платформа должна развиваться по архитектурной оси, уже зафиксированной в Архитектурная основа платформы vitrip.store:

supplier reality
  → normalized and governed canonical model
  → integrity-gated publishable offer state
  → offerable operational state
  → channel-aware commercial interpretation
  → quote as commercial promise
  → booking as transactional commitment
  → post-booking operational reality
  → settlement-relevant downstream financial reality
  → partner clearing and tenant-specific enablement reality
  → tour composition and proposal publication

Roadmap обязан сохранять именно эту ось.

Это означает:

  • нельзя строить реализацию как “просто поиск отелей”;
  • нельзя строить MVP как “UI поверх supplier API”;
  • нельзя преждевременно цементировать инфраструктуру вместо доменных и execution boundaries;
  • нельзя выпускать наружу public или partner surfaces раньше, чем стабилизированы offer, quote, booking, commercial и publication discipline;
  • нельзя считать платформу production-ready до появления settlement, reconciliation, observability и safe release discipline.

Что Этот Roadmap Не Должен Делать​

Этот roadmap не должен:

  • обещать жёсткие месячные сроки без реальной implementation breakdown;
  • фиксировать окончательный stack до завершения implementation-level решений;
  • подменять roadmap hiring-планом;
  • выдавать ранние speculative business numbers за подтверждённый operating baseline;
  • смешивать “архитектурно нужно” и “точно будет в первой поставке”.

Формат Roadmap​

Этот roadmap разбит не по календарю, а по ступеням зрелости.

Это сделано намеренно, потому что для платформы такого типа реальный прогресс должен определяться не количеством прошедших месяцев, а прохождением архитектурных и execution-гейтов.

Каждая стадия ниже содержит:

  • смысл стадии;
  • обязательный результат;
  • ключевые workstreams;
  • gate to exit, без которого нельзя безопасно идти дальше.

Стадия 0. Архитектурный Baseline И Сборка Каркаса​

Смысл стадии​

Собрать минимально непротиворечивый architectural baseline, на котором уже можно проектировать implementation и operational reality, а не спорить о самых базовых сущностях.

Текущий статус​

Эта стадия в основном уже пройдена.

Критически важные результаты уже получены:

  • зафиксирован архитектурный центр платформы;
  • собран второй несущий круг reference-документов;
  • сформирован execution baseline по deployment, settlement, observability и release engineering;
  • верхний narrative-layer уже подтянут к новому каркасу.

Что ещё нужно добить в рамках стадии​

  • довести roadmap, индексы и remaining navigation-docs до новой логики;
  • проверить, что diagram-layer не противоречит новому reference-ядру;
  • свести остаточные разночтения между старыми обзорными артефактами и текущим baseline;
  • поддерживать main-findings как живой документ перехода от domain-formation к implementation discipline.

Gate To Exit​

Из стадии 0 можно выходить только когда:

  • platform core одинаково читается из overview, reference и operations слоёв;
  • нет явных противоречий между domain-model, commercial-model, api-contracts, database-schema, storage, deployment;
  • roadmap и master-plan ведут в одном направлении;
  • старые документы переведены в статус archival reference, а не конкурирующего source of truth.

Стадия 1. Implementation Baseline​

Смысл стадии​

Перевести собранную архитектуру в форму, пригодную для поэтапной инженерной реализации.

На этой стадии проект ещё не должен притворяться production platform. Его задача — определить, как именно архитектурные документы станут executable design.

Ключевые workstreams​

1. Bounded implementation design​

Нужно определить:

  • какие release units реально существуют на первом implementation этапе;
  • где проходят первые code boundaries;
  • что будет реализовано как единый runtime unit, а что сразу должно быть отделено;
  • какие контуры нельзя объединять без operational риска.
  • какой technology baseline действительно обслуживает разные execution contours без forced one-stack dogma.

2. Contract-ready decomposition​

Нужно перевести архитектурные surface contracts в implementation-ready артефакты:

  • initial OpenAPI / AsyncAPI / IDL outlines;
  • event taxonomy;
  • compatibility expectations;
  • actor- and tenant-aware contract rules;
  • publication-state semantics.
  • queue and delivery semantics for major async contours;
  • observability instrumentation envelope for those contours.
  • initial event families and their naming/versioning discipline.

3. Persistent model hardening​

Нужно довести до implementation качества:

  • schema decomposition;
  • migration sequencing;
  • audited storage classes;
  • quote / repricing / settlement traces;
  • governance and review persistence.

4. Supplier execution design​

Нужно определить:

  • initial supplier onboarding discipline;
  • intake modes;
  • replay strategy;
  • failure isolation;
  • normalization and mapping workflow;
  • publication gating and downstream invalidation logic.

5. Surface strategy​

Нужно определить правильный порядок surface rollout:

  • internal operator surface;
  • agency working surface;
  • proposal/publication surface;
  • partner API surface;
  • optional B2C surface.

Важно: этот порядок не обязан совпадать с ранними маркетинговыми ожиданиями.

Обязательный результат​

После завершения стадии 1 у команды должны появиться:

  • implementation-ready decomposition;
  • initial contract package;
  • migration-ready persistent plan;
  • supplier onboarding baseline;
  • surface rollout order;
  • initial non-speculative delivery slices.
  • practical release-unit breakdown for the first implementation wave.
  • first implementation-ready contract package for those release units.
  • first bounded synchronous OpenAPI skeleton for those release units.
  • first bounded asynchronous AsyncAPI skeleton for those release units.
  • first channel catalog drafts for those release units.
  • first payload-family outlines for high-value async channels.
  • first concrete payload examples for top critical async events.
  • first semi-formal schema drafts for those events.
  • first explicit version-evolution policy for those async contracts.
  • first retry/DLQ/replay matrix for those schema families.
  • first consumer compatibility checklist for those release units.
  • first JSON-Schema-like field catalogs for top critical events.
  • first external webhook compatibility boundary for partner-facing async notifications.
  • first producer-side release-gate checklist for safe async contract evolution.
  • first catalog of allowed external async projections by surface and partner class.
  • first bounded external webhook payload examples for allowed projections.

Gate To Exit​

Нельзя выходить из стадии 1, пока не определены:

  • первый production-capable execution contour;
  • первая transaction-safe booking path;
  • первая quote-safe commercial path;
  • первый clearing-safe partner path;
  • первая integrity-gated publication path;
  • migration and release discipline для этих путей;
  • observability minimum для диагностики реальных сбоёв.

Стадия 2. Controlled Internal Platform​

Смысл стадии​

Построить управляемую внутреннюю платформу, на которой уже можно безопасно проживать реальные supplier, offer, quote и booking scenarios, но ещё без преждевременного широкого внешнего обещания.

Это стадия controlled internal reality, а не public launch.

Основные capability targets​

1. Supplier And Ingestion Reality​

Должно реально работать:

  • подключение ограниченного числа поставщиков;
  • intake в повторяемом режиме;
  • raw trace capture;
  • normalization;
  • canonical update;
  • review and anomaly workflow;
  • replay of representative cases.

2. Offer And Quote Reality​

Должно реально работать:

  • offer assembly;
  • freshness discipline;
  • commercial interpretation;
  • quote fixation;
  • revalidation and repricing logic;
  • integrity gating and publication control;
  • publication gating при коммерческой или data inconsistency.

3. Booking Reality​

Должно реально работать:

  • bounded booking flow;
  • booking state machine;
  • supplier-side confirmation handling;
  • failure and unknown state handling;
  • audit trail;
  • operator recovery path.

4. Post-Booking And Clearing Reality​

Должно реально работать:

  • cancellations and amendments;
  • supplier-driven disruption handling;
  • partner clearing checks;
  • deposit / limit aware sales control;
  • refund and reversal consequences;
  • supportable post-booking case model.

5. Governance Reality​

Должно реально работать:

  • human-in-the-loop review;
  • confidence-aware matching;
  • manual locks;
  • publication holds;
  • controlled correction flow.

6. Observability And Release Reality​

Должно реально работать:

  • domain-chain observability;
  • incident triage;
  • release gates;
  • migration verification;
  • rollback or forward-fix discipline;
  • recovery drills on representative failures.

Обязательный результат​

После завершения стадии 2 платформа должна быть способна пережить ограниченную реальную эксплуатацию внутри controlled operational perimeter.

Gate To Exit​

Нельзя выходить из стадии 2, пока не доказано, что система умеет:

  • не терять supplier trace;
  • не смешивать indicative price и quoted promise;
  • не терять booking truth при сбоях;
  • не терять settlement-relevant basis;
  • не допускать uncontrolled partner exposure;
  • не публиковать externally offers without integrity discipline;
  • объяснять operator-у путь от supplier signal до booking or settlement consequence.

Стадия 3. Controlled External Beta​

Смысл стадии​

Открыть платформу наружу ограниченно и осознанно, не размывая truth boundaries и не обещая рынку больше, чем система действительно умеет держать.

Возможные первые внешние контуры​

Порядок должен определяться не “где проще сделать UI”, а где ниже риск для платформы.

Наиболее реалистичный порядок выглядит так:

  1. internal operator and agency working surface;
  2. proposal and communication surface;
  3. bounded partner integration surface;
  4. только потом более широкие client-facing surfaces, если для этого уже достаточно честной publication discipline.

Ключевые workstreams​

1. Agency Beta​

Нужно проверить:

  • workspace-aware workflow;
  • quote visibility and validity;
  • proposal lifecycle;
  • booking follow-up;
  • exception handling;
  • operator support model.

2. Partner Beta​

Нужно проверить:

  • contract clarity;
  • rate and scope control;
  • version discipline;
  • publication rules;
  • compatibility handling;
  • partner-visible repricing and error semantics.

3. Financial And Operational Beta​

Нужно проверить:

  • settlement events;
  • reconciliation queues;
  • discrepancy aging;
  • refund / cancellation handling;
  • operator ownership and escalations.

Обязательный результат​

После завершения стадии 3 должен существовать ограниченный, но честный внешний operating loop:

  • платформа что-то реально обещает;
  • может объяснить это обещание;
  • может довести обещание до booking и post-booking reality;
  • может увидеть и обработать финансовые и операционные последствия.

Gate To Exit​

Из стадии 3 можно выходить только если:

  • external surfaces не ломают internal truth discipline;
  • quote/booking/settlement цепочка наблюдаема;
  • support and operations умеют сопровождать beta without archeology;
  • release changes не разрушают compatibility and financial trace.

Стадия 4. Production-Capable Baseline​

Смысл стадии​

Сделать платформу пригодной не просто для демонстрации и ограниченного beta use, а для устойчивой эксплуатационной жизни.

Это не обязательно означает “сразу массовый рынок”. Это означает, что базовые operational contours уже достаточно зрелые для настоящей ответственности.

Ключевые направления​

1. Reliability Hardening​

  • stronger failure isolation;
  • better queue discipline;
  • capacity envelopes;
  • degradation modes;
  • supplier outage handling;
  • state recovery practice.

2. Financial Hardening​

  • reconciliation completeness;
  • settlement trace durability;
  • correction event discipline;
  • refund/amendment robustness;
  • finance-support-operational ownership clarity.

3. Contract Hardening​

  • explicit version policy;
  • deprecation policy;
  • backward-compatible evolution discipline;
  • managed and external surface separation.

4. Security And Governance Hardening​

  • stronger actor and tenant isolation;
  • secret and credential discipline;
  • data retention discipline;
  • audit-readiness of sensitive contours;
  • publication control maturity.

5. Operational Maturity​

  • incident playbooks;
  • escalation model;
  • post-incident analysis;
  • release observation windows;
  • operational KPIs and service objectives.

Обязательный результат​

После завершения стадии 4 платформа должна иметь право считаться production-capable baseline, даже если она ещё не вышла на широкое масштабирование.

Gate To Exit​

Нельзя считать стадию 4 пройденной, пока:

  • platform core выдерживает реальные инциденты без потери truth;
  • booking and settlement paths переживают failures without manual chaos;
  • releases выпускаются контролируемо;
  • operator model работает не только на happy path;
  • financial and governance traces пригодны для разбора споров и corrective action.

Стадия 5. Controlled Scale And Product Expansion​

Смысл стадии​

Масштабирование должно идти только после того, как уже доказана состоятельность operational core.

Именно на этой стадии допустимо расширять:

  • supplier coverage;
  • agency network;
  • partner integration depth;
  • proposal and client-facing channels;
  • tour-builder sophistication;
  • аналитические и оптимизационные контуры.

Допустимые направления расширения​

1. Supplier Expansion​

  • новые supplier profiles;
  • supplier-class-specific handling;
  • broader geography;
  • richer coverage with preserved governance discipline.

2. Product Expansion​

  • deeper tour composition;
  • richer proposal artifacts;
  • multi-component travel product;
  • advanced commercial policies;
  • broader channel-specific offerings.

3. Analytics And Optimization​

  • reporting contours;
  • controlled optimization loops;
  • capacity and latency tuning;
  • decision support for operations and commercial teams.

4. Organizational Scaling​

  • clearer ownership model;
  • stronger ops/finance/support separation;
  • release governance;
  • formal supplier and partner enablement processes.

Что Нельзя Делать На Этой Стадии​

Нельзя расширять scale ценой размывания уже собранного ядра.

Если масштабирование:

  • ломает explainability цены;
  • ломает booking truth;
  • ломает settlement trace;
  • ломает publication honesty;
  • делает governance purely nominal;

то это не развитие платформы, а деградация под нагрузкой.

Сквозные Workstreams, Которые Не Привязаны К Одной Стадии​

1. Documentation Governance​

Документация должна обновляться вместе с платформой, а не постфактум.

Особенно это касается:

  • domain model;
  • contracts;
  • migrations;
  • settlement;
  • observability;
  • supplier onboarding;
  • operator playbooks.

2. Diagram Synchronization​

SVG, JPG и иные архитектурные схемы должны синхронизироваться с текущим source of truth, а не удерживать старую картину мира.

3. Risk Register​

Нужен живой список architectural and execution risks:

  • supplier dependency risk;
  • pricing / quote drift risk;
  • booking state ambiguity;
  • settlement discrepancy risk;
  • publication honesty risk;
  • release migration risk.

4. Decision Trace​

Ключевые решения о:

  • contracts;
  • storage;
  • release discipline;
  • supplier support;
  • channel rollout;
  • commercial policy;

должны оставлять after-image в документации, иначе roadmap потеряет управляемость.

Приоритет Следующего Практического Прохода​

После обновления этого roadmap следующий проход должен идти не в новые speculative планы, а в более прикладные документы и артефакты:

  1. проверить и синхронизировать diagram-layer;
  2. уточнить implementation slices и release units;
  3. собрать initial contract package;
  4. углубить supplier onboarding and operational playbooks;
  5. подготовить implementation-oriented breakdown по first controlled platform contour.

Краткий Итог​

Правильный roadmap для vitiana-api-platform больше не может быть roadmap-ом “от MVP к launch” в старом смысле.

Теперь это roadmap развития industrial platform:

  • сначала удержать truth boundaries;
  • затем перевести архитектуру в implementation baseline;
  • затем доказать controlled operational viability;
  • затем только расширять внешние обещания и масштаб.

Именно такой порядок соответствует уже собранной логике проекта и снижает риск того, что реализация начнёт расходиться с архитектурным центром платформы.

Timeline & Milestones​

Year 1 Timeline Overview​

Q1 2026 (Months 1-3): Foundation​

Team Building:

  • Week 1-2: Tech Lead и DevOps hiring
  • Week 3-6: Backend engineers onboarding
  • Week 7-12: Frontend и QA team completion

Technical Milestones:

  • Month 1: Database schema + K8s cluster
  • Month 2: SearchService + Stuba integration
  • Month 3: Basic frontend + authentication

Success Criteria:

  • Full team hired и onboarded
  • Core infrastructure deployed
  • First 1000 hotels searchable

Q2 2026 (Months 4-6): MVP Launch​

Feature Development:

  • Month 4: BookingService + payment integration
  • Month 5: Tour Builder + PDF generation
  • Month 6: Production launch + first customers

Business Milestones:

  • Beta testing с 5 турагентств
  • Production launch announcement
  • First 20 agencies onboarded
  • 1000+ bookings through platform

Success Criteria:

  • Full user journey working
  • 20+ active agencies
  • 85% technical targets met (cache hit, response time)

Q3 2026 (Months 7-9): Scale​

Feature Expansion:

  • HomeToGo integration (+2000 hotels)
  • Advanced filtering и search
  • Agency analytics dashboard
  • Mobile optimization

Business Growth:

  • 100+ agencies target
  • 5000+ monthly bookings
  • Partner API beta launch
  • Revenue optimization

Q4 2026 (Months 10-12): Advanced Features​

Product Evolution:

  • Advanced tour builder with activities
  • ML-based recommendations
  • Multi-supplier booking support
  • B2B API marketplace launch

Business Scale:

  • 200+ agencies
  • 10K+ monthly bookings
  • €100K+ MRR target
  • International expansion planning

Key Milestone Gates​

Gate 1 (Month 3): Technical Foundation​

Criteria:

  • Kubernetes cluster operational
  • Database schema deployed with all extensions
  • Search API functional with 1000+ hotels
  • Basic frontend deployed

Go/No-Go Decision: Proceed to booking development

Gate 2 (Month 6): MVP Launch Readiness​

Criteria:

  • End-to-end booking flow working
  • 20+ agencies signed up
  • Performance targets met (85% cache hit)
  • Security audit passed

Go/No-Go Decision: Production launch announcement

Gate 3 (Month 9): Scale Validation​

Criteria:

  • 100+ active agencies
  • 5000+ monthly bookings
  • 99.9% uptime achieved
  • Partner API beta successful

Go/No-Go Decision: Advanced features investment

Gate 4 (Month 12): Market Position​

Criteria:

  • 200+ agencies using platform
  • €100K+ MRR revenue
  • Market leader position in Ukraine
  • International expansion ready

Go/No-Go Decision: Series A fundraising

Go-to-Market Strategy​

Customer Segmentation​

Primary Segment: Small/Medium Travel Agencies​

Profile:

  • 2-20 employees
  • 50-500 bookings/month
  • Currently using manual processes or basic tools
  • Focus on leisure travel, tours

Pain Points:

  • Manual hotel search across multiple sites
  • No tour construction tools
  • Price comparison difficulties
  • Client presentation challenges

Value Proposition:

  • One-stop hotel search platform
  • Automated tour PDF generation
  • Real-time pricing comparison
  • Professional client materials

Secondary Segment: Corporate Travel Managers​

Profile:

  • Mid-size companies (100-1000 employees)
  • Regular business travel needs
  • Cost optimization focus
  • Streamlined booking processes need

Value Proposition:

  • API integration with corporate tools
  • Volume pricing through Partner API
  • Compliance и reporting features

Tertiary Segment: Large Tour Operators​

Profile:

  • 50+ employees
  • 1000+ bookings/month
  • Existing technology infrastructure
  • Custom integration needs

Value Proposition:

  • B2B API access
  • White-label solutions
  • Custom feature development
  • Enterprise support

Market Entry Strategy​

Phase 1: Ukraine Market Penetration​

Geographic Focus: Kyiv, Lviv, Odesa (major travel hubs)

Go-to-Market Tactics:

  1. Direct Sales: Personal meetings with top 100 agencies
  2. Industry Events: Travel fairs, conferences, networking
  3. Digital Marketing: LinkedIn targeting, Google Ads
  4. Referral Program: Early adopter incentives
  5. Content Marketing: Travel industry blog, case studies

Pricing Strategy:

  • Freemium Model: 50 free searches/month
  • Professional: €99/month unlimited search + basic booking
  • Enterprise: €299/month + tour builder + priority support
  • Commission: 2-5% per completed booking

Phase 2: Czech Republic Expansion​

Market Entry: Month 9-12

Localization Requirements:

  • Czech language interface
  • CZK currency primary
  • Local payment methods (Czech bank transfers)
  • GDPR compliance emphasis

Partnership Strategy:

  • Local travel association partnerships
  • Prague tourism board collaboration
  • Key opinion leader engagement

Phase 3: European Expansion​

Target Markets: Poland, Germany, Austria

Strategy:

  • Country-specific domains (.pl, .de, .at)
  • Local partnerships и distributors
  • Market-specific supplier additions
  • Regulatory compliance per country

Customer Acquisition Strategy​

Month 1-3: Foundation Building​

Tactics:

  • Website launch с SEO optimization
  • LinkedIn thought leadership content
  • Industry publication articles
  • Beta program announcement

Targets:

  • 1000+ website visitors/month
  • 100+ email subscribers
  • 10+ beta program applicants
  • Industry awareness building

Month 4-6: MVP Launch Campaign​

Tactics:

  • Product Hunt launch
  • Industry press coverage
  • Customer success stories
  • Webinar series for travel professionals

Targets:

  • 5000+ website visitors/month
  • 20+ agencies signed up
  • 1000+ bookings through platform
  • Industry recognition achievement

Month 7-12: Scale & Growth​

Tactics:

  • Referral program launch
  • Affiliate partnerships with consultants
  • Conference sponsorships
  • Customer advocacy program

Targets:

  • 200+ agencies using platform
  • 10K+ monthly platform bookings
  • 50%+ customer acquisition through referrals
  • Market leadership position establishment

Revenue Model​

Primary Revenue Streams​

1. SaaS Subscriptions (60% of revenue)

  • Professional: €99/month × 150 agencies = €14,850/month
  • Enterprise: €299/month × 50 agencies = €14,950/month
  • Subtotal: €29,800/month

2. Booking Commissions (30% of revenue)

  • Average booking value: €300
  • Commission rate: 3%
  • Monthly bookings: 10,000
  • Commission revenue: €9,000/month

3. Partner API Revenue (10% of revenue)

  • API calls pricing: €0.10 per search call
  • Monthly API calls: 50,000
  • API revenue: €5,000/month

Total Projected MRR Year 1: €43,800 (~€525K annually)

Revenue Growth Projections​

Year 1 Progression:

  • Month 6 (MVP): €5K MRR
  • Month 9 (Scale): €20K MRR
  • Month 12 (Growth): €45K MRR

Year 2 Target: €150K MRR (3x growth) Year 3 Target: €400K MRR (market maturity)

Competitive Analysis​

Direct Competitors​

Booking.com for Business:

  • Strengths: Massive inventory, brand recognition, global reach
  • Weaknesses: No tour builder, generic business tools, high commission
  • Differentiation: Our tour construction focus, regional specialization

TravelPerk:

  • Strengths: Good corporate focus, travel management tools
  • Weaknesses: Limited tour features, expensive, Western Europe focus
  • Differentiation: Tour builder functionality, Eastern Europe expertise

Local Competitors (Ukraine/Czech):

  • Strengths: Local relationships, language, market knowledge
  • Weaknesses: Limited technology, small inventory, manual processes
  • Differentiation: Technology advantage, API integration, scalability

Competitive Positioning​

Value Proposition Matrix:

                Technology  Tour Builder  Regional Focus  Price Point
vitrip.store       High        High          High          Mid
Booking.com        High        Low           Low           High  
TravelPerk         Mid         Low           Low           High
Local Players      Low         Mid           High          Low

Positioning Statement: "The only hotel aggregation platform specifically designed for Eastern European travel agencies with integrated tour construction capabilities and competitive pricing."

Success Metrics & KPIs​

Technical KPIs​

Performance Metrics (согласно overview/index.md):

  • API Response Time: <200ms P95 (target <150ms optimization)
  • Cache Hit Rate: 85-95% Redis efficiency (target 95%+)
  • Database Performance: <50ms P95 query time
  • System Uptime: 99.9% SLA (target 99.95%)
  • Error Rate: <1% 4xx/5xx responses

Scalability Metrics:

  • Concurrent Users: Support 1000+ concurrent searches
  • Request Throughput: 1000+ API calls/second capacity
  • Data Processing: 100K+ hotel updates/day ingestion
  • Storage Growth: <10GB/month PostgreSQL growth rate

Business KPIs​

Customer Metrics:

  • Active Agencies: 200+ by Month 12
  • Monthly Active Users: 1000+ agency users
  • Customer Retention: 90%+ monthly retention rate
  • Customer Satisfaction: NPS score 50+ (promoters)

Revenue Metrics:

  • Monthly Recurring Revenue: €45K by Month 12
  • Average Revenue Per User: €220/month per agency
  • Customer Acquisition Cost: <€500 per agency
  • Lifetime Value: €5000+ per agency (2+ year retention)

Operational Metrics:

  • Monthly Bookings: 10,000+ through platform
  • Booking Conversion Rate: 2-5% search to booking
  • API Usage Growth: 100%+ MoM in Partner API calls
  • Support Ticket Volume: <5% of monthly active users

Product KPIs​

Feature Adoption:

  • Search Feature: 95%+ agency usage monthly
  • Booking Feature: 80%+ agencies using monthly
  • Tour Builder: 60%+ agencies creating tours
  • PDF Generation: 50%+ of created tours exported

Content Metrics:

  • Hotel Inventory: 10,000+ unique properties
  • Supplier Coverage: 2+ active suppliers (95%+ uptime)
  • Geographic Coverage: 2+ countries (Ukraine, Czech Republic)
  • Data Freshness: <4 hour average lag от supplier updates

Tracking & Measurement​

Analytics Infrastructure:

  • Product Analytics: Mixpanel для user behavior tracking
  • Business Intelligence: Custom dashboard on Grafana
  • Technical Monitoring: Prometheus + alerts согласно operations/deployment.md
  • Customer Feedback: In-app surveys + support ticket analysis

Reporting Cadence:

  • Daily: Technical metrics, critical alerts
  • Weekly: Business metrics, feature adoption
  • Monthly: Financial metrics, customer health
  • Quarterly: Strategic KPI review, goal adjustment

Success Criteria Reviews:

  • Month 3: Technical foundation validation
  • Month 6: MVP market fit confirmation
  • Month 9: Scaling validation
  • Month 12: Market leadership assessment

Next Steps & Implementation​

Immediate Actions (Next 30 Days)​

Week 1-2: Team & Infrastructure Setup​

Priority Actions:

  1. Tech Lead Hiring: Finalize senior hire for architecture leadership
  2. Infrastructure Setup: Begin Kubernetes cluster provisioning
  3. Development Environment: Setup according to operations/deployment.md
  4. Repository Structure: Initialize according to project documentation structure

Deliverables:

  • Tech Lead offer signed
  • K8s cluster development environment ready
  • CI/CD pipeline basic setup
  • Code repositories initialized with proper structure

Week 3-4: Core Team Building​

Priority Actions:

  1. Backend Engineers: Complete hiring for both positions
  2. DevOps Engineer: Onboard infrastructure specialist
  3. Development Process: Establish sprints, code review, documentation
  4. Supplier Analysis: Deep dive into Stuba XML structure

Deliverables:

  • Core development team hired (4+ engineers)
  • Development workflow established
  • Technical spike: Stuba integration feasibility
  • Architecture review with full technical specifications

Month 2-3: MVP Development Kickoff​

Database & Core Infrastructure​

Implementation Priority:

  1. PostgreSQL setup с full schema из reference/database-schema.md
  2. Redis cluster configuration for caching layer
  3. NATS message queue для supplier events
  4. Basic monitoring setup (Prometheus + Grafana)

Search Service Foundation​

Implementation Priority:

  1. PostGIS geo-search core functionality
  2. Hotels table population from Stuba XML
  3. Basic search API endpoints согласно reference/api-contracts.md
  4. Redis caching layer с proper TTL strategies

Funding & Investment​

Current Funding Requirements​

MVP Phase (6 months):

  • Team Costs: $120K-150K (6 people × 6 months)
  • Infrastructure: $12K-15K (cloud costs, tools, services)
  • Operations: $8K-10K (legal, marketing, travel)
  • Total: $140K-175K for MVP completion

Series Seed Fundraising​

Target: €200K-300K for 12-month runway Use of Funds:

  • 70% Team costs (salaries, benefits, equipment)
  • 15% Infrastructure и technology costs
  • 10% Marketing и customer acquisition
  • 5% Operations (legal, compliance, travel)

Investment Thesis:

  • Large addressable market (2000+ agencies Ukraine)
  • Unique product positioning (tour builder)
  • Strong technical foundation и scalability
  • Experienced team с domain expertise
  • Clear path to profitability

Связанная документация​

  • Техническая архитектура: полная 6-слойная архитектура из Архитектура платформы
  • Бизнес-сервисы: 4 микросервиса (Search, Pricing, Booking, Tours) из Business Services
  • База данных: PostgreSQL схемы и структуры из Database Schema
  • API спецификации: REST endpoints и OpenAPI contracts из API Contracts
  • Инфраструктура: Kubernetes deployment и CI/CD из Deployment
  • Интеграции: Supplier adapters для Stuba и HomeToGo из Suppliers Layer
  • Хранилище данных: Redis strategies и caching из Storage Layer
  • Обработка данных: Rust ingestion pipeline из Ingestion Layer
  • Фронтенд: React/Next.js клиент из Clients Layer
  • API Gateway: Traefik конфигурация из API Layer