Your developer says the login system should live in its own AuthServer. Is that necessary, or is it overengineering? Here's how to tell, using a real example from a framework I build with every day.
A service account has admin access and no tenant context. This post shows the OAuth 2.1 flow that makes Claude authenticate as the real user: discovery endpoints, mock Dynamic Client Registration, JWT validation, and bearer token forwarding. (Claude's random callback ports get their own post — Series 2B.)
The Inspector proves your protocol; only Claude proves your product. This post builds the bridge middleware that lets real Claude Code authenticate — random localhost ports and all — so the client that hits a tool error is the same agent that reads your code and fixes it.
I used to build the API, wire up the UI, and call it done if the screen looked right. Somewhere in building MCP servers for a living, I noticed I'd stopped doing that — and started trusting AI to check my APIs before I ever opened Angular.
Every caching tutorial ends up polluting the application layer with GetAsync, SetAsync, and RemoveAsync. This post shows a different approach: a decorator that intercepts at the DI layer, version-based ETags that validate client caches without a round trip to the database, and why Redis becomes optional once you get the defaults right.
Most MCP tutorials show stdio — a local process Claude talks to directly. That works on your laptop, but it's not deployable. Here's how to build an MCP server in ASP.NET Core that runs over HTTP, where the tools, the transport, and the deployment story all actually make sense.
Building an MCP server for a live production system exposed every assumption the backend had made about its only consumer: an Angular UI. Here's what I learned.
A 9:1 read-write ratio is real, but it doesn't automatically mean your relational schema is wrong. A monolith on plain Postgres handles most traffic, most slow pages have cheaper fixes than re-architecting, and when a join genuinely is the bottleneck, a denormalized read table inside the same database solves it. No NoSQL or microservices required.
Managing one coding agent is a waste of your time and the resource in front of you. Orchestrating several is the point. Here's what a month of doing that actually looks like.