{ } Software Engineer Blog
May 8, 2026 · Przemyslaw Gilewski

Personal OS — what I'm building and why

First post. The shape of the system underneath plantir.garden, posadz.garden, and this blog — and why one operator runs three public sites with one shared schema.org graph.

· meta· personal-os· infrastructure

I’m Przemyslaw Gilewski. I run a single-greenhouse telemetry pipeline, a master’s thesis on edge-vs-cloud IoT, and three public sites that talk to each other. This is the first post on the third site, and it’s about the system underneath all of it.

What “personal OS” means

Not a literal operating system. A personal OS is the stack of software, hardware, and writing surfaces an operator builds over time to absorb the recurring problems in their own life. Daily problems become services; services become infrastructure; infrastructure becomes the floor for the next problem. After a while you stop solving the same things twice.

The repository this blog ships from is the personal OS. It runs:

  • Aircraft scraping (the original surface, still alive)
  • Reddit / WSB sentiment + daily-thread parsing
  • A real greenhouse: ESP32 sensors, capacitive moisture probes, a Raspberry Pi hub, automatic watering
  • News scraping across 14 outlets
  • A music library, scale companion, sound-pack store
  • Print-job queue for a thermal printer
  • An AI usage tracker, a job queue, and an alarm system that watches itself
  • A Chrome extension that intercepts Instagram and asks me what I was actually looking for

It’s not all in production. Some of it is half-built. Some of it embarrasses me. All of it is documented in one ROADMAP.md and audited in one CLAUDE.md, which is how a single operator can keep this many surfaces honest without losing the thread.

Three public sites, three audiences

The personal OS lives on a private monorepo. The public surface is three Astro sites, each pointed at a different audience:

  • plantir.garden — the product brand, English. Live sensor dashboard, master’s-thesis hub, and a citable URL for the September 2026 defence. Visual identity is dossier-dark, deliberately parodying intelligence-platform marketing applied to one tomato plant. (plantir.garden)
  • posadz.garden — the consultancy umbrella, Polish-language. The human author surface for smart-greenhouse work in Poland, sitting above Plantir as a brand. Warm cream substrate, terracotta accents, Polish blog separate from the English one. (posadz.garden)
  • softwareengineerblog.com — this blog, English. Long-form on the engineering underneath the other two sites: firmware, AWS Lambda, Aurora, the bits most blog posts skip. Cool gray, blue link accent, no parody, no Polish.

Three sites. One operator. One shared schema.org entity graph that links them all so search engines see them as a coherent property cluster instead of three orphans. The shared infrastructure (sites/_shared/) is plain TypeScript — no npm workspace, no build overhead, just a path alias and a bundle of JSON-LD builders that guarantee the sameAs lists stay symmetric across all three sites.

What’s actually working

Honest list, dated 2026-05-08:

  • The greenhouse rig has been recording temperature, humidity, soil moisture, and air quality continuously since early 2026, with one notable gap (more on that later).
  • An alarm system fans out to Discord, email, SMS, a piezo buzzer on the Pi, and an LED. Configurable rules, sink dispatcher, unified history.
  • A Chrome extension intercepts every navigation to instagram.com with a fullscreen “what are you actually looking for?” page, then deep-links to the scraping app with the parsed intent. Intentional is better.
  • A scrapers backend (10 brokers) runs on AWS Lambda + Aurora Serverless v2, with all cadences driven by a single scraper_configs table — edit the row, not the YAML.
  • A 1M-token Claude harness writes most of this code (including this post, until the operator edits the voice).

What’s not working

Equally honest:

  • The public sensor exporter (the Lambda that ships latest.json to S3 every 5 min) is drafted and parked. It’s gated on a sensor- liveness watchdog reaching production, because shipping a public dashboard over a silently-failing pipeline is the worst possible thing a thesis project can do.
  • The four-day silent gap on 2026-04-23 was caught by a manual row-count audit, not by any alarm. That’s a structural failure; the remediation is itself part of the methodology now.
  • The thesis chapters are skeletons. The research question, the hypothesis, the variables are real and locked. The actual prose is the work between now and August.
  • The greenhouse-kit shop (plantir.store) is deferred until the hardware bundle is reproducible end-to-end without me on the phone with the customer.

What this blog will cover

I’m not promising a posting cadence. I’m promising that when I write here, the post is going to be about the engineering underneath the personal OS — not the lifestyle of running it. Posts will dig into things like:

  • How I run three Astro sites with one Cloudflare API token and zero cross-site coupling.
  • Why the alarm system has to watch itself, and what fixing that taught me about IoT pipelines that lie.
  • The paired-measurement methodology behind the master’s thesis, and what’s actually different between edge-local and cloud-central processing of identical sensor streams.
  • The chrome-extension Instagram interception pattern, and why the “intentional is better” framing matters more than any blocker.

The thesis lives at plantir.garden/thesis/2026 and is the citable academic record. This blog is the place where I write about the system as engineering — slower, longer, less formal.

If you’ve ended up here from a thesis citation, a Polish smart- garden inquiry, or a Hacker News link to one of those posts that hasn’t been written yet — welcome. The plumbing is honest, the gaps are documented, and the data is public.

— Przemyslaw