Book a demo
Build vs buy

A script can write one good description. A catalog is a different job.

For ecommerce teams deciding whether to build product-data AI in-house. What it costs, what breaks, and what the next twelve months look like either way.

Act 1

The cost

The first estimate is always about the prototype. The real cost is everything a catalog needs after it.

Laura, Head of Ecommerce

Our supplier feeds are a mess. Twelve thousand products, half of them with codes for titles. Can we just use AI?

Tomas, Developer

Sure. I call the model API from a script and loop over the CSV. Give me a week.

Laura, Head of Ecommerce

A week for the whole catalog?

Tomas, Developer

A week for a prototype. Then categories, missing specs, the feeds, the Latvian and Estonian versions. A few months, realistically.

Laura, Head of Ecommerce

And when a supplier changes their file?

Tomas, Developer

Then I fix the script. Again.

A made-up scenario, with made-up names. The conversation itself happens in a lot of ecommerce teams.
Question Build it yourself Norlif
Time to first results Months Days
Engineering A developer for 6–12 months (estimate) None: CSV, store connection or API
Web research for missing specs Build a crawler and a checker Built in, sources kept
Category tree matching Custom embeddings and prompts Built in: your own tree or Google taxonomy
Checks against made-up specs Build it yourself Built in
Revert and history Build it yourself Every change
XML feeds and store sync Build and maintain Included
Monthly cost Developer time + API + hosting Pro from €55 a month

An in-house build typically means 6–12 months of developer time (estimate), plus model API and hosting costs. See pricing

Act 2

The build

One LLM call per product looks simple. These are the problems that show up when you run it on a real catalog.

  1. 01

    Made-up specs

    Ask for a battery capacity the supplier never sent and the model will often invent one. It reads well, and it is wrong.

  2. 02

    Tone drifts over 10,000 products

    The same prompt writes differently on product 20 and product 9,000. Nobody notices until a customer does.

  3. 03

    Categories that don't exist

    The model suggests a sensible category, just not one from your tree. Now someone maps them by hand.

  4. 04

    Broken HTML

    Unclosed tags and stray markdown end up in descriptions and break product pages.

  5. 05

    Token costs on every re-run

    Change the prompt and the whole catalog is paid for again, including products that were already fine.

  6. 06

    Only the developer can run it

    The content team can't review, edit or approve anything without a ticket.

What you end up running

The in-house pipeline grows one script at a time. With Norlif it's one connection.

Build it yourself

10 parts to own
  1. Your store
  2. Export scripts
  3. Prompt layer
  4. LLM API
  5. Web scraper
  6. Validation scripts
  7. Category matcher
  8. Feed generator
  9. Re-import scripts
  10. Monitoring

Every box is code someone on your team writes, hosts and fixes.

Norlif

1 part to connect
  • Your store
  • Supplier files

Norlif

Copy, categories, attributes, images, checks, revert

  • Your store
  • XML feeds
  • AI assistants over MCP

Products publish on their own. Nothing to host or patch.

Act 3

The aftermath

Going live is the start. The pipeline has to keep working while models, suppliers and your team change around it.

If you built it

  • A new model version ships and your prompts start producing different copy.
  • A supplier changes the file format on a Sunday night. Monday's import fails.
  • You open a new market, and every prompt and check needs a new language.
  • The one developer who understood the pipeline takes another job.

With Norlif

  • Norlif keeps improving every week, without work on your side.
  • A changed supplier file is re-imported, not re-coded.
  • Writes in 98 languages from the same product data.
  • Your data stays yours: export it any time, and revert any change.
Timeline

Twelve months from now

Where each path usually is a year after the decision.

Build it yourself

  1. Kickoff

    Scope the script

  2. Month 1

    Prototype

  3. Month 2

    Works on 100 products

  4. Month 4

    Edge cases and bad specs

  5. Month 6

    Categories and feeds

  6. Month 9

    Maintenance

  7. Month 12

    Still maintaining

Norlif

  1. Day 1

    Demo on your products

  2. Week 1

    First import

  3. Weeks 2–4

    Whole catalog live

  4. From then on

    New products handled automatically

The in-house timeline is an estimate for a single developer. Yours may be faster or slower.

Live in days, not quarters.

See Norlif on your own products in a 30-minute demo, then decide.

Book a demo See pricing
Mantas Vaitkūnas Mantas Vaitkūnas Founder. Every demo is 30 minutes with me, on your own products.