Every developer has a portfolio of finished work. But the more interesting list is the one that never makes it onto a portfolio: the systems you would love to design properly, from the architecture up. This article is that list — not polished products, but the engineering behind the ideas I keep turning over in my head, and how I would actually build them.
I have deliberately gone into the architecture here, because ideas are easy and systems are hard. The gap between “wouldn’t it be cool if” and something that survives real traffic, real data, and real users is entirely a question of engineering judgement — the trade-offs, the failure modes, and the operational reality — and that is the part I enjoy most.
Idea One — QuizMage as an AI-Native, Event-Driven Recommendation Platform
QuizMage, the product-recommendation quiz engine I built for WooCommerce, is the seed. The version I am excited about is far larger: a multi-tenant, platform-agnostic recommendation system that any store can embed, driven by semantics rather than hand-written rules.
The core architecture
At the heart I would model every user interaction — each answer, hesitation, and click — as an immutable event in an append-only log (event sourcing). That log becomes the single source of truth, and from it I derive any number of read models (CQRS): one optimised for real-time personalisation, one for analytics, one for training data. The moment you separate the write path from the read path this way, scaling and evolving each independently stops being a fight.
Recommendations themselves move from weighted scoring to a vector-embedding model. Each product and each in-progress quiz session is embedded into the same semantic space, and matching becomes a nearest-neighbour search in a vector database. That is what lets the system recommend the right product even when nobody wrote an explicit rule for that combination — and it degrades gracefully back to classic rule-based scoring when data is thin, solving the cold-start problem instead of pretending it does not exist.
Quizzes that generate themselves
On top sits a retrieval-augmented generation (RAG) layer: point it at a store’s catalogue and it drafts a coherent, on-brand quiz — questions, branching logic, and scoring — grounded in the store’s real products rather than a language model’s imagination. The hard part is never calling the model; it is the guardrails around it: grounding every suggestion in actual catalogue data, validating the generated logic before it goes live, and keeping a human firmly in the approval loop.
Idea Two — A Demand-Intelligence Platform for Seasonal Businesses
Living in Rhodes, I see how brutally seasonality punishes small tourism businesses. The system I would build to help is, underneath, a serious piece of data engineering.
From raw signals to a forecast
It starts with a streaming ingestion layer pulling in many signals: a business’s own booking history, plus weather, ferry and flight schedules, local events, and competitor pricing. Those flow through a stream-processing pipeline into a feature store, so the exact same feature definitions power both model training and live serving — eliminating the training/serving skew that quietly ruins so many machine-learning projects.
The forecasting is probabilistic, not a single confident number. A small hotel does not need “you will sell 40 rooms”; it needs “there is an 80% chance you sell between 34 and 46”, because decisions about pricing and staffing are decisions about risk. Every model is backtested against history before anyone is asked to trust it.
Treating models as production software
What separates a demo from a product is everything around the model: a model registry for versioning, automated retraining pipelines, drift detection that notices when reality has diverged from the model’s assumptions, and shadow deployments that let a new model run silently beside the old one until it has earned promotion. This is MLOps done properly — models as living production systems, not one-off scripts.
Idea Three — A Multilingual, Tool-Using AI Agent With Real Guardrails
The third system is an AI “front desk” for small businesses — but a serious one, engineered for the two things most AI assistants get wrong: grounding and control.
Retrieval, orchestration, and tools
Every answer is grounded in the business’s own knowledge through a retrieval layer over a vector store, so the assistant speaks from real policies and prices rather than plausible-sounding invention. Above that sits an orchestration layer — effectively a state machine — that decides when to answer directly, when to call a tool (check live availability, create a booking, look up an order), and when a request has crossed into “a human needs this now” and hands over cleanly.
The unglamorous engineering that makes it trustworthy
Production-grade means the boring, essential scaffolding: an evaluation harness that scores responses against known-good answers so quality never silently regresses; defences against prompt injection; full tracing of every agent step so a wrong answer can be debugged rather than shrugged at; response caching to control both latency and cost; and a deterministic fallback for when the model is uncertain, so the system fails safe instead of failing confidently. An agent you cannot observe and cannot constrain is a liability, not a feature.
The Principles Underneath All of It
Three different systems, one shared engineering spine. These are the principles I keep returning to, because they are what separate software that demos well from software that survives contact with the real world.
- Design for failure. Every external call will eventually be slow or fail. Timeouts, retries with backoff, circuit breakers, and graceful degradation are not extras — they are the difference between a hiccup and an outage.
- Idempotency everywhere. In distributed systems, messages get delivered twice. Operations must be safe to repeat, or you will double-charge a customer and double-book a room.
- Observability first. Structured logs, metrics, and distributed tracing are not something you bolt on after an incident. You cannot fix what you cannot see, so I build that visibility in from day one.
- Tenancy and security by design. In multi-tenant systems, strict data isolation is a first-class architectural concern — enforced at the data layer, not just hoped for in application code.
- Cost as a design constraint. At scale, an elegant design that is ruinously expensive to run is a failed design. Caching, right-sizing, and knowing the cost of every request are part of the architecture, not an afterthought.
Anyone can name technologies. Engineering is choosing between them with your eyes open — understanding the trade-offs, the failure modes, and the real cost of being wrong.
Have a Hard Problem? Let’s Architect It Together
Some of these systems I will build for myself. Others are far better built with someone who lives the problem every day. If you have an ambitious idea — something that needs real architecture rather than a quick script, where the interesting part is making it scale, stay reliable, and not fall over at the worst possible moment — that is exactly the kind of work I love.
Get in touch, tell me the hard part, and let’s design something that actually holds up.