Work

PEEPS

Where System Design Meets System Philosophy

About 75% of the team's daily marketplace work is automated.

Python · Flask · SQLite · JavaScript · Docker · Odoo XML-RPC · Microsoft Teams

Mar 2025 – Oct 2026


PEEPS: Where System Design Meets System Philosophy, slide 1 of 8PEEPS: Where System Design Meets System Philosophy, slide 2 of 8PEEPS: Where System Design Meets System Philosophy, slide 3 of 8PEEPS: Where System Design Meets System Philosophy, slide 4 of 8PEEPS: Where System Design Meets System Philosophy, slide 5 of 8PEEPS: Where System Design Meets System Philosophy, slide 6 of 8PEEPS: Where System Design Meets System Philosophy, slide 7 of 8PEEPS: Where System Design Meets System Philosophy, slide 8 of 8

Swipe or scroll for the full carousel.

At the company where I work, every marketplace order used to mean a small chain of manual chores. I built PEEPS to take that chain over. It watches our marketplaces, enters their orders into Odoo and alerts the team in Microsoft Teams.

Today nobody on the team enters marketplace orders by hand. I estimate that about 75% of the team’s daily marketplace work is now automated, and PEEPS does it faster than any of us could.

The problem

Not every marketplace tells you about a new order, and not always in time for the shipping cut-off. So for each order, a coworker or I had to go and check by hand. Then we recorded the order in Odoo, told the warehouse, checked stock, raised or lowered the quantity on the listing, and kept an eye on the cut-off.

None of these steps is hard. The cost is that they repeat for every order, they interrupt other work, and a missed check means a late shipment or a wrong stock level on a listing.

Nobody asked me to fix it. I noticed the pattern, and I started with a small script that nudged me when a new order appeared.

Constraints

  • The marketplaces don’t all notify you. The system had to go and look, not wait to be told.
  • There is a clock. Each order has a shipping cut-off, so “eventually” is not good enough.
  • Odoo is the live record. A wrong or duplicate order in the ERP creates real work for the warehouse and for finance.
  • A small team. There was no one to babysit a fragile tool, so it had to be safe when something goes wrong.

What I built

PEEPS works as a chain, from the marketplace to the team’s next action.

  1. Watchers look at the marketplaces and report what they see. They only read. They hold no business logic and know nothing about Odoo.
  2. The PEEPS server receives those reports and decides what they mean: which order, which items, how urgent.
  3. A durable queue stores every order before anything touches Odoo.
  4. An ERP adapter is the only part that talks to Odoo. It enters the order and reads stock.
  5. Teams alerts tell the team about new orders, low stock and approaching cut-offs. If a watcher goes quiet, that raises an alert too.
  6. Optional recommendations can add an upgrade suggestion to an eligible order in Odoo.

The name came first. I named the first version after “Peeps” from Regular Show, a giant floating eye surrounded by smaller eyes. That set the structure: “Big PEEPS” decided and reported to me, and each “Small PEEPS” did one job. It later grew into layers, but the idea stayed: one place that orchestrates, and small parts that each do one thing.

Key decisions

1. Save every order before it touches Odoo. The shortcut would be to pass each order straight to the ERP. I chose to put it in a queue first. If PEEPS crashes midway, the order is still there when it comes back. A dead watcher or a crash must never mean an order is lost silently.

2. Make replays harmless. Any system that retries will sometimes see the same order twice. I made sure a replayed order is never entered twice, even after a forced restart. I tested this on a staging copy by interrupting the system on purpose. Entering an order twice in Odoo is worse than being slow, because someone has to find and clean it up.

3. The server owns the meaning; the watchers only read. I could have put the smarts in the watchers, close to the marketplace. I kept them deliberately dumb. The watchers pass on what they see, and the server decides what it means. Marketplace pages change often, and when one does, the fix stays in one small, low-risk place and never reaches the ERP logic.

4. Put Odoo behind one adapter. Odoo logic could have been spread through the system, which would have been quicker at the start. Instead, the rest of PEEPS never speaks Odoo. That makes PEEPS not tied to one platform: a new marketplace or a different ERP plugs in without a rewrite.

5. Make every alert help someone decide. A stock alert should tell you what to do, not just what happened. No low-stock alert means you can add stock to the listing. A low-stock alert means you should start lowering it. Nobody checks stock by hand any more, because the alert already carries the decision.

Outcome

  • Orders arrive in Odoo and the warehouse hears about them, with no manual entry.
  • Stock is no longer checked by hand.
  • The team gets reminders before the shipping cut-off, and optional upgrade recommendations.
  • About 75% of the team’s daily marketplace work is automated. This is my own estimate from comparing the before and after, not a measured figure. We do other work while PEEPS handles the rest.

I don’t have a count of orders per day or hours saved, so I haven’t claimed one.

What I’d do next

The 75% is an estimate. The next step I want is to replace it with recorded measurements, so the result stands on numbers and not on my judgment.

Takeaway

A good name gave me a structure. Two quotes came to life for me. “There are only two hard things in Computer Science: cache invalidation and naming things” (Phil Karlton), and “A language will not succeed without a good name” (Donald Knuth).

All projects