Projects

The problem

Suppliers lose money to deductions taken out of their Walmart payments, and most can't tell which ones are wrong before the dispute window closes.

The solution

Argus runs the supplier's Walmart account on one screen. It collects every invoice, payment and deduction daily, matches each one to the cent, explains it, and drafts the dispute when it is worth fighting.

How it works

• Collect: Invoice, payment and dispute records from Walmart's supplier API and portals, every day
• Store: A PostgreSQL warehouse with raw, cleaned and reporting layers
• Match: Every short payment matched to its invoice, to the cent
• Classify: A rules knowledge base maps each deduction by code and root cause, and says whether it is worth disputing
• Draft: LLM agents draft each dispute with its evidence, and a RAG assistant answers why any deduction happened, quoting Walmart's rules and the contract
• Decide: Dashboards show what to recover, prevent or accept, sorted by filing deadline, and the team approves every filing

The impact

• Every deduction matched to its invoice and classified every morning, with no manual digging.
• Disputes filed inside the window, drafted with their evidence and approved by a person.
• Repeat causes visible by distribution center, item and carrier, so they get fixed upstream.
• One working list for the team: recover, prevent or accept, sorted by deadline.

Built with

• Python
• PostgreSQL
• Airflow
• Playwright
• LLM agents
• RAG
• Streamlit

The problem

A three-branch car-service business ran on about 47,000 Excel files, with the same customer, car or part written many ways and transfer receipts arriving as phone screenshots.

The solution

One pipeline reads every invoice and daily sheet, cleans the names and loads a warehouse that refreshes itself, with dashboards and an assistant on top.

How it works

• Read: About 47,000 Excel files: form-style invoices and daily cash workbooks
• Clean: Customer, car and part names standardised across every spelling
• Load: A warehouse that refreshes itself every day
• Answer: An assistant that answers from that data and the price lists
• Report: Power BI dashboards and improved Excel templates

The impact

• About 47,000 scattered files turned into one source of truth.
• The same customer, car or part recognised across every spelling.
• Branch performance on Power BI dashboards, and an assistant that answers from the data and price lists.
• Improved Excel templates, so new data arrives clean.

Built with

• Python
• PostgreSQL
• Airflow
• RAG
• LLM agents
• Power BI
• Excel

The problem

An HR team sees one in six employees leave but cannot tell where it happens, why, or who will go next, so retention money gets spread across everyone.

The solution

A Power BI report on a clean star schema that shows where people leave, the drivers behind it and a risk score for every employee, ending in five actions, each with a KPI and an owner.

How it works

• Clean: The HR table, 1,470 employees and 35 columns, cleaned in one Power Query staging step
• Model: A star schema: one employee fact table and seven dimensions, every filter one way
• Measure: 15 DAX measures with variables, and outliers found with the 1.5 × IQR rule
• Score: Six risk flags per employee: overtime, single, entry level, no stock options, two years or less, low satisfaction
• Show: A home page and three report pages: overview, drivers, trends and outliers
• Act: Five actions, each with a KPI and an owner, and the list of people to talk to first

A closer look

The code

Risk Flags =
VAR _OverTime = RELATED ( dim_overtime[OverTime] ) = "Yes"
VAR _Single = RELATED ( dim_marital_status[MaritalStatus] ) = "Single"
VAR _EntryLevel = fact_employee[JobLevel] = 1
VAR _NoStock = fact_employee[StockOptionLevel] = 0
VAR _EarlyTenure = fact_employee[YearsAtCompany] <= 2
VAR _LowEnvSat = fact_employee[EnvironmentSatisfaction] = 1

The impact

• Where: Sales has the highest rate, and Sales Representatives leave at 39.8%.
• Why: overtime staff leave at 30.5% against 10.4%, and the first two years hold 43% of leavers.
• Who next: 295 current employees carry three or more of the six risk flags.
• What to do: five actions, each with a KPI to track on the dashboard and an owner.

The result

1,470 employee records: attrition climbs from 4.6% with no risk flags to 75% with five, and 295 current staff carry three or more.

Built with

• Power BI
• DAX
• Power Query
• Star schema
• SQL

The problem

Finding data and AI work in Egypt and the Gulf means checking a dozen job boards and hundreds of career pages by hand, seeing the same job three times and still missing the new ones.

The solution

A pipeline that reads every source once a day, keeps each job once, ranks it against the roles, places and skills wanted, and emails only the jobs not seen before.

How it works

• Collect: 19 job boards and job APIs in Egypt, the Gulf and remote, 121 company career pages in Egypt, a crawl of 28,000+ more and the Gmail job alerts
• Respect: Every site read inside its limits: one that asks to wait is left alone for as long as it asks
• Store: A PostgreSQL warehouse with raw, core and mart layers, where the same job on three boards is one row
• Rank: Each job checked against the roles, places and level wanted, then scored by skills
• Email: Two emails a day, Egypt and outside Egypt, junior to senior, each job sent once
• Apply: On request, Claude grades the best matches, tailors the CV and applies only after a yes

A closer look

The code

- name: AI & Data Engineer
  search: [AI Data Engineer, Data AI Engineer, ML Data Engineer]
  title_needs:
    - [data]
    - [ai, ml, genai, llm, llms, machine learning]
    - [engineer*, developer*]

- name: Data Engineer

The impact

• A dozen boards and hundreds of career pages checked without opening one of them.
• The same job on three boards, or reposted, arrives once.
• Onsite jobs only where the commute works; everywhere else, remote only.
• Roles, places and companies changed in plain words in one settings file.

The result

Open-source product: 22 sources, 121 company career pages in Egypt and a crawl of 28,000+ more, merged into one ranked list every day.

Built with

• Python
• Airflow
• PostgreSQL
• Docker
• Playwright
• Streamlit
• Claude Code

The problem

Sales, seller and product data sit in separate exports, so every report needs a day of cleaning and the totals never agree.

The solution

A pipeline that loads every order, item, seller and review into a star-schema warehouse, cleans it with dbt, and feeds a Power BI sales, supplier and late-delivery report.

How it works

• Collect: Orders, items, sellers and reviews loaded as they are
• Clean: dbt staging models set types, tidy names and keep one review per order
• Model: A star schema of order facts with product, seller, customer and date dimensions
• Report: Power BI sales, supplier and late-delivery pages

A closer look

The code

ranked = sellers.sort_values("late_rank").reset_index(drop=True)
cum = ranked.late_items.cumsum() / ranked.late_items.sum()
share = numbers["top sellers: share of late items"] * 100
fig, ax = plt.subplots(figsize=(8, 3.6))
ax.plot(range(1, len(cum) + 1), cum * 100, color=ACCENT, lw=2)
ax.axvline(TOP_N, color=GREY, ls="--", lw=1)
ax.set_xlabel("Sellers, most late items first")
ax.set_ylabel("Share of all late items (%)")

The impact

• One star schema for sales, sellers as suppliers, products and departments.
• The 100 suppliers to call first: they ship 42% of items but cause half of the late ones.
• Power BI sales, supplier and late-delivery pages on one trusted model.

The result

99,441 orders in one star schema: 100 of 3,095 sellers account for half of all late-delivered items.

Built with

• PostgreSQL
• dbt
• Python
• Docker
• Power BI

The problem

Every branch sends its own Excel file in its own format, so someone spends hours each week copying, fixing and pasting before anyone sees a total.

The solution

One script reads every branch file, cleans names, dates and amounts to one standard, sets aside rows that break the rules with the reason, and rebuilds the weekly report in Excel and Power BI in one click.

How it works

• Collect: Every branch's monthly Excel file dropped in one folder
• Clean: Names, dates, products and amounts fixed to one standard, duplicates removed
• Check: Rows that break the rules set aside with the reason, never silently dropped
• Merge: One clean, trusted table across all branches and months
• Report: A weekly Excel and Power BI report rebuilt in one click

A closer look

The code

order_date: [Order Date, Date]
ship_mode: [Ship Mode, Shipping]
segment: [Segment, Customer Type]
city: [City]
state: [State]
product_id: [Product ID, SKU]
category: [Category]
sub_category: [Sub-Category, Subcategory]
product_name: [Product Name, Item]
quantity: [Quantity, Qty]
sales: [Sales, Amount]
profit: [Profit]

The impact

• Hours of copy, paste and VLOOKUP replaced by one click.
• Every branch in the same format, so totals match.
• Bad rows listed with the reason, so they get fixed at the source.

The result

10,089 rows across 192 branch files: 253 errors caught and set aside with the reason, report rebuilt in under a minute.

Built with

• Python
• pandas
• Excel
• Power Query
• Power BI

The problem

Buyers can't see which suppliers and departments deliver late or short until shelves run empty.

The solution

A Power BI supplier scorecard on a star-schema model: on-time-in-full, fill rate and late rate by supplier and department, a watch list of the suppliers to call, each buyer seeing only their department, and a short written summary of each week.

How it works

• Load: Orders, suppliers and departments into a star schema, checked on every load
• Rules: On-time-in-full, fill rate and late rate written once in DAX
• Secure: Row-level security: each buyer sees only their department
• Explain: A local LLM writes each department's weekly summary, every number checked
• Report: Power BI scorecard, reloaded from source on demand

A closer look

The code

WORST_SUPPLIER_SQL = """
SELECT s.supplier, COUNT(*) AS late_lines
FROM star.fact_order_line f
JOIN star.dim_product p  USING (product_key)
JOIN star.dim_supplier s USING (supplier_key)
CROSS JOIN star.client_setting c
WHERE DATE_TRUNC('week', f.due_date)::date = %(week)s
  AND f.delivered_date > f.due_date + c.on_time_grace_days

The impact

• One trusted score per supplier and department.
• Late deliveries traced back to the supplier's late hand-over.
• Each buyer sees only their own department.
• A plain-language summary of the week beside the charts.

The result

98,666 orders: 29% of late deliveries started with a supplier's late hand-over, and 61 suppliers with 4.4% of deliveries accounted for 12% of them.

Built with

• Power BI
• DAX
• Power Query
• PostgreSQL
• Python
• Ollama

The problem

Best sellers run out before anyone notices while slow items fill the shelves, because stock is checked by hand and too late.

The solution

A daily pipeline loads sales and stock, works out days of cover and a reorder point per item, emails the morning reorder list, and shows stock risk in Power BI.

How it works

• Load: Daily sales and stock per store and item into a warehouse, checked on every load
• Forecast: Expected daily demand per item from recent sales
• Rules: Days of cover, reorder point and safety stock written once, counting orders on the way
• Alert: An email each morning listing the items to reorder and how many
• Report: A Power BI stock report: what to reorder, what is empty, what sits too long

A closer look

The code

@task
def rules():
    import pipeline
    pipeline.rules()

@task
def alert():
    import pipeline
    pipeline.alert()

load() >> forecast() >> rules() >> alert()

The impact

• A reorder list every morning, before the shelf is empty.
• Overstocked and dead items visible, so cash stops sitting on shelves.
• One rule for days of cover and safety stock, used by every store.

The result

913,000 sales rows: 1,643 stock-outs flagged in time to reorder, and 37% of stock value found in slow items.

Built with

• Power BI
• DAX
• PostgreSQL
• Python
• Airflow

The problem

The owner learns how much cash came in only at month end, from a spreadsheet nobody trusts, so late payments and weak days are found too late.

The solution

A Power BI cash page on a star schema: money in by day, payment method and region, what is still due on instalments, and what is late, with every total matching the source.

How it works

• Load: Orders and payments by method, instalment and day
• Rules: Cash in, cash still due and late payments defined once
• Model: A star schema with a date table, so every day, month and year adds up
• Report: A daily cash page: what came in, what is due and what is late

A closer look

The code

select
    i.payment_id,
    i.order_id,
    i.instalment_no,
    i.instalments,
    i.payment_type,
    i.customer_state,
    i.order_date,
    i.cash_date,
    i.amount,
    case when i.cash_date is null       then 'Never paid'
         when i.cash_date <= r.report_date then 'Received'
         else 'Due'
    end as status,

The impact

• Today's cash on one page, not at month end.
• Instalments still due and late payments listed.
• The payment methods and regions that bring the money in.

The result

103,886 payments: 76% of the cash in arrived by credit card, and BRL 1.56 million was still due on instalments.

Built with

• Power BI
• DAX
• Power Query
• PostgreSQL
• SQL

The problem

The business treats every customer the same, so it spends on people who would buy anyway and loses good customers without noticing.

The solution

An analysis that scores every customer on recency, frequency and spend, groups them into champions, loyal, new, at risk and lost, tracks how each starting month's customers return, and shows who to contact first in Power BI.

How it works

• Clean: Invoices cleaned: returns, cancelled orders and missing customers handled
• Score: Each customer scored on how recently, how often and how much they buy
• Group: Customers grouped into champions, loyal, new, at risk and lost
• Cohorts: How many customers from each starting month come back
• Report: A Power BI page per group, with who to call first

A closer look

The code

still_buying = customers.r_score >= RULES["still_buying_min_recency_score"]
good = customers.f_score + customers.m_score >= RULES["good_customer_min_frequency_plus_spend"]
customers["segment"] = np.select(
    [still_buying & good, still_buying & (customers.orders == 1), still_buying, good],
    ["Champions", "New", "Loyal", "At risk"],
    default="Lost",
)

The impact

• The customers who bring most of the revenue, named: 1,772 champions bring 77% of it.
• 631 good customers who stopped buying, listed biggest spender first.
• Return rates by starting month: 20.8% of new customers buy again the next month.

The result

36,573 invoices: 30% of customers bring 77% of revenue, and 631 good customers are at risk.

Built with

• Python
• pandas
• SQL
• Power BI
• DAX

The problem

Prices are checked by hand on a few competitor sites now and then, so the business finds out it was undercut after the sales are gone.

The solution

A weekly pipeline reads competitor prices, matches each product to the client's own, keeps every price with its date, emails an alert when a key product is undercut, and shows price gaps in Power BI.

How it works

• Collect: Competitor prices read every week, from product pages and published shelf prices
• Match: Each competitor product matched to the client's own product, by barcode or by name
• Store: Every price kept with its date, so changes become history
• Alert: An email when a competitor undercuts a key product
• Report: Power BI pages of price gaps and changes by product

A closer look

The code

for attempt in range(8):
    response = http.get(url, params=params or None, timeout=60)
    if response.status_code not in (429, 503):
        break
    wait = response.headers.get("Retry-After", "")
    time.sleep(int(wait) if wait.isdigit() else 2 ** attempt)
response.raise_for_status()
return response

The impact

• Competitor prices checked automatically, with no one browsing.
• An alert the week a key product is undercut.
• Price history, so promotions and patterns show up.

The result

356 products across 10 stores: 127 price changes caught, each within one run.

Built with

• Python
• BeautifulSoup
• Airflow
• PostgreSQL
• Power BI

The problem

The sales report takes ages to open, some totals look wrong, and people go back to Excel because they stopped trusting it.

The solution

The slow report's flat model rebuilt as a star schema with a date table, its slow DAX rewritten, and every number checked against SQL before and after, handed over with a build guide and a note of every change.

How it works

• Measure: One timing method for every page, before and after: Performance Analyzer and DAX Studio from a cold cache
• Model: The flat table rebuilt as a star schema with a proper date table
• DAX: Slow measures rewritten with variables and filter context done right
• Check: Every card, chart and table checked against SQL, the same in both reports
• Hand over: Both reports, a step-by-step build guide and a note of every change

A closer look

The code

overview = q('''
SELECT count(*)                       AS sales_rows,
       count(DISTINCT order_key)      AS orders,
       count(DISTINCT customer_key)   AS customers,
       count(DISTINCT product_key)    AS products,
       min(order_date)                AS first_order,
       max(order_date)                AS last_order,
       round(sum(quantity * net_price)) AS sales_all_years
FROM sales
''')

The impact

• A lean model: each name stored once, no hidden date tables, no calculated columns.
• Totals that add up, checked against the source.
• A model the next developer can understand.

The result

2,098,633 sales rows: one 35-column table rebuilt as a star schema of 4 tables, every number matched against SQL before and after.

Built with

• Power BI
• DAX
• Power Query
• DAX Studio
• Python
• SQL

The problem

Orders, items, sellers and reviews sit in separate exports, so a marketplace cannot see on one page whether it is growing, who carries the revenue, or what late deliveries cost in customer reviews.

The solution

A Power BI report on a star schema with five pages, from overview to delivery: growth against last year, what sells, the sellers behind the revenue, late deliveries by seller and state, and security so each regional manager sees only their own sellers.

How it works

• Load: Orders, items, products, sellers, customers and reviews checked and read by one Python notebook
• Clean: Delivered orders only, the latest review of each order, English category names
• Model: A star schema: one fact table of items sold, four dimensions, one-way filters
• Measure: 23 DAX measures: growth against last year, late deliveries, reviews, seller share
• Report: Five pages from overview to delivery, with each regional manager limited to their own sellers

A closer look

The code

WITH sale_orders AS (
    SELECT
        order_id,
        customer_id,
        CAST(purchased_at AS DATE) AS order_date,
        CAST(delivered_at AS DATE) AS delivered_date,
        CAST(estimated_at AS DATE) AS estimated_date
    FROM orders
    WHERE list_contains($sale_statuses, status)
),

The impact

• Growth against the same period last year on one page: 2018 revenue up 145%.
• Late deliveries traced to sellers and states: 6.8% of orders overall, 21.4% in the worst state.
• The 297 sellers who bring two thirds of the revenue, listed with their delivery and review record.
• Each regional manager sees only the sellers in their region.

The result

96,478 orders: late orders scored 2.27 stars against 4.29 on time, and the top 10% of sellers brought 67% of revenue.

Built with

• Power BI
• DAX
• Python
• Star schema
• Row-level security

The problem

Order files pile up on shared drives, with no single source of truth and no history.

The solution

An Airflow pipeline picks up each new daily file from a storage container, PySpark builds raw, cleaned and reporting Delta tables, and Power BI reads the reporting layer.

How it works

• Land: Daily order files dropped into a storage container (the Azure Blob Storage API)
• Ingest: An Airflow task picks up only the files not loaded yet
• Clean: PySpark jobs build raw, cleaned and reporting Delta tables
• Load: Merges keep one current row per item; the raw layer keeps every file as received
• Report: Power BI on the reporting layer

Built with

• PySpark
• Delta Lake
• Airflow
• Azurite
• Docker
• Power BI

The problem

Accounts payable pays supplier invoices that don't match the purchase order or the delivery: wrong prices, short shipments and duplicates, because nobody checks every line by hand.

The solution

A pipeline that reads each invoice PDF or scan, matches it line by line to its purchase order and goods receipt, and flags every mismatch before payment, with a report per supplier and department.

How it works

• Read: Invoice PDFs and scans read with Docling and a local vision model
• Extract: Lines, prices and quantities into a checked invoice schema
• Match: Each line matched to its purchase order and goods receipt, within tolerances
• Flag: Mismatches and duplicates held aside with the reason
• Report: Power BI overbilling report per supplier and department

Built with

• Python
• Docling
• Ollama
• PostgreSQL
• dbt
• Airflow
• Power BI

The problem

Managers wait days for an analyst to pull a simple number, and analysts spend their week on repeat requests.

The solution

An assistant that turns a plain question, such as late deliveries by supplier last month, into a checked, read-only SQL query on the warehouse, and refuses rather than guesses.

How it works

• Model: Orders loaded as a documented star schema
• Ask: A manager types a question in plain language
• Plan: A LangGraph agent picks the tables and writes SQL from the dbt docs
• Check: The read-only query is validated before it runs
• Answer: The result with its query shown, or a clear refusal

Built with

• LangGraph
• Ollama
• PostgreSQL
• dbt
• FastAPI
• DeepEval

The problem

Payment terms, penalties and termination clauses are buried in hundreds of supplier contracts, and buyers miss them.

The solution

An assistant that answers questions about supplier contracts in plain language and cites the exact clause, tested against labelled contracts.

How it works

• Parse: Docling splits contracts into sections and clauses
• Index: Clauses embedded locally and stored in Qdrant
• Retrieve: Hybrid search with BM25 and a cross-encoder reranker
• Answer: A local LLM answers with the clause cited
• Evaluate: RAGAS and DeepEval scores on the labelled clauses

Built with

• RAG
• Docling
• Qdrant
• FastAPI
• Ollama
• RAGAS

The problem

Every team calculates lead time and fill rate differently, so the same question gets different answers.

The solution

dbt marts that define lead time, fill rate and supplier cost once, tested on every run and documented with lineage anyone can browse.

How it works

• Generate: Suppliers, parts and orders loaded with DuckDB
• Stage: dbt staging models clean and rename the sources
• Model: Marts for lead time, fill rate and supplier cost
• Test: Built-in and custom dbt tests on every run
• Publish: dbt docs and lineage published with GitHub Actions

Built with

• dbt
• DuckDB
• Jinja
• dbt-utils
• GitHub Actions

The problem

Supplier and product master data has no owner, no lineage and no checks, so errors surface in the reports.

The solution

A governance layer with quality checks on every load, owners and definitions in a data catalogue, lineage from source to dashboard, and access set by role.

How it works

• Profile: Supplier and product tables profiled in PostgreSQL and MongoDB
• Check: Soda Core quality checks on every load
• Catalogue: OpenMetadata holds owners, definitions and tags
• Trace: Lineage from source to dbt models to dashboard
• Secure: Roles limit access to sensitive fields

Built with

• OpenMetadata
• Soda Core
• PostgreSQL
• MongoDB
• dbt

The problem

Demand planning runs on slow spreadsheets that can't hold years of item-level sales.

The solution

Spark jobs that reshape and aggregate years of item, store and department sales into Parquet, tuned with partitioning and caching, ready for planning reports.

How it works

• Load: Store sales, calendar and prices into HDFS
• Reshape: PySpark unpivots daily sales per item and store
• Aggregate: Spark SQL demand per department, store and week
• Tune: Partitioning, caching and file sizes tuned and measured
• Store: Results written as Parquet for reporting

Built with

• Apache Spark
• PySpark
• Spark SQL
• Hadoop
• Parquet

The problem

Stock-outs show up in yesterday's report, after the sales are already lost.

The solution

Orders stream in live, stock per department is recalculated continuously, and an alert fires the moment an item drops below its threshold, alongside live review sentiment per supplier.

How it works

• Stream: Orders and reviews streamed into Kafka topics
• Process: Spark Structured Streaming updates stock per item and department
• Score: A BERT model scores review sentiment per supplier
• Alert: A threshold breach triggers an alert
• Store: Events and totals land in PostgreSQL for reporting

Built with

• Kafka
• Spark Streaming
• PostgreSQL
• Airflow
• Docker

The problem

Nightly loads break when a supplier renames a column or changes a unit, and reports go stale until someone fixes the code.

The solution

An Airflow pipeline that detects schema changes in each supplier feed, proposes a fix with an LLM agent, tests it, and loads the data once a person approves.

How it works

• Receive: One CSV feed per supplier lands on schedule
• Detect: Schema and value checks compare each file with its contract
• Propose: An LLM agent drafts the mapping fix
• Approve: A person approves the fix through a pull request
• Load: The corrected feed loads into PostgreSQL

Built with

• Airflow
• Python
• PostgreSQL
• LangGraph
• Ollama
• Langfuse

The problem

The same product is listed by several suppliers under different names, with missing attributes, so stock and sales split across duplicates.

The solution

A pipeline that extracts attributes from supplier titles, descriptions and images, matches listings of the same product with embeddings, and keeps one clean record per item.

How it works

• Collect: Supplier titles, descriptions and images loaded per feed
• Extract: A local LLM fills a checked attribute schema
• Embed: Listings embedded and stored in pgvector
• Match: The same product matched across suppliers, uncertain pairs reviewed
• Publish: One product record per item in the warehouse

Built with

• Python
• Ollama
• Pydantic
• sentence-transformers
• pgvector
• dbt

The problem

Teams want AI assistants on their data, but giving a model database access is risky.

The solution

An MCP server that exposes the warehouse through read-only, documented tools, so any MCP client can answer questions from the data within set limits.

How it works

• Describe: The dbt manifest and docs describe every table
• Expose: The MCP server offers read-only query and lookup tools
• Limit: Row limits, timeouts and allowed schemas enforced
• Log: Every call logged with its query
• Connect: Tested with MCP Inspector and a desktop client

Built with

• Python
• MCP
• PostgreSQL
• dbt
• Docker

The problem

E-commerce support teams drown in order-status, return and refund messages.

The solution

A support agent that understands the request, looks up the real order, starts returns, and hands angry or complex cases to a person with the full conversation.

How it works

• Understand: A local LLM sorts each message by intent and mood, as structured output
• Look up: Agent tools query the real order in PostgreSQL
• Act: Starts a return or answers the delivery question
• Hand off: Complex or angry cases go to a person with the transcript
• Monitor: A Streamlit view of intents, resolutions and hand-offs

Built with

• Ollama
• LangGraph
• FastAPI
• PostgreSQL
• Streamlit

The problem

Quality problems hide in thousands of reviews that nobody has time to read.

The solution

A pipeline that classifies reviews by topic and sentiment, summarises them per supplier and product, and shows the results in a dashboard.

How it works

• Collect: Product reviews loaded from the marketplace
• Classify: A local LLM labels topic and sentiment as structured output
• Summarise: LLM summaries of complaints per supplier and product
• Check: Labels compared with a hand-labelled sample
• Report: A Gradio dashboard per supplier

Built with

• Ollama
• Pydantic
• Python
• Gradio
• DeepEval

The problem

Arabic and dialect searches return nothing on most stores, and the sale is lost.

The solution

Product search and questions in Arabic and English, matching queries to products with multilingual embeddings and answering product questions from the listings.

How it works

• Normalise: CAMeL Tools cleans Arabic spelling and diacritics
• Embed: bge-m3 multilingual embeddings for queries and products
• Search: Qdrant returns the closest products
• Answer: A local LLM answers product questions from the listing
• Evaluate: Hit rate on the translated test queries

Built with

• CAMeL Tools
• bge-m3
• Qdrant
• Ollama
• Gradio

The problem

Buyers sign or renew suppliers without checking news, financial and delivery risk signals.

The solution

A research agent that searches the web and the supplier master, gathers risk signals, and writes a short brief with sources for a buyer to review.

How it works

• Plan: A LangGraph agent plans the research steps
• Search: Web search and the supplier master through MCP tools
• Gather: Risk signals stored with their sources in Chroma
• Write: The brief written with citations
• Review: A buyer approves or edits the brief

Built with

• LangGraph
• Ollama
• MCP
• FastAPI
• Chroma
• Langfuse

The problem

AI bills grow with no owner and no limits, and private data can leak into prompts.

The solution

A self-hosted gateway in front of every model that tracks cost per department, caps spending, caches repeat questions and removes personal data before it reaches a model.

How it works

• Route: LiteLLM routes each request to the right model
• Protect: Presidio removes personal data from prompts
• Cache: Redis caches repeat questions
• Limit: Budgets and rate limits per department
• Trace: Langfuse records cost and response time

Built with

• LiteLLM
• vLLM
• Redis
• Presidio
• Langfuse
• FastAPI

The problem

Generic models misread Egyptian dialect messages, so bots send the wrong answer.

The solution

A small open model fine-tuned with QLoRA on Egyptian Arabic shopper messages, quantised to run locally, and compared with the base model on the same test set.

How it works

• Prepare: Support messages translated into Egyptian Arabic and checked by hand
• Train: QLoRA fine-tuning with Unsloth on a free GPU
• Quantise: Exported to GGUF for local use
• Serve: Runs in Ollama
• Compare: Accuracy against the base model, tracked in MLflow

Built with

• Unsloth
• Transformers
• PEFT
• QLoRA
• Ollama
• MLflow

The problem

Customers and drivers call to ask when and where an order will arrive, and the phone never stops.

The solution

A voice agent that answers delivery calls, looks up the order and its expected date, and passes anything unusual to a person.

How it works

• Listen: faster-whisper turns speech into text
• Understand: A local LLM with tool calling finds the intent
• Look up: The order and delivery dates from PostgreSQL
• Reply: Piper speaks the answer back
• Hand off: Unusual calls passed to a person

Built with

• Pipecat
• faster-whisper
• Ollama
• Piper
• FastAPI
• PostgreSQL

The problem

A developer or brokerage selling units in Egypt's growth areas checks competing listings by hand now and then, so nobody can say how its asking price per m² compares with the units around it, or who cut their price.

The solution

A weekly pipeline reads the asking prices on the main listing sites, checks every row, keeps each price with its week, and compares our units with the same type in the same area, by compound and developer, in Power BI.

How it works

• Collect: Asking prices for units for sale read every week from the listing sites, area by area
• Check: Every row needs a price, a size, an area and a type; a row that fails is set aside with its reason
• Store: Every asking price kept with its week and never overwritten, so a price cut can be shown
• Compare: Each of our units against the competing listings of the same type in the same area, by compound and developer
• Report: Power BI pages of the gap by area, compound and developer, and of who cut prices

A closer look

The code

"source": source,
"source_listing_id": str(listing_id),
"url": url,
"area_id": area_id,
"compound": " ".join(compound.split()) if compound else None,
"developer": " ".join(developer.split()) if developer else None,
"unit_type": unit_type(label),
"bedrooms": integer(bedrooms),
"bathrooms": integer(bathrooms),
"size_m2": decimal(size),
"asking_price": decimal(price),
"listed_on": listed_on,

The impact

• Our asking price per m² set against the market every week, area by area.
• The areas and units where we ask most above the median of their type.
• Every price kept with its week, so a competitor's cut shows up the week it happens.
• Rows that fail a check set aside with their reason, never dropped.

The result

5,619 competing listings from 6 sites in 6 areas read and checked, 1,152 compound names and 307 developers covered; our units' widest gap is +7.4% in 6th of October, and 41 rows (0.7%) were set aside with their reason.

Built with

• Python
• Airflow
• PostgreSQL
• Playwright
• Docker
• Power BI

The problem

An Egyptian spare-parts retailer sells the same belts, filters and spark plugs as a dozen online shops whose prices move every week, so nobody can say which competitor is cheaper on which part until the customer has bought elsewhere.

The solution

A weekly pipeline reads the prices of 13 online sellers, checks every row, keeps each price with its date, finds the same part at each seller by its part number, and emails when a competitor goes below our price, with the gaps in Power BI.

How it works

• Collect: Prices read every week from the sites of 13 Egyptian spare-parts sellers
• Check: Every row checked before it is stored; a bad row is set aside with its reason, never lost
• Store: Every price kept with its date in a warehouse, so changes become history
• Match: The same part found across sellers by its part number
• Report: An email when a competitor cuts a price below ours, and Power BI pages of the gaps

A closer look

The code

offers.append({
    "listing_key": str(p["id"]),
    "title": p["title"],
    "price": price,
    "currency": "EGP",
    "is_discounted": bool(price and was and was > price),
    "url": f"{base}/products/{quote(p['handle'])}",
    "brand": (p.get("vendor") or "").strip() or None,
    "part_no": scrape.part_code(variant.get("sku")),
    "in_stock": variant.get("available"),
})

The impact

• Every competitor price read each week, with no one browsing.
• The parts where a competitor sells below us, seller by seller.
• Every price kept with its date, so a one-week promotion stands apart from a new normal.
• Rows that fail a check set aside with their reason, never dropped.

The result

28,825 prices from 13 sellers in one weekly run: 88 of the 154 parts sold under the same part number (57.1%) have a seller at least 5% below the market's middle price.

Built with

• Python
• Web scraping
• Airflow
• PostgreSQL
• Power BI