I was tired of bouncing between a dozen different sites just to format JSON or decode a JWT. One tab for a JSON formatter. Another for a Base64 decoder. Another for a DNS lookup. Another for an SPF validator. Browser full of bookmarks, half of them plastered with ads, most requiring an account to do anything useful. So I built MonkKit — a single place for all of them. 106 free developer tools across 10 categories.

Skills, agents, and hooks you add to .claude/ are powerful — but they are locked to one project. Every time you start a new repo you copy the same files, maintain them in multiple places, and drift out of sync. Claude Code plugins solve this: a plugin is a shareable, versioned package that carries all your customisations and can be installed in any project with one command. This post covers what plugins are, when to use them, and how to build a real one from scratch — a DevOps helper that ships a deployment skill, a pre-deploy safety hook, and an MCP server connection to your Kubernetes cluster.

Building an e-commerce site is one of those projects that sounds simple until you actually start. Payments, authentication, inventory, personalisation, image handling, email notifications, admin tools, live chat — each piece is its own rabbit hole. I built PersonalisedGifts, a full UK-market personalised gifts store from scratch, wiring all of these together into a single cohesive product. The site lets customers browse gifts by category (Mugs, Jewellery, Canvas Prints, Home Décor) or occasion (Birthday, Wedding, Christmas, New Baby), personalise their chosen item with custom text, images, fonts, or colours, and pay via Stripe (cards, Apple Pay, Google Pay, Klarna) or directly from their bank account via Tink’s open banking integration.

By default, Claude generates its response token by token without any deliberate planning step. For most tasks — answering a question, writing a function, explaining a concept — this is fine. The response comes quickly and it is good. For some tasks, it is not enough. Complex multi-step reasoning problems, ambiguous architecture decisions, intricate security analyses — these benefit from Claude thinking through the problem before committing to an answer. That is what extended thinking and adaptive thinking provide.

Building an AI agent that runs autonomously — browses the web, executes code, reads and writes files, persists memory across sessions — requires infrastructure. You need a sandbox, a process that can run for hours without your web server timing out, and a way to resume from where you left off after a network hiccup. Claude Managed Agents, launched in public beta in April 2026, offloads all of that to Anthropic.

Picking the wrong Claude model is expensive. Opus on every task costs 5x more than Sonnet for comparable results on most work. Haiku on a complex reasoning task produces worse output than just asking Sonnet. And if you are still using models from early 2025, some of them are deprecated — or will be soon. This guide covers every current Claude model, what each is good at, how much they cost, and a concrete decision framework for choosing the right one.

If you are calling the Claude API repeatedly with a large system prompt, a big document, or a long codebase context — and you are not using prompt caching — you are paying full price every time for content that has not changed. Prompt caching stores a prefix of your prompt server-side and charges 90% less to read it back on every subsequent request. For applications that repeatedly process the same context, this is the single highest-impact API optimisation available.

Spring Boot 4.0 was released on November 20, 2025. It is built on Spring Framework 7 and represents the most significant shift in the Spring ecosystem since the Jakarta EE migration in Spring Boot 3. The headline change is full modularisation — the single spring-boot-autoconfigure JAR has been split into 70+ granular modules. But that is just the start. This guide covers every change that matters, what breaks on upgrade, and what is genuinely new and useful.

There are three ways to containerise a Spring Boot application: a naive single-stage Dockerfile, a proper multi-stage Dockerfile with layered JARs, and Cloud Native Buildpacks. Each has different tradeoffs in build speed, image size, and maintenance overhead. This guide covers all three approaches, explains why layered JARs matter for CI/CD speed, and shows how to produce small, secure, production-ready images. The Problem with the Naive Dockerfile Most tutorials show this:

Running Spring Boot on Kubernetes is not just packaging the app in a container and deploying it. You need to configure health probes correctly, handle graceful shutdown so in-flight requests don’t get dropped, manage configuration without baking secrets into images, and make sure the JVM respects container memory limits. This guide covers the production-critical Kubernetes configuration for Spring Boot applications. Health Probes Kubernetes uses three probe types to manage pod lifecycle: