DEV Community: Serhat

Building a Profit Analytics SaaS for Turkish Marketplace Sellers: Lessons Learned

Serhat — Mon, 05 Oct 2026 11:42:40 +0000

Most marketplace sellers in Turkey think they're profitable. Many of them are wrong.

I'm Serhat Topcu, founder of Netaliz. This is the honest story of building a profit analytics tool for Trendyol sellers: what worked, what surprised me, and what I'm still figuring out.

Trendyol integration live, Hepsiburada and N11 on the roadmap
Every sale broken down into 12 separate deduction items
A demo store anyone can try without signing up
An AI module that answers customer questions and learns from the seller

1. The problem was hiding in plain sight

Talking to marketplace sellers, I kept hearing the same story: sales were growing, but the money at the end of the month didn't match. They were busy, the orders were coming in, and yet the payout always felt smaller than it should be.

Trendyol's seller panel shows the commission. But the real cost of a sale includes shipping, service fees, withholding tax, VAT, returns, damaged goods and ad spend. Each has its own formula.

Sellers were trying to track this in Excel. Most of them gave up halfway.

Takeaway: The best problems are the ones people already try to solve with spreadsheets.

2. "Just calculate the profit" is never simple

I thought profit was one formula. It's twelve.

Commission isn't even a fixed number. It changes with the product's price, across multiple tiers. Raise the price by a small amount and you might drop into a different tier and earn less.

So a simple "multiply by the commission rate" approach was wrong. For price suggestions, we ended up solving it numerically: give a target margin, and the system searches for the price that actually hits it, tiers included.

Takeaway: If your domain has edge cases, they aren't edge cases. They're the product.

3. Marketplace APIs have personalities

Integrating with a marketplace API teaches you humility. Timestamps don't always line up the way you expect. Commission data changes. Returns arrive long after the original order.

The timestamp issue was a good example. An order could appear on one day in our reports and a different day in the seller's panel, depending on how the time was interpreted. To a seller, that doesn't look like a timezone detail. It looks like the numbers are wrong. We ended up adding in-app guides that explain these marketplace quirks right where they show up.

Our first sync ran on a schedule every 15 minutes. It worked, but sellers watching a live campaign wanted to see sales now. So we added webhooks for near real-time updates, with the scheduled sync kept as a safety net.

Takeaway: Never trust a single data path. Build a backup sync from day one.

4. Trust is a feature

Sellers were giving us access to their store. That's a big ask.

One of the first questions sellers asked was simple: "Can this break anything in my store?"

So we made a deliberate decision: Netaliz is read-only. It never changes products, prices or stock. API keys are encrypted with AES-256 envelope encryption, and data is hosted in Turkey.

We put this right on the landing page, not hidden in a policy document, because that question deserves a clear answer before anyone signs up.

Takeaway: In B2B, what you won't do can sell better than what you will.

5. Let people see it before signing up

People hesitated to connect their real store just to "try" a tool.

The fix was a demo store with sample data and the real interface, no signup required. Visitors can click around, see a red "loss" order, and understand the value in seconds.

Takeaway: Remove every step between curiosity and the "aha" moment.

6. AI was the feature sellers didn't ask for, but use daily

Sellers receive a constant stream of customer questions. Answering them well takes time.

We built Netaliz AI to draft replies using the product's details, the seller's brand voice and their own rules. Every answer the seller approves is stored and used as an example for similar future questions, so it gets better over time.

Nothing is sent automatically by default. The seller reviews and clicks send.

Takeaway: Human-in-the-loop isn't a limitation. Every approval is free training data.

7. What I'm still figuring out

Distribution. Building the product turned out to be the easier part.

Marketplace sellers are busy people. They don't browse software directories or read tech blogs. They live in seller groups, forums and WhatsApp chats, and they trust recommendations from other sellers far more than any ad.

Reaching them in a way that feels helpful rather than salesy is the problem I'm working on right now. Expanding to Hepsiburada and N11 is the other big challenge, since every marketplace has its own fee structure and its own API quirks.

What I'd do differently

Launch the demo store much earlier. It answers questions no landing page can.
Start marketing before the product feels "finished". It never will.
Talk to sellers before writing a single formula.

If you want to see what it looks like, here's the demo store with sample data, no signup needed: netaliz.com/demo

I'd love to hear from anyone building for a local market or integrating with marketplace APIs. What surprised you the most?

How I Built a Self-Improving AI Reply System for E-commerce Sellers with pgvector

Serhat — Mon, 05 Oct 2026 11:38:44 +0000

Marketplace sellers in Turkey get a constant stream of customer questions: "Is this table waterproof?", "Will it fit a small balcony?", "Why are the reviews so bad?". Every unanswered question is a lost sale, but writing thoughtful replies all day doesn't scale.

While building Netaliz, a profit analytics tool for Trendyol sellers, I added an AI module that drafts replies to these questions. The interesting part isn't calling an LLM. It's making the system get better every time the seller approves an answer.

Here's how it works.

The problem with "just prompt it"

My first version was simple: send the product info and the question to an LLM, get an answer back. It worked, but:

Answers sounded generic, not like the seller's brand.
The model didn't know seller-specific rules ("always say shipping takes 1–3 business days").
It made the same stylistic mistakes over and over, because nothing was learned.

Sellers were editing almost every draft. That's not automation, that's extra work.

The architecture

The final system has four layers that get assembled into the prompt:

Product context: material, dimensions, warranty, pulled from the marketplace API.
Brand voice: the seller picks a tone (friendly, corporate, or sales-focused) and defines banned words.
Template rules: hard instructions like "for shipping questions, say 1–3 business days".
Few-shot examples: previously approved answers to similar questions, retrieved with vector search.

Layer 4 is what makes it self-improving.

Storing approved answers with pgvector

Every time a seller approves a draft (or edits and sends it), we store the question, the final answer and an embedding of the question:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE approved_answers (
  id          BIGSERIAL PRIMARY KEY,
  store_id    BIGINT NOT NULL,
  question    TEXT NOT NULL,
  answer      TEXT NOT NULL,
  embedding   vector(1536),
  created_at  TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX ON approved_answers
  USING hnsw (embedding vector_cosine_ops);

Keeping this in Postgres instead of a separate vector database was a deliberate choice. The data already lives there, it's scoped per store with a simple WHERE, and it's one less service to run.

Retrieving similar examples

When a new question comes in, we embed it and pull the closest approved answers from the same store:

SELECT question, answer
FROM approved_answers
WHERE store_id = $1
ORDER BY embedding <=> $2
LIMIT 3;

Those examples go into the prompt as few-shot demonstrations. If a seller always answers sizing questions in a particular way, the model sees that pattern and follows it, without any fine-tuning.

Structuring the answer

We also give the model a fixed three-step structure, which made answers noticeably more persuasive:

Acknowledge the concern: show the customer they were heard.
Give a concrete argument: a specific fact about the product (material, warranty, dimensions).
Close with trust: offer further help.

A simplified version of the prompt assembly:

function buildPrompt(ctx: ReplyContext): string {
  return [
    `You are a customer support writer for a marketplace seller.`,
    `Tone: ${ctx.brandVoice}. Never use: ${ctx.bannedWords.join(", ")}.`,
    `Rules:\n${ctx.templateRules.map(r => `- ${r}`).join("\n")}`,
    `Product facts:\n${JSON.stringify(ctx.product)}`,
    `Structure: acknowledge the concern, give one concrete argument, close with trust.`,
    `Examples of approved answers:\n${ctx.examples
      .map(e => `Q: ${e.question}\nA: ${e.answer}`)
      .join("\n\n")}`,
    `Customer question: ${ctx.question}`,
  ].join("\n\n");
}

Keeping humans in control

By default, nothing is sent automatically. The AI drafts, the seller reviews and clicks send. Auto-send is opt-in, and even then the brand voice, banned words and template rules still apply.

This turned out to matter for two reasons: sellers trust the system more, and every human approval becomes a new training example. The review step is the learning loop.

What I learned

Retrieval beats fine-tuning for per-customer style. Each store gets its own "memory" instantly, with no training pipeline.
Postgres + pgvector is enough at this scale. Don't add infrastructure you don't need.
Human-in-the-loop is a feature, not a limitation. It builds trust and generates your best data.

If you're curious about the product side, Netaliz has a demo store with sample data, no signup needed: netaliz.com/demo.

I'd love to hear how others are handling per-user style in LLM apps. Are you using retrieval, fine-tuning, or something else?