Cynara

How we think about building AI that lasts.

Every AI project eventually runs into the same questions. Model or software? Cloud or on-prem? Buy or build? Fine-tune or retrieve? Where does compliance begin? What happens if we want to leave a provider in three years? These aren't AI questions — they're engineering questions.

We've spent decades building production software through changing languages, frameworks, platforms, and architectures. AI is another technology wave, not an exception to the fundamentals. This is where we write about the decisions that matter after the prototype: ownership, economics, engineering, and governance. No hype. No trend chasing. Just practical thinking from people who build systems for a living.

Four themes.

01

Ownership

Who controls your AI once it's in production?

The easiest system to build is often the hardest to leave. We explore vendor lock-in, private AI, open-weight models, data ownership, and how to design systems that stay yours — even when today's technology changes tomorrow.

Upcoming essays

  • What it really means to own an AI system
  • Why vendor lock-in happens quietly
  • Designing an exit strategy before you need one
02

Economics

The costs that begin after the pilot succeeds.

Most AI business cases stop at the prototype. Production is where the real economics begin: token pricing, GPU utilisation, infrastructure, maintenance, and operating cost over years rather than months. AI should make financial sense long after the excitement fades.

Upcoming essays

  • API pricing vs owning your infrastructure
  • When GPUs become cheaper than tokens
  • Building a realistic five-year AI business case
03

Engineering

Turning prototypes into dependable systems.

Connecting a model is rarely the difficult part. Building software that stays reliable, observable, secure, and maintainable is where engineering earns its keep. We write about architecture, integration, testing, deployment, and the decisions that separate production systems from impressive demos.

Upcoming essays

  • MCP explained without the buzzwords
  • Retrieval, fine-tuning, or neither?
  • Production architectures for AI systems
  • The engineering checklist before you deploy
04

Governance

Building AI that survives legal and organisational reality.

Compliance shouldn't be an afterthought. From GDPR and the EU AI Act to audit trails, data residency, and governance, we explore how to design systems that satisfy regulators without slowing delivery. Good governance isn't bureaucracy — it's good engineering.

Upcoming essays

  • GDPR and AI in practice
  • Understanding the EU AI Act
  • Data residency and private AI
  • Designing AI for regulated organisations

A point of view.

Technology changes. Good engineering doesn't.

We've seen programming languages come and go. We've watched architectures rise and fall. We've migrated systems that outlived the companies that built them. AI is transforming what's possible — but it doesn't replace the principles that make software dependable. The organisations that succeed won't necessarily use the newest model; they'll build systems that are understandable, maintainable, economically sensible, and designed to evolve. That's the perspective we'll keep exploring here.

Rather talk than read?

Every organisation starts from a different place. Articles can explain principles, but they can't understand your systems, your constraints, or your goals. If you have a question about AI, software architecture, private infrastructure, or where AI genuinely fits, let's have the conversation — no sales pitch, no generic presentation, just an honest technical discussion with the people who build these systems.