So picture this: we’re at a bar, and I’m telling you about this project I just wrapped up. My client, Arcatech, runs a business selling mechanical parts. Sounds simple, right? Except it’s not. They deal with tons of different suppliers, many of them in Turkey, and none of the parts have predictable names. Customers message them nonstop asking “Do you have this?” and half the time they send a blurry photo of some random metal piece with zero context.

Arcatech was drowning. They were manually replying to customers, manually asking suppliers for availability and pricing, manually updating spreadsheets… everything manual. Days wasted on stuff that should’ve been automated years ago.

So I built them a custom CRM system that basically acts like a multilingual, AI-powered operations brain.

The Core Problem

They needed three things:

1. A way to manage thousands of parts across multiple suppliers.
2. A way to quickly answer customers, even when the customer doesn’t know what the part is called.
3. A way to talk to suppliers automatically many of whom only respond via WhatsApp.

And they wanted all of this in a single workflow, fast, clean, and real-time.

The Solution I Built

I built the whole system using Elixir + Phoenix LiveView, because nothing beats Elixir for real-time processes and fault-tolerant workflows. The CRM lets Arcatech:

• upload and manage parts catalogs
• receive customer requests with photos
• let an AI agent identify the part using LLMs
• query suppliers automatically via WhatsApp
• collect availability, pricing, and shipping
• update MongoDB in real time
• present the final price for Arcatech to approve
• and then automatically send the final quote to the customer in their language

So instead of hours of back-and-forth, things happen in minutes.

The AI Agent Workflow

Here’s how the “AI agent” actually works under the hood:

1. Customer sends a message or a photo
2. The user might not know the part’s name. No problem, I run the image through an LLM to classify it and match it to known catalog items (or similar items).
3. Agent prepares a supplier inquiry
4. For parts not in stock, the agent sends a message to one or multiple suppliers.
5. Suppliers respond on WhatsApp, because that’s how they actually do business.
6. Responses get parsed automatically
7. My agent extracts availability, expected delivery time, pricing, shipping cost, etc.
8. Database updates
9. Everything gets stored automatically in MongoDB Atlas.
10. I use MongoDB because it’s flexible, handles nested item structures nicely, and works well with my agent’s vector search.
11. Pricing approval
12. The agent asks Arcatech:
13. “Customer needs this part. Supplier price is X. How much should we charge?”
14. Arcatech confirms the final price.
15. Agent replies to the customer (multilingual)
16. For translation, I use Gemini (fast + cheap)
17. For reasoning, workflow, and conversations, I use GPT-5 (preview).
18. Together, they’re more than enough.

The WhatsApp Problem

This was the funny part. WhatsApp doesn’t have an official free API for this kind of workflow you either use the paid Business API or you reverse-engineer WhatsApp Web.I found a Go library called Whatsmeow

which basically gives you a stable WhatsApp Web client with message sending/receiving support. The problem? It’s Go, not Elixir.

I had two options:

1. Write an Elixir wrapper around their WebSocket implementation
2. would take too long
3. not worth the pain
4. and if something breaks, I’m debugging WhatsApp protocols at 3 AM.
5. Build a separate Go microservice dedicated to WhatsApp
6. simple
7. stable
8. easy to scale

Obviously, I went with option 2.

The Architecture

Here’s what the final architecture looks like:

• Elixir / Phoenix LiveView app
• Runs the CRM app, business logic, AI agent logic, dashboards, and all workflows.
• Hosted on Fly.io, with 2 Elixir nodes for redundancy.
• Go microservice using Whatsmeow
• Keeps a persistent WhatsApp Web session alive.
• Talks to the Elixir nodes via WebSockets.
• Reliable, stateless, and easy to scale horizontally.
• Hosted on Fly.io as well.
• MongoDB Atlas (cloud)
• Stores all customer requests, parts catalogs, supplier responses, vector embeddings, and conversation states.
• LLM stack
  • GPT-5 for reasoning, workflows, and messaging
  • Google Gemini for translation and embeddings
  • Embeddings stored in MongoDB for quick retrieval of similar parts

Everything together forms a fully automated sales pipeline that works across languages, countries, and messaging apps.

Why Not Use an Elixir Node for WhatsApp?

I considered using goerlang/node

The idea was to make the Go process behave like an Erlang node and join the BEAM cluster.

But that brings headaches:

• full mesh networking
• cluster splits across regions
• node naming issues
• debugging distributed systems for no good reason

A simple WebSocket between Go and Elixir is:

• cleaner
• safer
• easier to scale
• easier to monitor
• easier to deploy

Sometimes the boring solution is the right one.

Deployment Setup

Everything runs on Fly.io because:

• easy clustering for BEAM apps
• private networking between services
• automatic failover
• simple scaling

I have:

• 2 Elixir instances (Phoenix LiveView)
• 1 Go instance (WhatsApp connector)
• MongoDB Atlas external
• LLM APIs external

This setup handles concurrency beautifully.

The Final Result

Arcatech now handles customer requests in minutes, not hours.

• No more manual supplier messaging
• No more searching WhatsApp for old conversations
• No more confusion about which part is which
• No more language barrier
• Real-time, AI-assisted pricing
• Fully traceable conversation history
• Clean customer–supplier workflow

And the best part?

We built everything in around 4 weeks.