A family member wanted to start a dropshipping business. I wanted to build something useful.

Starting with Shopify

The first phase was straightforward: set up the store, pick a theme that felt right for the brand, connect a supplier, and get the first products listed. Shopify handles the storefront well. The onboarding is polished, the admin is clean, and within a weekend you can have something that looks legitimate.

But once you are past the initial setup, the reality of running an e-commerce store sets in. Orders come in at odd hours. A product goes out of stock on the supplier's end and you only find out when a customer complains. You are constantly toggling between the Shopify admin, supplier portals, email threads, and spreadsheets — and none of them talk to each other.

That is the problem we were not prepared for. Not the technical one. The operational one.

The Problem with Manual Operations

Within the first few weeks, there were three browser tabs open at all times: the Shopify admin, the supplier's portal, and a running Google Sheet tracking what was actually selling. It worked, but it was fragile. Any time a tab was closed or a notification was missed, something slipped.

The insight was simple: the data exists. Shopify knows every order the moment it comes in. The financial figures for a small business are not complicated — but they are scattered. The question was whether we could connect these pieces and surface the right information, at the right time, without anyone having to manually check anything.

The decision was to stop managing it manually and build a centralised dashboard instead. Not a fancy one. Just one thing that tells you, clearly, what is happening right now and what needs attention.

The Architecture

The stack I landed on was deliberately simple. I wanted zero ongoing cloud cost, which meant running everything on hardware we already owned.

┌─────────────────────────────────────────────────────┐ │ SHOPIFY STORE │ │ (Orders, Revenue, Products) │ └──────────────┬──────────────────────────────────────┘ │ Webhooks (orders) + REST (sales data) ▼ ┌──────────────────────────────────────┐ │ RASPBERRY PI (Home) │ │ │ │ ┌────────────┐ ┌──────────────┐ │ │ │ n8n │──▶│ Flask Dash │ │ │ │ Workflows │ │ (Central │ │ │ └────────────┘ │ View) │ │ │ │ └──────────────┘ │ │ │ │ │ │ │ ▼ │ │ │ ┌──────────────┐ │ │ │ │ NAS Storage │ │ │ │ │ (Documents) │ │ │ │ └──────────────┘ │ │ ▼ │ │ ┌────────────┐ │ │ │ Telegram │ │ │ │ Bot │ │ │ └────────────┘ │ └──────────────────────────────────────┘ │ ▼ 📱 Morning Telegram summary (sales records · EBITDA tracking · revenue predictions)

The Raspberry Pi runs 24/7 at home. It costs nothing to operate beyond the electricity. Here is what runs on it:

What We Built

After about three weekends of iteration, the system does the following reliably:

The result: a family member goes to sleep knowing that if anything significant happens overnight, they will know about it by morning. They wake up with a clear financial picture, documents already filed, and predictions updated. The operational anxiety that came with manual management dropped noticeably within the first week.

What I Learned

A few things stood out from this build that I keep thinking about.

The boring operational stuff matters more than the flashy tech. I could have built a React dashboard with real-time WebSockets and a beautiful data visualisation layer. I started to, briefly. Then I realised what was actually needed was a number — one number — that told you whether things were fine or not. A table in Flask and a Telegram message every morning solved that completely.

n8n is genuinely good for this use case. I had looked at it before but never built anything serious with it. For webhook-driven, event-based workflows with a mix of HTTP calls and scheduled jobs, it handles the complexity well. The visual editor makes it easy to reason about flow, and the node library covers most of what you need without custom code.

The Raspberry Pi as an always-on home server is underrated. I have several Pi projects running now and the pattern works: low cost, always available, no cloud bills, no cold starts. For anything that needs to run continuously at low compute intensity, this is a genuinely good architecture choice.

And finally: building something for someone close to you makes you care more about whether it actually works — not whether it is clever. That focus is a useful forcing function for staying practical.

What comes next: pulling in ad spend data so we can see revenue versus cost on the same dashboard. A proper analytics layer — even a simple one — would sharpen the decision-making around which products to promote. The ambition is to have the whole operational picture in one place, updating itself every night, requiring zero manual work beyond actually running the business.