I'm a software engineer by trade. Eight years in, mostly C# and Angular, mostly enterprise systems. The day job is great but some of the best education has come from the stuff I've built on the side, after hours, for no reason other than I thought "I could probably build that."

Some of it made money. Most of it didn't. All of it taught me something.

The Twitter Scheduler (~2020)

Back when Hypefury was gaining traction and everyone was talking about "building in public" on Twitter, I thought the scheduling space was ripe for competition. So I built one. A Twitter scheduling tool, from scratch.

It worked. You could queue tweets, schedule threads, set posting times. The core functionality was solid. I used it myself for a while.

It never went anywhere commercially. No users beyond me, no launch that stuck, no revenue. I built the product but never really built the distribution. Classic engineer mistake: assuming the hard part was the code. The hard part was getting anyone to care.

What I learned: a working product and a viable business are two completely different things. I could build Hypefury's feature set, but I couldn't build Hypefury's audience. That distinction changed how I thought about every project after it.

OpenClaw

My daughter's creche uses an app called Childpaths to log meals, naps, and activities throughout the day. The app works, but it's pull-based. You have to open it, scroll around, check what happened. My wife and I both wanted the information pushed to us without the faff.

So I built OpenClaw. It scrapes Childpaths, pulls the day's food and medicine entries, runs them through an LLM to generate a summary with a bit of humour baked in, flags any anomalies (skipped meals, medication changes, anything out of the ordinary), and fires the whole thing to a Telegram channel that my wife and I both follow.

The LLM layer is the interesting part. Rather than just forwarding raw data, it writes the updates in a way that's actually enjoyable to read. A dry "Breakfast: Toast. Consumption: Ate None" becomes something you'd smile at over your morning coffee. It also spots patterns and oddities that you might miss scanning a list of entries manually.

It can fail sometimes. That's the nature of LLMs, and I deliberately didn't add evals. This isn't a medical device. It's a convenience tool for two parents who want to know if their daughter ate her lunch without opening another app. When the LLM hallucinates or misreads something, it's mildly annoying, not dangerous. The raw data is always there in Childpaths as the source of truth.

Nobody else will ever use this. It solves a problem for exactly one family. But it runs, it's reliable enough, and it's the kind of project that reminds me why I got into engineering in the first place. No stakeholders, no sprint planning, no pull request reviews. Just a problem and a solution.

The Nappy Price Scraper

Same energy as the creche tracker, different problem. Nappies are expensive and the price fluctuates across Dunnes, SuperValu, and Tesco. I wanted to know who had the cheapest Pampers on any given day without manually checking three websites.

Built a Python scraper using Playwright that hits all three retailers, extracts prices (handling cookie banners, lazy-loaded content, and HTTP/2 protocol issues along the way), and posts a comparison to Telegram. Logs everything to CSV for historical tracking.

Getting it working on Tesco was a headache. HTTP/2 errors, anti-bot measures, dynamic pricing elements. SuperValu was the easiest. Dunnes fell somewhere in between. The retailer-specific selector logic and retry mechanisms ended up being more complex than the actual comparison logic.

Deployed it as a scheduled container job. Runs daily. Half works :D

The Driving Theory Test App (Explored, Not Shipped)

Looked into building a better version of Ireland's driving theory test app. The existing one has UX issues and feels dated. My plan was an Angular web app with an adaptive question bank, better explanations, and progress analytics.

Got as far as scoping the content challenge (RSA questions are copyrighted, so you'd need original questions covering the same material) and the business model (freemium with a one-time unlock). Decided the content creation effort was too high for a side project and parked it.

RSA questions being copyrighted is a bit of a joke!

Small WordPress Sites

Before Ghost, there was WordPress. I built a handful of small sites over the years, mostly to understand the ecosystem from the inside: hosting, themes, plugins, the whole stack.

None of these sites were world-changing. They were small, functional, purpose-built. But building them taught me things I wouldn't have learned from my day job. How shared hosting actually works. Why managed WordPress hosts charge what they do. How plugin conflicts can take down a site at 2am. The difference between a theme that looks good in a demo and one that performs well in production. How SEO plugins work under the hood versus what they promise on the tin.

More importantly, working with WordPress gave me an appreciation for the non-engineer's experience of the web. When your day job is C# and Angular, it's easy to forget that most of the internet runs on PHP, MySQL, and a prayer. Understanding that world made me a better engineer, even though I never wrote a line of WordPress core code.

eamonkeane.dev — Self-Hosted Ghost

The blog you're reading this on is itself a project. I run Ghost as my CMS, self-hosted, on my own infrastructure at eamonkeane.dev.

I could have used Medium, Substack, WordPress.com, or any number of managed platforms. But I wanted full control: my domain, my data, my design, my deployment pipeline. No algorithmic feed deciding who sees my posts. No platform risk where someone else's business decision kills my archive overnight.

Self-hosting Ghost means dealing with server setup, SSL certificates, updates, backups, email delivery configuration, and the occasional 3am "why is the site down" investigation. It's not difficult work for someone who spends their days in Azure, but it's a different kind of responsibility than writing code that someone else deploys. When it breaks, it's on me.

Self-Hosted n8n and the Farm Receipt Automation

I also self-host n8n, the workflow automation platform. Same philosophy as Ghost: I'd rather run my own instance than depend on someone else's pricing tier and uptime guarantees.

Most of my n8n workflows are simple glue. But the one I'm most proud of solves a genuinely tedious real-world problem: filing farm receipts.

I run a farm with my father in Maam, County Galway. Farming generates a relentless stream of receipts. Feed, diesel, vet bills, parts, fencing supplies. They pile up in jacket pockets, glove compartments, and kitchen counters. Come tax time, you're sorting through crumpled bits of paper trying to remember what you bought in March and which category it falls under.

The automation works like this: I snap a photo of the receipt on my phone and send it to a Telegram bot. n8n picks it up, sends the image to Gemini for extraction, and gets back structured JSON with the vendor, amount, date, and line items. The workflow then categorises the expense (feed, fuel, veterinary, machinery, etc.), files the receipt image away for future reference, and updates a Google Sheet that serves as the running ledger.

The whole thing takes about five seconds from my side. Photo, send, done. No manual data entry, no spreadsheet wrangling, no shoeboxes of paper.

It's not perfect. Gemini occasionally misreads a smudged total or guesses the wrong category for an ambiguous purchase. But it's right often enough that correcting the odd mistake is still faster than doing it all by hand. And the Google Sheet gives me and my father a live view of farm expenses without either of us having to sit down and "do the books."

This is the kind of automation that doesn't look impressive in a portfolio but saves real hours every month. Nobody's going to put "farm receipt OCR pipeline" on a conference talk abstract. But when January comes around and the accountant needs the numbers, everything's already there.

What Ties These Together

Looking at this list, a pattern emerges. I'm drawn to problems that annoy me personally. Creche app inconvenient? Scrape it, add an LLM, pipe it to Telegram. Nappy prices unpredictable? Automate the comparison. Farm receipts piling up? Point a camera at them and let Gemini sort it out. Want a blog? Host it yourself.

Not all of these projects made money. Most didn't. The Twitter scheduler taught me that building the thing is the easy part. The WordPress sites taught me that most of the internet doesn't work the way enterprise engineers think it does. OpenClaw taught me that imperfect automation still beats manual checking. The farm receipt pipeline taught me that the most valuable automations are often the most boring ones. And self-hosting Ghost taught me that owning your platform is worth the overhead.

The through-line isn't technical skill. It's the habit of seeing a friction point and deciding to fix it with code. That instinct is worth more than any framework or language on a CV. Frameworks change. The itch to build doesn't.