SyriaCore
An AI-native tourism platform where ambitious product vision, accelerated implementation and real-world constraints meet.
- AI-NATIVE
- PLATFORM
- TRAVEL
- ARCHITECTURE
Problem
Planning travel through Syria means navigating fragmented information, disconnected tools and schedules that rarely account for geography, travel time or the realities of a day on the ground.
Idea
Build a bilingual tourism platform that helps people discover places, events and food; shape collaborative multi-day itineraries; ask an AI travel companion for guidance; and continue using the experience while they are actually travelling.
Architecture
SyriaCore spans a traveler-facing web PWA and mobile app, a CMS as the system of record, Keycloak identity, dedicated trip-scheduling and route services, a knowledge and retrieval layer, first-party analytics and offline-capable companion experiences. Each part has a defined responsibility rather than treating the AI model as the system itself.
What I Built
A working platform across discovery, collaborative itineraries, maps, personalized recommendations, an AI journey planner and companion mode, supported by services for content, identity, scheduling, routing, retrieval and analytics.
[PRODUCT::SURFACES]
01Discover
Cultural discovery grounded in real places, categories and personalized recommendations.
02Trips
Multi-day itineraries connect planning, editing and the transition into a live trip.
03Companion Mode
The planned itinerary becomes an on-the-ground guide to the next stop, route and context.
How AI Agents Were Used
AI coding agents were a substantial part of turning the product vision into working software. They contributed across implementation, interfaces, refactoring, tests, debugging, documentation, research and integration work, making a scope that would historically have demanded far more implementation effort possible to explore and iterate quickly.
[ARCH::BOUNDARY]
Building SyriaCore with AI — and where architecture entered
AI made it possible to move from an ambitious product idea to working software much faster than before. That contribution was not peripheral: it materially changed what one person could explore, connect and ship.
As the product became more real, the question changed. The challenge was no longer only whether each piece could be built, but whether those pieces formed a system that could survive real data, real permissions, real geography and real users.
AI::QUESTION
Can we make this vision real?
ARCHITECTURE::QUESTION
Will it survive reality?
BUILD::PIPELINE
- 01Vision
- 02AI-accelerated implementation
- 03Working product
- 04Reality introduces constraints
- 05Architectural judgment
- 06System that survives reality
AI::LEVERAGE
- Implementation
- UI development
- Refactoring
- Testing
- Debugging
- Documentation
- Research
- Integration work
- Approach exploration
- Iteration
REALITY::CONSTRAINTS
- Business rules
- Data ownership
- Permissions
- Validation
- Geography
- Travel time
- Failure modes
- User expectations
ARCHITECTURE::QUESTIONS
- 01Where should business rules live?
- 02What belongs to AI, and what must be deterministic?
- 03How should travel time constrain an itinerary?
- 04How do we detect impossible schedules?
- 05Which system owns place, trip and user data?
- 06How should identity and authorization work?
- 07How do we stop generated plans violating real constraints?
- 08How should knowledge be represented and retrieved?
- 09Where does RAG help, and where is structured data better?
- 10What happens when an external system fails?
- 11How are actions validated before changing user data?
- 12Which decisions belong to the model or the application?
ARCHITECT::RESPONSIBILITY
Decide what should be built, how the pieces should behave together, which constraints matter and whether the resulting system makes sense as a whole.
- Define product boundaries
- Decompose the problem
- Assign system responsibilities
- Identify real constraints
- Choose deterministic boundaries
- Shape the knowledge architecture
- Define integration contracts
- Evaluate tradeoffs
- Identify failure cases
- Challenge locally-correct implementations
- Keep asking beyond the happy path
Key Decisions
Keep product data and user state in explicit systems of record; centralize itinerary math instead of duplicating it across clients; let AI interpret intent and generate possibilities while deterministic services enforce time, geography, permissions and write validation; and design every integration with an owned contract and a failure path.
What Worked
AI made it possible to move across product surfaces and infrastructure unusually quickly. Ideas could become working flows, be tested against the wider platform and be revised without implementation capacity becoming the first bottleneck.
What Didn't
Some generated implementations were locally convincing but wrong for the system: business rules landed in the wrong layer, ownership blurred, happy paths ignored failure modes, or an AI-generated itinerary violated a real travel constraint. Those moments were not failures of speed; they revealed where architecture had to become explicit.
What I’m Learning
SyriaCore has become a practical test of something I have been thinking about more broadly: AI changes the economics and speed of building software, but it does not eliminate the need for architecture. In many cases, it moves the architecture problem.
AI can get surprisingly far toward a working product. The difficult questions increasingly appear when that product has to deal with real data, permissions, constraints, integrations, failure modes and users. That is the point where “Can we build it?” becomes “Will it survive reality?”
[PROJECT::THESIS]
SyriaCore is an AI-native travel platform that shows what becomes possible when AI accelerates execution and architecture provides the judgment needed to turn an ambitious vision into a real system.
- 01
The vision was ambitious.
- 02
AI provided enormous leverage in turning that vision into working software.
- 03
Architectural judgment connected the generated pieces into a coherent system capable of dealing with real-world constraints.