EhlyTECH — Cross-Language AI Service Orchestration

AI-assisted local service orchestration that turns text or image-based needs into validated workflows and bridges customers and experts across languages.

Comment

Inspiration

EhlyTECH came from real field experience.

Before building the product, I experienced local service marketplaces from both sides: as a customer and as a service provider. The core problem I saw was not only “finding an expert.” Local service work is messy: customers describe needs in natural language, choose the wrong category, leave out important details, struggle with forms, and often need help turning a real-life situation into a clear service request.

In real life, people do not think in catalog names. They say things like “my kitchen sink is leaking,” “my wall is dirty,” or “my child is struggling with math.” EhlyTECH was designed to turn those natural needs into structured, validated service workflows.

What it does

EhlyTECH is an AI-assisted local service orchestration platform.

Users can reach a service in multiple ways:

  • Search
  • Category selection
  • Natural-language descriptions
  • Image-based service intent signals

A user can describe a need with text, or in some cases provide an image such as a broken faucet, a dirty wall, or a visible renovation issue. The assistant can infer likely service intent and route it into the same service pipeline.

The broader EhlyTECH product is designed to manage the full local-service lifecycle:

customer need
→ service routing
→ planned or urgent workflow
→ dynamic form
→ expert job card
→ offer
→ AI-assisted expert offer text
→ customer/expert messaging
→ cross-language translation
→ agreement
→ reminders
→ completion
→ rating and expert statistics

A user can also participate as both a customer and an expert, which lets the platform support both sides of the local service economy.

Existing product foundation

EhlyTECH existed before Build Week as a Flutter/Firebase-based customer and expert product with a broader local-service foundation.

Existing capabilities include:

  • Planned service workflows and urgent/fast job workflows
  • Dynamic service forms
  • Multi-language UI, dictionaries, vectors, and form infrastructure
  • Natural-language service routing
  • Image-to-service-intent path
  • Customer-to-expert job flow
  • Expert job cards
  • Expert offer submission
  • AI-assisted expert offer writing
  • Customer/expert messaging
  • Automatic translation when customer and expert languages differ
  • Offer translation into the receiver’s language
  • Smart pricing infrastructure
  • Geography, distance, city multiplier, category, and currency logic
  • Expert statistics
  • Reminder and notification flows
  • Completion and rating flows
  • Founding Expert application and admin tracking infrastructure

Before the app launch, we also launched a website to start building the expert supply side. Founding Expert applications have started coming in through the website from different cities and service categories.

Multi-gate service routing

One of EhlyTECH’s core design principles is cost-aware routing.

The system does not try to send every request directly to a large language model. Instead, it uses a staged decision architecture:

dictionary matching
→ vector / semantic matching
→ intent routing
→ controlled LLM fallback
→ service / FAQ / chat / unsupported-service handling

If the user is asking for a valid service, EhlyTECH tries to open the relevant service workflow. If the message is an FAQ, it can answer. If it is general chat, it can continue the conversation while staying close to service intent. If the requested service is not supported, the system should not force the user into the wrong workflow.

This architecture is designed to improve speed, reduce cost, and keep service decisions under product control.

What we built during Build Week

EhlyTECH was not built from scratch during Build Week.

The broader Flutter/Firebase product, Gemini-assisted routing/form flows, multilingual catalogs, translation infrastructure, pricing logic, and customer/expert workflows already existed.

For Build Week, we used Codex and GPT-5.6 to add an isolated, testable backend vertical slice for cross-language service orchestration.

The Build Week slice demonstrates this flow:

English customer need
→ GPT-5.6 Need Interpreter
→ Ehly deterministic catalog and workflow validation
→ Turkish expert offer
→ GPT-5.6 Offer Bridge
→ deterministic price / time / claim validation
→ English customer-facing offer

GPT-5.6 is used for language understanding and cross-language bridging. It does not own the marketplace authority. Canonical service validation, workflow selection, and post-generation checks remain in Ehly’s deterministic layer.

How we built it

The existing product foundation uses Flutter, Firebase, Firestore, Firebase Cloud Functions, Python backend logic, multilingual dictionaries, vector search, Gemini-assisted production flows, and localization infrastructure.

For Build Week, Codex helped implement, test, document, and package an isolated GPT-5.6 backend slice.

The slice uses GPT-5.6 in two bounded roles:

  1. Need Interpreter
    It structures a natural-language customer need into a strict format.

  2. Offer Bridge
    It bridges an expert’s offer into the customer’s language while preserving critical business facts such as time, price, currency, and conditions.

Ehly’s deterministic layer remains responsible for catalog validation, canonical service control, workflow type, and post-generation fact/claim validation.

The existing Gemini production path was not migrated or replaced. The GPT-5.6 Build Week work is presented as a modular backend extension.

Technical architecture

The architecture deliberately separates language intelligence from marketplace authority.

GPT-5.6 interprets and bridges human language.

Ehly’s deterministic layer controls:

  • canonical service validation
  • catalog checks
  • workflow selection
  • country/service policy evaluation
  • price, time, currency, and selected claim validation
  • fallback or human-review routing when validation fails

This creates a safer AI architecture for local services: the model helps understand and communicate, but deterministic product logic controls whether a service workflow is accepted.

Tests and evidence

The Build Week slice was packaged with:

  • 9 automated guardrail/unit/contract tests
  • 2 verified live GPT-5.6 calls
  • Need Interpreter live trace
  • Offer Bridge live trace
  • Recorded live traces showing fallback_used:false
  • Recorded live traces showing errors:[]
  • Offer Bridge trace showing added_claims:[]
  • Clean submission commit: 6019e18cccd27ed6997b9ed0f919be65c6e6482d
  • Tag: build-week-gpt56-demo
  • Codex session reference: 019f722f-2b1e-7b13-89be-7f716c120315

The judging repository uses a clean one-commit submission history with no product history or API keys.

Challenges we ran into

The hardest challenge was combining flexible AI language understanding with the strict rules of a real service marketplace.

In local services, a wrong category, wrong price, wrong time, or unsupported promise can create real operational problems. So we did not give GPT-5.6 full authority over the marketplace workflow.

Instead, we designed a controlled architecture:

GPT-5.6 handles language.
Ehly validates services, workflows, facts, and claims.

Another challenge was presenting the Build Week work honestly. EhlyTECH already had a broader product foundation, so we clearly separated the pre-existing product from the GPT-5.6 Build Week slice in the demo, README, traces, tests, commit, and tag.

Accomplishments that we’re proud of

  • Added an isolated GPT-5.6 backend orchestration slice on top of an existing local-service platform
  • Combined natural-language need interpretation with deterministic service validation
  • Built an Offer Bridge that transfers a Turkish expert offer into English while preserving key facts
  • Created automated guardrail/unit/contract tests
  • Captured verified live GPT-5.6 traces
  • Packaged the work with README documentation, fixtures, commit, tag, and Codex session reference
  • Clearly separated pre-existing product capabilities from Build Week contributions
  • Launched a pre-release website to build the expert supply side before the app launch
  • Started receiving Founding Expert applications through the website from different cities and service categories

What we learned

For AI-assisted local services, the safest architecture is not to let the model control everything.

The model is powerful for language, interpretation, and cross-language communication. But product logic should remain responsible for service validation, workflow selection, price/time checks, and operational guardrails.

Build Week showed that GPT-5.6 can be valuable as a Need Interpreter and Offer Bridge, especially when combined with deterministic validation, test coverage, live traces, and clear scope boundaries.

What’s next

In the short term, we plan to connect this GPT-5.6 backend slice more deeply into the product architecture, connect it with real Firestore availability and expert matching data, and test it across more services, categories, languages, and country scenarios.

Product roadmap:

  • Launch first in Türkiye
  • Expand next to the United States
  • Then roll out country by country
  • Grow the Founding Expert pool
  • Improve expert verification and onboarding
  • Mature the pricing-learning engine using real offer data
  • Improve cross-language offer and messaging quality
  • Strengthen the admin panel and operations tracking

Long term, EhlyTECH has a broader HaYaT vision:

Services
→ Food
→ Supply

The goal is to start with local services, then add food ordering and supply/market delivery once the service side is mature.

At the final stage, a user should be able to manage daily life needs through a single AI-assisted local life interface:

“Ehly, order me a pizza.”
“Ehly, I’m out of shampoo, have shampoo delivered.”
“Ehly, can you call me a taxi?”

This is the long-term EhlyTECH HaYaT vision: a technological life layer for everyday local needs.

Built With

Share this project:

Updates