![\"Coolify](\"https://ansezz.com/blog/coolify-self-hosted-saas/features.webp\")
Most SaaS founders are quietly getting robbed by their own cloud provider.
\nI have spent over a decade building and scaling web applications, and if there is one thing I have learned, it is that the \"cloud tax\" is the most effective way to kill your margins before you even find product-market fit. We have been conditioned to believe that unless our small CRUD app is running on a multi-region, auto-scaling AWS EKS cluster, we are doing it wrong.
\nThat is a lie designed to keep you paying for complexity you do not need.
\nIt starts innocently enough. You sign up for AWS or GCP because they give you $1,000 in credits. You spin up an RDS instance for your database, a few S3 buckets for storage, and maybe a managed Kubernetes service because it feels \"professional.\"
\nThen the credits run out.
\nSuddenly, you are paying $200 a month for a database that is 99% idle. You are paying for NAT gateways, provisioned IOPS, and \"management fees\" for services that could easily run on a $5 VPS. You are stuck in a web of proprietary APIs and IAM roles that require a full-time DevOps engineer just to update an environment variable.
\nThis is the agitation: managed services feel like a superpower at the start, but they become a golden cage as you scale. The complexity overhead alone is enough to slow your development velocity to a crawl. When I look at how AI is changing traditional development, it becomes clear that we need to move faster, not get bogged down in infrastructure molasses.
\n
The solution I have moved my entire stack to is Coolify.
\nCoolify is an open-source, self-hostable alternative to Vercel, Heroku, and Railway. It gives you that same \"git push to deploy\" experience we all love, but it runs on your own hardware. Whether you have a $4 VPS on Hetzner or a massive ARM-based instance on Oracle Cloud, Coolify turns it into a private PaaS.
\nI recently wrote about how Coolify and Docker are changing SaaS hosting, but the shift is deeper than just a tool change. It is a mindset shift toward technical sovereignty.
\nHere is what makes Coolify a game-changer for a senior engineer:
\nIf you want to see a 90% reduction in your infrastructure bill, you need to stop using x86 and start using ARM.
\nAWS Graviton instances are roughly 20-40% cheaper and more performant than their Intel-based counterparts. But the real \"cheat code\" right now is Oracle Cloud Infrastructure (OCI). Their \"Always Free\" tier gives you 4 ARM Ampere A1 cores and 24 GB of RAM for free.
\nI can run an entire production SaaS — frontend, backend, database, and Redis — on that single free instance using Coolify.
\nWhen you pair ARM efficiency with a self-hosted orchestrator, the math changes. A startup that was paying $500/month on AWS can often move that entire workload to a $40/month ARM instance on Hetzner or OCI. That extra $460 goes back into your pocket or your marketing budget.
\n![\"Architecture](\"https://ansezz.com/blog/coolify-self-hosted-saas/architecture.webp\")
Coolify relies heavily on Docker, which is the industry standard for a reason. It ensures that what works on my machine works on the server. But as I move deeper into the \"vibe coding\" era, I'm also looking at how technologies like Nix can further stabilize our environments.
\nBy using Nix flakes to define our development environment and Docker to package the runtime, we create a bulletproof deployment pipeline. When I use tools like the Model Context Protocol (MCP), I want my AI agents to have a clear, reproducible environment to work within. Self-hosting doesn't mean \"unprofessional\" — it means having total control over the stack.
\nLet's look at the numbers for a standard Laravel or Node.js app with a database and a background worker.
\nThe managed path (Vercel + Supabase + AWS S3):
\nThe Coolify path (Hetzner VPS):
\nThe \"managed\" path is nearly 10x more expensive before you even have your first 100 users. For a senior engineer, the 30 minutes it takes to install Coolify on a fresh Linux box is worth the thousands of dollars saved over the life of the project.
\n![\"A](\"https://ansezz.com/blog/coolify-self-hosted-saas/workspace.webp\")
If you are tired of the cloud tax, here is my recommended path to freedom:
\nDockerfile. For Vite or Next.js, Coolify has built-in builders that don't even require a Dockerfile.We are entering a cycle where efficiency is the only thing that matters. The days of \"VC-subsidized\" infrastructure are over. Whether you are building a small tool or a massive enterprise SaaS, you owe it to your bottom line to look at self-hosting.
\nCoolify has matured to the point where the developer experience is indistinguishable from the big players. The only difference is who owns the keys to the castle.
\nI am curious: what is the most \"expensive\" mistake you have ever made on a cloud bill — a forgotten NAT gateway or a runaway Lambda function? Drop a note via contact. 🤘
\n", "date_published": "2026-05-30T00:00:00.000Z", "date_modified": "2026-05-30T00:00:00.000Z", "tags": [ "devops", "coolify", "self-hosting", "devops", "docker", "arm", "hetzner", "saas", "cost-optimization" ], "image": "https://ansezz.com/blog/coolify-self-hosted-saas/hero.webp" }, { "id": "https://ansezz.com/blog/laravel-octane-high-traffic/", "url": "https://ansezz.com/blog/laravel-octane-high-traffic/", "title": "Laravel Octane: making PHP scream on high-traffic apps", "summary": "Standard PHP rebuilds the whole kitchen for every request. Laravel Octane boots once, stays warm in memory, and feeds requests through a worker pool — taking 50ms responses down to single digits. Swoole vs RoadRunner, worker-pool tuning, and surviving persistent state without memory leaks.", "content_html": "Standard PHP is a bit like a restaurant that fires its entire staff and rebuilds the kitchen from scratch for every single customer order. You walk in, they hire a chef, buy a stove, cook your meal, and then demolish the building as soon as you leave. It's consistent and safe, but it's a massive waste of energy when you're trying to serve thousands of people at once.
\nThis is the PHP-FPM lifecycle. Every request boots the entire Laravel framework, loads your service providers, parses your config, and instantiates your objects. For low-traffic sites, it's fine. But when you hit real scale, those milliseconds of \"boot time\" become a wall you can't climb without throwing excessive amounts of expensive hardware at the problem. Horizontal scaling buys you room, but it doesn't fix the underlying latency.
\nThe solution is to stop rebuilding the kitchen. Laravel Octane changes the game by booting your application once, keeping it in memory, and then feeding requests to it through a high-performance worker pool. It transforms PHP from a \"short-lived script\" language into a \"long-lived process\" powerhouse.
\n![\"PHP-FPM](\"https://ansezz.com/blog/laravel-octane-high-traffic/fpm-vs-octane.webp\")
The overhead of traditional PHP isn't just about speed; it's about efficiency. In a standard request, your CPU spends a significant chunk of time just getting the application ready to do work. Once it finally starts execution, it does the database query, renders the view, and then dies.
\nIf you're running a complex Laravel monolith with dozens of packages and custom service providers, your boot time might be 30ms to 50ms before a single line of your actual business logic even runs. Under high traffic, this leads to CPU thrashing. You're paying for the \"setup\" over and over again.
\nLaravel Octane removes this boot cycle. By using high-performance application servers like Swoole or RoadRunner, your app stays resident in memory. The first request boots the framework, and subsequent requests hit a \"warm\" application. We're talking about moving from 50ms responses to sub-10ms responses just by changing how the process is managed.
\n![\"Swoole](\"https://ansezz.com/blog/laravel-octane-high-traffic/swoole-vs-roadrunner.webp\")
When you drop Octane into your project, you have to choose between two primary engines: Swoole and RoadRunner. I've used both in production, and while they both solve the \"persistent state\" problem, they do it differently.
\nSwoole is a C++ extension for PHP. It's essentially a high-performance networking engine that allows PHP to handle asynchronous tasks, coroutines, and long-lived connections.
\nRoadRunner is written in Go. It acts as a load balancer and process manager that communicates with your PHP workers via a high-speed binary protocol (Goridge).
\nFor most developers starting out with Octane, I recommend RoadRunner for the ease of use. If you are chasing every last millisecond and need features like async task workers, go with Swoole.
\n![\"A](\"https://ansezz.com/blog/laravel-octane-high-traffic/worker-pool.webp\")
The secret sauce of Octane is the \"worker pool.\" Instead of one process per request, you have a fixed number of workers waiting to handle incoming traffic. If you misconfigure this, you'll either leave performance on the table or crash your server.
\nA general rule of thumb for sizing your worker pool depends on whether your app is CPU-bound or I/O-bound.
\n# Starting Octane with 16 workers for an I/O-heavy app\nphp artisan octane:start --server=swoole --workers=16\nDon't forget about task workers if you're using Swoole. These are separate from your HTTP workers and are perfect for offloading slow tasks like sending emails or processing webhooks without blocking the main request cycle.
\n![\"Hunting](\"https://ansezz.com/blog/laravel-octane-high-traffic/memory-leaks.webp\")
The biggest hurdle when moving to Octane is the shift in mindset. In traditional PHP, \"leaky\" code doesn't matter much because the process dies after 100ms. In Octane, a memory leak is a ticking time bomb.
\nIf you have a static array in a service provider that you append to on every request, that array will grow until your server runs out of RAM. You have to be extremely careful with:
\nglobal variables at all costs (which you should be doing anyway).Laravel helps you by \"resetting\" some core services between requests, but it can't catch everything. If you're migrating an old codebase from monolith to microservices, you'll want to audit your service providers for any long-lived state.
\nThe best insurance policy against memory leaks is the --max-requests flag. This tells Octane to kill and restart a worker after it has handled a certain number of requests.
# Restart workers every 1000 requests to prevent memory bloat\nphp artisan octane:start --max-requests=1000\nThis keeps your memory usage predictable while still giving you the performance benefits of a warm application.
\nOnce you have Octane running, there are a few technical levers you can pull to squeeze out even more performance.
\ndatabase.php config and ensure you aren't hitting the max connection limit on your DB server.Octane::cache(). It's an in-memory table that's blistering fast. Use it for frequently accessed configuration or small datasets that don't change often.opcache.validate_timestamps=0 in production since your code won't be changing while the server is running.php artisan octane:reload. This will gracefully restart the workers without dropping current connections. It's essential for zero-downtime deployments.Transitioning to Octane isn't just about installing a package; it's about maturing your infrastructure.
\nOctane::concurrently() to execute multiple tasks at once and return their results, cutting down total response time for complex pages.Octane takes PHP to a level where it can compete with Node.js and Go for high-concurrency applications while keeping the developer experience of Laravel intact. If you're building a SaaS that expects a lot of noise, this is your jet engine.
\nAre you running Octane in production yet, or is the fear of memory leaks keeping you on PHP-FPM? Drop a note via contact — let's talk worker counts. 🤘
\n", "date_published": "2026-05-29T00:00:00.000Z", "date_modified": "2026-05-29T00:00:00.000Z", "tags": [ "laravel", "laravel", "octane", "php", "performance", "swoole", "roadrunner", "scaling", "high-traffic" ], "image": "https://ansezz.com/blog/laravel-octane-high-traffic/hero.webp" }, { "id": "https://ansezz.com/blog/shopify-ucp-quick-start/", "url": "https://ansezz.com/blog/shopify-ucp-quick-start/", "title": "Your quick-start guide to Shopify UCP: do this before June 15", "summary": "AI agents are the biggest spenders of 2026 — and they can't see your store without a UCP manifest. How the Universal Commerce Protocol works, why the /.well-known/ucp endpoint is the robots.txt of agentic commerce, and a pre-deadline checklist to make your Shopify store a first-class citizen in the AI economy.", "content_html": "Your store is effectively invisible to the biggest spenders of 2026. I'm not talking about Gen Z or Alpha. I'm talking about AI agents.
\nIf Google Gemini or OpenAI's \"Operator\" can't find a machine-readable map of your Shopify store, it won't recommend your products. It definitely won't buy them.
\nTraditional SEO was built for humans with eyeballs. The Universal Commerce Protocol (UCP) is built for agents with wallets.
\nThe rollout is moving fast. If you haven't configured your UCP manifest by June 15, you are opting out of the agentic economy.
\nHere is how to fix that.
\nFor ten years, we've obsessed over meta tags and JSON-LD schema. That was enough when Google was just a list of links. But we've entered the era of agentic commerce on Shopify.
\nAgents like Gemini don't \"browse\" your collections. They don't look at your hero banners. They want to know three things:
\nIf your site doesn't answer these questions in a standardized way, the agent moves to a competitor who does. Legacy schema tells an agent what a product is. UCP tells an agent how to transact.
\n![\"Side-by-side](\"https://ansezz.com/blog/shopify-ucp-quick-start/seo-vs-ucp.webp\")
UCP is an open standard backed by Google and Shopify. It creates a \"handshake\" between a merchant and an AI agent.
\nThe core of this handshake is the /.well-known/ucp endpoint.
It's a simple JSON file that acts as a discovery manifest. When an agent hits your domain, it looks for this file to understand your capabilities. It's the robots.txt of the AI era, but for money.
Here is what a raw UCP manifest looks like:
\n{\n \"ucp\": {\n \"version\": \"2026-01-11\"\n },\n \"role\": \"merchant\",\n \"capabilities\": {\n \"checkout\": {\n \"endpoints\": {\n \"create_session\": \"https://api.yourstore.com/ucp/checkout/sessions\"\n }\n },\n \"payment\": {\n \"handlers\": [\"shop_pay\", \"google_pay\"]\n }\n }\n}\nThis manifest tells the agent exactly where to send the payment data. No scraping required. No \"guessing\" where the add-to-cart button is.
\nIf you are running a standard Shopify or Shopify Plus store, the good news is you don't have to write this JSON manually. Shopify is baking this directly into the core.
\nBut it isn't always on by default.
\nTo ensure you're ready for the June 15 deadline, go to your Shopify admin. Navigate to Settings > Apps and sales channels. Look for Agentic storefronts.
\nOnce you toggle this on, Shopify automatically generates and hosts the manifest at your-store.com/.well-known/ucp.
If you are running a headless setup with Hydrogen or a custom frontend, you'll need to ensure your middleware correctly proxies this path back to Shopify's servers. We see a lot of developers break their agentic discovery because their Vercel or Netlify rewrites aren't handling the .well-known directory.
![\"Architecture](\"https://ansezz.com/blog/shopify-ucp-quick-start/architecture.webp\")
Why is everyone panicking about mid-June?
\nGoogle is moving \"AI Mode\" out of beta for a massive segment of search users. When Gemini becomes the default shopping assistant, it will prioritize stores that support the UCP handshake.
\nThis is also when Shopify begins its wider rollout of MCP context-aware agents. These agents use the Model Context Protocol to link your store's live data directly into the LLM's reasoning loop.
\nIf your manifest is missing, your store is a black box. The agent will see your products in the search index, but it won't be able to fulfill the request \"buy me the best hiking boots from a local store.\" It will choose the store where it can verify the checkout capability instantly.
\nDon't just flip a switch and hope. You need to verify that your manifest is actually reachable by external bots.
\nhttps://yourdomain.com/.well-known/ucp.Check your robots.txt file as well. Ensure you aren't accidentally disallowing agents from crawling the .well-known directory.
If you are using a custom Laravel backend to power your Shopify store's logic, make sure your routes file includes a specific entry for this endpoint. At ansezz, we often see custom middleware stripping out these hidden directories for \"security\" reasons. In 2026, that security is just costing you sales.
\n![\"Shopify](\"https://ansezz.com/blog/shopify-ucp-quick-start/admin-toggle.webp\")
Here is your pre-June 15 checklist:
\n/.well-known/ucp path returns valid JSON.The transition from a human-centric web to agent-centric commerce is happening whether we're ready or not. UCP is the first real step toward making your store a first-class citizen in the AI economy.
\nAre you letting agents shop your store, or are you still building for a world that clicks? Drop a note via contact — let's get your manifest live before the deadline. 🤘
\n", "date_published": "2026-05-28T00:00:00.000Z", "date_modified": "2026-05-28T00:00:00.000Z", "tags": [ "shopify", "shopify", "ucp", "agentic-commerce", "ai", "seo", "hydrogen", "shopify-plus", "agents" ], "image": "https://ansezz.com/blog/shopify-ucp-quick-start/hero.webp" }, { "id": "https://ansezz.com/blog/claude-mcp-dev-tools/", "url": "https://ansezz.com/blog/claude-mcp-dev-tools/", "title": "Claude MCP: why I'm connecting my dev tools to LLMs for real-time context", "summary": "The Model Context Protocol is the USB port for LLMs. One MCP server, any MCP-aware host — killing the M×N integration tax. How the host/client/server architecture works, the servers I run daily, and why the sandbox model makes it safe enough to plug into production.", "content_html": "Every time I have to build a custom integration for a new tool, a little piece of my developer soul dies. It is a maintenance nightmare that never ends. We have reached a point where building the actual product is often faster than setting up the pipes to make it work with our data.
\nIf you have spent any time building agentic workflows and vibe coding, you know exactly what I am talking about. You have an LLM like Claude that is incredibly smart but essentially locked in a room with no windows. To give it context, you have to manually copy-paste code, export CSV files, or spend three days writing a brittle wrapper for a third-party API just so your assistant can \"see\" your work.
\nThis fragmentation is the biggest bottleneck in modern software development. We have powerful models, but they are isolated from our local files, our databases, and our production logs. It is like having a world-class architect who isn't allowed to visit the construction site. They are just guessing based on the photos you decide to send them.
\nEnter the Model Context Protocol — or as I have been calling it: the USB port for LLMs.
\nThe problem is simple but massive. Every AI application — whether it is Claude Desktop, a custom agent, or an IDE extension — wants to talk to your data. On the other side, every data source — your GitHub repos, your Postgres databases, your Slack channels — has its own specific API and authentication flow.
\nWithout a standard, we are stuck in an M×N problem. If you have 5 AI apps and 10 data sources, you need 50 different integrations. This is why most \"AI-powered\" tools feel shallow. They only support a few basic integrations, and if you want to use your internal company data, you are back to writing custom glue code.
\nThis agitation is real. We are wasting hours building the same connectors over and over again. We are worried about security because every new integration is another potential leak. And we are frustrated because the \"magic\" of AI disappears the moment we hit a data silo.
\n![\"MCP](\"https://ansezz.com/blog/claude-mcp-dev-tools/architecture.webp\")
Claude MCP (Model Context Protocol) is the first serious attempt to standardize how AI applications discover and interact with data and tools. Instead of building a specific connector for every model and every tool, you build an MCP server.
\nThis server acts as a translator. It sits between your data and the AI, exposing a consistent interface that any MCP-compliant host (like Claude Desktop) can understand. It is exactly like the USB standard. It doesn't matter if you are plugging in a mouse, a keyboard, or an external drive. The protocol is the same, so it just works.
\nThis shifts the entire paradigm of context-aware agents. Instead of hard-coding logic into the agent, you simply \"plug in\" the servers you need.
\nThere are three main players in the MCP ecosystem:
\nFor example, if I want Claude to have access to my local project files, I run a local MCP server that exposes those files as \"resources.\" The host (Claude Desktop) asks the server: \"what do you have?\" The server replies: \"I have these 10 files and a tool to run grep searches.\"
\nThe model can then decide to call the \"grep\" tool whenever it needs to find a specific function definition. I didn't have to write a single line of logic inside Claude to make that happen. I just connected the server.
\n![\"A](\"https://ansezz.com/blog/claude-mcp-dev-tools/servers.webp\")
The beauty of this modularity is that once a server is built, anyone can use it. The community has already started building servers for everything you can imagine. I have been using a few in my daily workflow that have completely changed how I code:
\nThis also solves a massive pain point in agentic commerce for Shopify. Imagine an agent that can talk directly to your Shopify store via MCP to check inventory levels or update product descriptions in real-time, all while maintaining a secure, standardized connection.
\n![\"Sandboxed](\"https://ansezz.com/blog/claude-mcp-dev-tools/security.webp\")
The biggest question I get when I talk about connecting dev tools to an LLM is: \"is it safe?\"
\nSecurity is baked into the design of MCP. Because the server is a separate process, it runs in its own sandbox. It only has access to the specific resources you grant it.
\nFor local servers, the protocol typically uses stdio (stdin/stdout). This means the server can only talk to the host through a very narrow pipe. It doesn't have open network ports listening for connections. It only exists as long as the host is running it.
For remote servers, MCP uses OAuth 2.1. This allows for fine-grained permissions. You can authorize a GitHub MCP server to only read public repositories, or a database server to only access specific tables.
\nThis is a huge improvement over the \"give me your master API key\" approach that we have seen in the past. We can now treat AI tools with the same \"least privilege\" mindset we use for any other service in our stack. This is especially important when you are trying to avoid RAG mistakes in production, where data leakage is a top-tier risk.
\nI have been a developer for over a decade, and I have seen plenty of \"standards\" come and go. What makes MCP different is its simplicity and its backers. Anthropic has made this open source because they realize that the more context a model has, the more valuable it becomes.
\nWe are moving toward a world of \"agentic\" software development. In this world, we don't just use AI to write snippets of code. We use AI as an orchestrator that can reach into our cloud infrastructure on GCP, check our Docker logs, and suggest fixes for a failing Laravel app.
\nWithout a protocol like MCP, that vision is impossible to scale. It would be too expensive and too risky to build. But with MCP, we are building a world where tools are plug-and-play.
\nIf you are ready to start experimenting with this, here is what I recommend:
\nConnecting your dev tools to an LLM isn't just about speed. It is about reducing the cognitive load of switching between tabs, terminals, and documentation. It allows you to stay in the \"flow\" longer.
\nAre you ready to stop copy-pasting your code into a chat box and start connecting your tools directly to the brain? What is the one internal tool you wish you could \"plug in\" to Claude right now? Drop a note via contact — let's figure it out. 🤘
\n", "date_published": "2026-05-27T00:00:00.000Z", "date_modified": "2026-05-27T00:00:00.000Z", "tags": [ "ai", "mcp", "claude", "anthropic", "agentic-ai", "tool-use", "context", "dev-tools", "integrations" ], "image": "https://ansezz.com/blog/claude-mcp-dev-tools/hero.webp" }, { "id": "https://ansezz.com/blog/redis-semantic-caching-rag/", "url": "https://ansezz.com/blog/redis-semantic-caching-rag/", "title": "Caching for speed: Redis and semantic layers in RAG", "summary": "Stop paying for the same LLM call twice. Two-tier caching — exact-match Redis keys plus semantic vector lookups via RedisVL — that cuts RAG latency from seconds to milliseconds and slashes API spend by up to 80%. With tenant isolation, TTL tiers, and the precision metrics that keep it honest.", "content_html": "You finally shipped your RAG pipeline. It works. The retrieval is accurate. The LLM is snappy. But then you look at your cloud bill and your P99 latency. Every single query — even \"what are your shipping times?\" asked for the tenth time — triggers a full chain of embedding, vector search, and an expensive LLM call.
\nAt scale, this is a disaster. You are essentially paying for the same computation over and over again. Your users are waiting two seconds for answers that should take twenty milliseconds. Your \"denial of wallet\" risk is through the roof.
\nThe solution isn't a bigger model or a faster vector DB. It's a smarter cache. I'm talking about semantic caching with Redis. It cuts latency from hundreds of milliseconds to single digits and slashes your API costs by up to 80 percent.
\nHere is how I build these systems to handle production traffic.
\nStandard caching relies on exact matches. If a user asks \"How do I reset my password?\" and another asks \"how do i reset my password\", they might hit the same key if you normalize the string. But if the second user asks \"Can you help me change my password?\", a traditional cache fails.
\nIn a modern RAG stack, I use a two-tier approach.
\nThis architecture ensures that you never do the heavy lifting twice for the same intent.
\n![\"Two-tier](\"https://ansezz.com/blog/redis-semantic-caching-rag/architecture.webp\")
Most developers think of Redis as just a key-value store. But with the Redis Vector Library (RedisVL), it becomes a high-performance vector database.
\nWhy use Redis for this instead of your main vector DB like Pinecone or Weaviate?
\nLatency.
\nYour main vector DB is likely optimized for searching through millions of document chunks. Your semantic cache is much smaller — it only stores recent queries and answers. By co-locating this cache in Redis, which likely already sits in your application tier, you reduce network hops.
\nI typically see vector lookups in Redis finish in under 5ms. Compare that to an embedding API call that takes 100ms and an LLM generation that takes 1500ms. The math is simple.
\nThe trick to a good semantic cache is the similarity threshold. Too low, and you give users wrong answers (the \"semantic trap\"). Too high, and you never get a cache hit.
\nI usually start with a distance threshold of 0.1 for cosine distance, which translates to roughly 90 percent similarity. You can implement this quickly using the RedisVL extensions.
\nfrom redisvl.extensions.llmcache import SemanticCache\n\n# Initialize the cache with a conservative threshold\nllm_cache = SemanticCache(\n name=\"production_rag_cache\",\n redis_url=\"redis://localhost:6379\",\n distance_threshold=0.1,\n)\n\n# Check for a hit\nquery = \"how do i update my billing info?\"\nhit = llm_cache.check(prompt=query)\n\nif hit:\n return hit[0][\"response\"]\n\n# If miss, run full RAG and then store\n# response = run_rag_pipeline(query)\n# llm_cache.store(prompt=query, response=response)\nThis simple wrapper handles the embedding of the incoming query, the vector search in Redis, and the logic for returning the most relevant cached response.
\n![\"Python](\"https://ansezz.com/blog/redis-semantic-caching-rag/code.webp\")
Semantic caching is powerful but dangerous if you aren't careful. If your underlying data changes, your cache might still be serving old, incorrect information.
\nI always include a context_version in my cache keys or metadata. If I re-index my product catalog or update my documentation, I bump the version. The cache immediately starts missing for old entries, forcing a refresh with the new data.
Another trap is tenant isolation. If User A asks \"what is my balance?\", you absolutely cannot serve that cached response to User B. I solve this by partitioning the cache:
\ncache:tenant_id:query_hashtenant_id to the vector index filters.This ensures that semantic matches only happen within the correct security boundary. For more on building secure, multi-tenant systems, check out my thoughts on Laravel multi-tenancy which shares similar isolation principles.
\nIn a standard cache, you just set an expiry of 3600 seconds and forget it. With a semantic cache, I prefer a tiered TTL strategy.
\nThis hybrid approach keeps the system responsive without serving stale data. I've written about similar event-driven patterns here if you want to dive deeper into how to handle these updates at scale.
\nDon't just turn on the cache and walk away. You need to monitor two specific metrics:
\nI log every semantic hit along with its similarity score. Once a week, I sample hits with scores between 0.85 and 0.92 and manually review them. If I see too many \"near misses\" that are actually different questions, I tighten the threshold.
\n![\"Cache](\"https://ansezz.com/blog/redis-semantic-caching-rag/dashboard.webp\")
Implementing Redis as a semantic layer isn't just about speed. It's about making your AI systems sustainable. If you are serious about moving from a prototype to a production-ready SaaS, caching is not optional.
\nHere is your checklist for next week:
\nredisvl and set up a basic vector index in your dev environment.tenant_id or context_version to your metadata to avoid cross-talk.Building in public means sharing the war stories, not just the successes. For more technical deep dives into modern architecture, I suggest looking at 7 RAG mistakes in production to see what else might be slowing you down.
\nWhat is the one query in your system that keeps hitting your LLM unnecessarily? Drop a note via contact — let's figure out if a semantic cache would have caught it. 🤘
\n", "date_published": "2026-05-26T00:00:00.000Z", "date_modified": "2026-05-26T00:00:00.000Z", "tags": [ "architecture", "redis", "caching", "ai", "rag", "semantic-cache", "redisvl", "vector-search", "performance", "infrastructure" ], "image": "https://ansezz.com/blog/redis-semantic-caching-rag/hero.webp" }, { "id": "https://ansezz.com/blog/smart-auto-scaling-ai/", "url": "https://ansezz.com/blog/smart-auto-scaling-ai/", "title": "Scaling on demand: smart auto-scaling for modern AI apps", "summary": "CPU autoscaling is a lie for GPU workloads. Why queue depth, KV-cache pressure, and TTFT beat CPU as scaling triggers — KEDA-driven patterns, ARIMA forecasting, and composite metrics that scale your AI SaaS before users hit the spinner.", "content_html": "Your AI application is lagging, users are complaining, but your cloud dashboard says everything is fine. Your CPU usage is hovering at a comfortable 20 percent while your inference requests are timing out.
\nThis is the classic scaling trap for AI engineers. Traditional auto-scaling is built for web servers where CPU and memory are the primary bottlenecks. In the world of large language models and vector databases, those metrics are practically useless.
\nIf you wait for your CPU to hit 80 percent before spinning up a new pod, your service will be dead in the water long before the second instance even starts its boot sequence. GPU-bound workloads require a completely different playbook.
\nTo build a resilient, cost-effective AI SaaS, you need to move beyond reactive hardware metrics. You need to scale on intent, queue pressure, and the specific physics of GPU memory.
\nMost horizontal pod autoscalers (HPA) are configured to watch CPU utilization by default. For a Laravel or Node.js API, this works great. The work is linear — more requests equal more CPU cycles.
\nAI models are different. The CPU handles the \"boring\" stuff like tokenization, request routing, and managing HTTP headers. The heavy lifting happens on the GPU.
\nI have seen production clusters where the GPU is pinned at 100 percent while the CPU sits idle. Kubernetes sees the low CPU usage and thinks the pod is healthy. It might even try to pack more pods onto that node, leading to a catastrophic failure.
\n![\"CPU](\"https://ansezz.com/blog/smart-auto-scaling-ai/cpu-lie.webp\")
When you finally switch to monitoring GPUs, you encounter two confusing metrics: utilization and occupancy.
\nGPU utilization is essentially a duty cycle. It tells you the percentage of time the GPU was active over a sample period. It is a lagging indicator. By the time it hits 90 percent, your request queue has likely been building for 30 seconds.
\nOccupancy is more granular. It measures how many \"warps\" or hardware slots are filled within the streaming multiprocessors (SM). You can have high utilization but low occupancy if your batch size is too small.
\nFor scaling, utilization is the baseline, but it isn't the truth. You need to look at what is happening before the request even hits the silicon.
\nIf you want to stop fires before they start, monitor your queue depth. In vLLM or SGLang, this is the number of requests waiting for a slot in the inference engine.
\nQueue depth is a direct predictor of latency. If you know your model can handle 16 concurrent requests before P99 latency starts to climb, set your scaling trigger at 12.
\nScaling on queue depth lets you provision capacity while the current hardware is still performing within SLO. It gives you that 60-second head start you need to pull a fresh container and load a 20GB model weights file into memory.
\n![\"Queue](\"https://ansezz.com/blog/smart-auto-scaling-ai/queue-depth.webp\")
In generative AI, not all requests are created equal. A 10-token summary request is light. A 4,000-token RAG retrieval analysis is a heavyweight.
\nThis is where token velocity and KV-cache usage come in. The KV cache is the memory on the GPU that stores the context of current conversations. If your KV cache is 95 percent full, the next long request will trigger an eviction or a \"swap to CPU\" event.
\nLatency will skyrocket. Your P99 will look like a mountain range.
\nI recommend scaling based on a combination of:
\nWhen the cache is full, it doesn't matter how low your GPU utilization is. You cannot fit more work onto that chip. You must scale.
\nReactive scaling is always playing catch-up. Even with fast boot times, there is a delay. For enterprise apps with predictable traffic patterns, I use ARIMA (Auto-Regressive Integrated Moving Average) models to forecast load.
\nIf I know traffic historically spikes at 9:00 am every Monday, I don't wait for the queue to grow. I use a time-series forecast to spin up the \"base load\" pods at 8:55 am.
\nThis turns your infrastructure into a proactive system rather than a reactive one. You pay for what you use, but you ensure the capacity is there before the first user clicks \"Generate.\"
\n![\"ARIMA](\"https://ansezz.com/blog/smart-auto-scaling-ai/predictive.webp\")
Implementing this doesn't have to be a nightmare. Here is how I structure it:
\nScaling AI isn't about having the biggest GPUs. It is about having the smartest triggers. By moving to service-level metrics, you save money on idle compute and save your users from the dreaded \"thinking...\" spinner.
\nAre you still scaling on CPU, or have you made the jump to queue-based triggers yet? Drop a note via contact — I love this conversation. 🤘
\n", "date_published": "2026-05-25T00:00:00.000Z", "date_modified": "2026-05-25T00:00:00.000Z", "tags": [ "architecture", "auto-scaling", "ai", "llm", "kubernetes", "keda", "gpu", "kv-cache", "queue-depth", "ttft", "infrastructure" ], "image": "https://ansezz.com/blog/smart-auto-scaling-ai/hero.webp" }, { "id": "https://ansezz.com/blog/gpu-aware-load-balancing/", "url": "https://ansezz.com/blog/gpu-aware-load-balancing/", "title": "GPU-aware load balancing: managing AI compute like a pro", "summary": "Round-robin is a relic when LLM requests span 50 tokens to 50,000. Prefill vs decode disaggregation, KV-cache-aware routing, prefix matching, and the four metrics that matter — how to route AI traffic so your P99 stops bleeding.", "content_html": "You just scaled your RAG application to a hundred concurrent users. Suddenly, your latency spikes. Some users get their answers in two seconds, while others are staring at a loading spinner for thirty. You check your load balancer and it says everything is fine. CPU is at 40%. RAM is stable. But your GPUs are screaming, and your P99 latency is in the gutter.
\nThe problem is that you are treating your AI models like traditional web servers. Sending a 4,000-token prompt to the same GPU that is currently generating a 50-token summary is a recipe for disaster. Round-robin routing is a relic of the past when it comes to LLM inference. If you don't account for the unique way GPUs handle compute and memory, you aren't just wasting money. You are killing your user experience.
\nThe solution isn't just \"more GPUs.\" It is building a load balancer that actually understands what is happening inside the model. We need to talk about GPU-aware routing, prefill vs decode disaggregation, and why your KV cache is the most valuable asset in your stack.
\nIn traditional software development, a request is a request. Whether it's a GET /users or a POST /orders, the variance in resource consumption is usually predictable and small. Standard load balancers like Nginx or HAProxy work great here. They look at basic health checks and send traffic to the next available worker.
AI is different. A single request to an LLM has a massive variance in \"weight.\" One user might ask \"what is 2+2?\" while another uploads a 50-page PDF and asks for a deep analysis. If your load balancer sends both to the same GPU, the heavy request will hog the compute resources, forcing the light request to wait in a queue.
\nThis is why CPU-based metrics are useless. A GPU can be at 100% utilization while performing very different types of work. Some work is compute-bound, meaning it needs raw processing power. Other work is memory-bound, meaning it is limited by how fast data can move in and out of VRAM. To solve this, we have to look deeper into the inference lifecycle.
\nLLM inference happens in two distinct phases. Understanding the difference between them is the \"aha!\" moment for GPU load balancing.
\nThe first phase is prefill. This is when the model reads your entire prompt and processes all the tokens at once. It is a heavy, compute-intensive task that builds something called the KV cache (key-value cache). Prefill loves big batches and high-performance tensor cores. It is where the \"heavy lifting\" happens.
\n![\"Prefill](\"https://ansezz.com/blog/gpu-aware-load-balancing/prefill-vs-decode.webp\")
The second phase is decode. This is where the model generates the response one token at a time. Each new token only needs to look at the previously generated tokens and the KV cache. This phase is surprisingly light on compute but incredibly heavy on memory bandwidth. It is slow and long-lived.
\nWhen you mix these two on the same GPU without a smart scheduler, the \"prefill\" of a new request will often pause the \"decode\" of existing requests. This causes the jittery, stuttering text generation that users hate. By using GPU-aware load balancing, we can prioritize these phases differently across our fleet.
\nTo build a better router, you need to stop looking at CPU and start looking at these four metrics:
\nI often recommend using tools like vLLM because they expose these metrics out of the box. You can pipe these into a custom gateway that makes routing decisions based on real-time VRAM availability rather than just \"is the server up?\"
\nHere is a secret — the most expensive part of a RAG request is often re-processing the same system prompt or long context over and over again. If you send five consecutive questions about the same document to five different GPUs, each GPU has to perform the \"prefill\" phase for that document from scratch.
\n![\"Prefix](\"https://ansezz.com/blog/gpu-aware-load-balancing/prefix-routing.webp\")
This is where prefix-aware routing (sometimes called SkyWalker-style routing) comes in. Instead of routing randomly, your load balancer tokenizes the start of the prompt and looks for a GPU that already has that specific content in its KV cache.
\nBy matching the \"prefix\" of a prompt to a specific GPU, you can skip the prefill phase entirely for large chunks of text. This cuts latency from hundreds of milliseconds to almost zero. It is the single most effective way to optimize costs in production RAG systems. I've written before about common RAG mistakes, and ignoring cache locality is definitely one of them.
\nAs you scale, you should stop treating every GPU as a generalist. A senior move is to create disaggregated inference fleets.
\nI like to split my GPUs into two pools:
\nThis separation lets you scale based on your specific workload. If your users are uploading huge documents but only asking for short summaries, you scale your prefill pool. If they are having long, chatty conversations, you scale your decode pool.
\nThis is the same logic we use in modern DevOps with Coolify. You wouldn't put your heavy database on the same tiny instance as your frontend — why would you mix your heavy prefill work with your light decode work?
\nYou don't need to build a custom engine from scratch to start doing this. Here is the practical path I follow when setting this up for a new SaaS:
\nconversation_id has been seen by a specific node recently. If it has, and that node isn't at 100% KV utilization, send it there.![\"SaaS](\"https://ansezz.com/blog/gpu-aware-load-balancing/metrics-dashboard.webp\")
Managing AI compute is about moving from \"black box\" infrastructure to \"context-aware\" infrastructure. When your load balancer knows the difference between a 10-token greeting and a 10,000-token context window, your costs go down and your users stay happy.
\nIt's easy to get lost in the hype of \"agentic systems\" and context-aware agents, but none of that matters if your underlying infrastructure is buckling under the weight of unoptimized routing.
\nIf you are still using round-robin for your AI models, what is the biggest bottleneck you are seeing in your P99 latency right now? Drop a note via contact — I love this conversation. 🤘
\n", "date_published": "2026-05-24T00:00:00.000Z", "date_modified": "2026-05-24T00:00:00.000Z", "tags": [ "architecture", "gpu", "load-balancing", "ai", "llm", "inference", "vllm", "kv-cache", "prefill", "decode", "infrastructure" ], "image": "https://ansezz.com/blog/gpu-aware-load-balancing/hero.webp" }, { "id": "https://ansezz.com/blog/circuit-breakers-vector-db/", "url": "https://ansezz.com/blog/circuit-breakers-vector-db/", "title": "Circuit breakers: preventing cascading failures in your vector DB", "summary": "A slow vector DB kills SaaS faster than a dead one. The circuit-breaker pattern for AI infrastructure — closed/open/half-open states, fallback tiers, semantic caches, LLM-only mode, and Laravel-friendly wiring to keep production from melting under one bad dependency.", "content_html": "You built a beautiful RAG pipeline. It works perfectly on your machine with a few hundred vectors. Then you launch. Traffic spikes. Suddenly your managed vector database starts sweating. A single similarity search that used to take 50ms is now taking 5 seconds. Your web workers are all tied up waiting for responses that aren't coming. The database isn't technically down — but it is slow enough to kill your entire application. Your users see spinning loaders until the request finally times out. This is a classic cascading failure, and it is the fastest way to drain your \"innovation budget\" and your users' patience.
\nThe problem is that we often treat external APIs and databases as if they are always healthy. We write code that assumes the vector DB will return results. When it doesn't, we wait. And while we wait, we hold onto memory and CPU cycles. The solution is an old-school electrical engineering concept applied to software: the circuit breaker.
\nIn this guide I want to show you how to wrap your AI infrastructure in protective logic so a slow dependency doesn't take your whole SaaS down with it.
\nThe circuit breaker pattern is a state machine that sits between your application code and your external service. It monitors every call you make. It has three specific states that dictate how it handles traffic.
\n![\"Closed,](\"https://ansezz.com/blog/circuit-breakers-vector-db/states.webp\")
Closed — the healthy state.\nIn the closed state, the circuit is complete. Requests flow through to your vector database or LLM provider normally. The breaker is silently watching. It keeps a count of how many requests failed or took too long. As long as the failure rate stays below your threshold, it stays closed. This is the \"everything is fine\" mode.
\nOpen — the fail-fast state.\nOnce the failure threshold is hit — let's say 50% of requests failed in the last 30 seconds — the breaker \"trips\" and moves to the open state. Now, every time your application tries to call the vector DB, the breaker immediately throws an error or returns a fallback response without even attempting the network call. This gives your database room to breathe and recover. It also ensures your application doesn't waste time waiting on a service that is clearly struggling.
\nHalf-open — the recovery test.\nAfter a cooldown period, the breaker moves to the half-open state. It allows a small number of \"test\" requests to pass through. If these test calls succeed, the breaker assumes the service is healthy again and moves back to the closed state. If they fail, it immediately goes back to open for another cooldown cycle. This is a controlled way to probe the system before fully re-engaging.
\nRAG pipelines are particularly vulnerable because they usually involve multiple high-latency network hops. You have to embed the query, search the vector DB, and then call the LLM. If any of these pieces fail or slow down, the whole experience breaks.
\nMost developers make the mistake of only handling hard errors like a 404 or a 500 status code. But in production, \"slow\" is often more dangerous than \"down.\" A slow vector DB creates a bottleneck that backs up your entire request queue. By the time you realize there is a problem, your server is out of memory because it is holding open thousands of connections.
If you have read my previous post on 7 RAG mistakes in production, you know that reliability is the difference between a demo and a product. The circuit breaker is your insurance policy against these types of outages.
\nTripping the breaker shouldn't always mean showing an error message to the user. The best AI systems use fallbacks to maintain a level of service even when parts of the stack are failing.
\n![\"Architecture](\"https://ansezz.com/blog/circuit-breakers-vector-db/fallback-flow.webp\")
Hot and cold tiers.\nYou can think of your vector DB as your \"hot\" knowledge tier. If it fails, you should have a \"cold\" fallback. Maybe you fall back to a standard keyword search in your primary Postgres or MySQL database. The results might not be as contextually relevant as a vector search, but a \"decent\" answer is always better than a \"timed out\" error.
\nCached responses.\nAnother great strategy is semantic caching. If the circuit is open, you can check a Redis cache for similar queries that were answered recently. Even if you can't generate a fresh answer, you might be able to serve a cached one. This keeps the user moving while your backend recovers.
\nLLM-only mode.\nIf your retrieval step is what's failing, you can still send the user's prompt to the LLM with a note that external knowledge is currently unavailable. The LLM can then answer based on its general training data. It is a degraded experience, but it is still functional. Transparency here is key — tell the user that the \"live\" data isn't available so they know to verify the response.
\nSince I spend a lot of time in the Laravel ecosystem, I often use tools that make this easy to implement. You don't need to write the state machine from scratch. Packages like spatie/resilience or even building a custom wrapper around the illuminate/http client can get the job done.
The goal is to wrap your API calls in a block that understands these states. Here is a simplified look at how that logic looks in practice.
\n![\"Circuit](\"https://ansezz.com/blog/circuit-breakers-vector-db/code.webp\")
When you call your vector DB client, you wrap it in the breaker. If the call fails multiple times, the breaker trips. In the catch block, you handle the CircuitBreakerOpenException by returning your fallback data. This keeps your controllers clean and your architecture robust.
You can also integrate this with your SaaS hosting on Coolify to ensure that your containers don't get killed by health checks just because an external API is slow. The breaker prevents the resource bloat that usually triggers those health-check failures.
\nSenior engineers don't just set a circuit breaker and walk away. They monitor it. You need live telemetry to see how often your circuits are tripping. Tools like Prometheus or even simple logs piped to a dashboard can tell you a lot.
\nIf you see that your primary vector DB in us-east-1 is constantly tripping but your secondary in eu-west-1 is healthy, you can implement smart routing. Your circuit breaker can act as a signal to your load balancer or your internal router to shift traffic to the healthy region.
This kind of event-driven architecture makes your system self-healing. It doesn't wait for a human to wake up at 3am to fix a database. It detects the failure, trips the breaker, uses the fallback, and tries to recover automatically.
\nIf you are ready to harden your AI infrastructure, start here:
\nThe goal is to fail gracefully. Every system has issues, but the ones that survive are the ones that don't let a small fire in a dependency burn down the whole house.
\nHave you ever had a slow dependency take down your entire application, or are you still relying on long timeouts and luck? Drop a note via contact — I love this conversation. 🤘
\n", "date_published": "2026-05-23T00:00:00.000Z", "date_modified": "2026-05-23T00:00:00.000Z", "tags": [ "architecture", "circuit-breakers", "ai", "rag", "resilience", "vector-db", "fallback", "laravel", "observability", "infrastructure" ], "image": "https://ansezz.com/blog/circuit-breakers-vector-db/hero.webp" }, { "id": "https://ansezz.com/blog/message-queues-document-processing/", "url": "https://ansezz.com/blog/message-queues-document-processing/", "title": "Message queues: handling the heavy lifting of document processing", "summary": "Stop running embeddings inside the request-response cycle. A production-grade document ingestion pipeline — staged workers, exponential backoff, dead-letter quarantines, batched embeddings, and queue-depth autoscaling that keeps your AI app from melting under a 500-page PDF.", "content_html": "If you are running your document embeddings inside your request-response cycle, you are playing with fire. I have seen too many junior devs build a beautiful RAG application that falls over the second a user uploads a 50MB PDF. The browser spins, the Nginx timeout hits, and the database locks up while your worker tries to chunk 500 pages of legal jargon in real time.
\nThis is the classic \"heavy lifting\" problem in AI engineering. Document processing — OCR, text extraction, semantic chunking, and embedding — is slow, unpredictable, and resource-heavy. Trying to force it into a synchronous web request is a recipe for a bad user experience and a fragile system.
\nThe solution is decoupling. I'm talking about message queues. In this guide, I'll walk you through why async work belongs in a queue and how to build a production-grade ingestion pipeline that doesn't melt your server.
\nImagine a user uploads a document to your SaaS. Your code receives the file, sends it to an extraction API, waits for the response, loops through the text to create chunks, sends each chunk to an embedding model, and finally saves it to pgvector.
\nIf any of those steps take more than 30 seconds, the connection drops. If the embedding API has a momentary blip, the whole process fails, and the user has to start over. Worse, while your server is busy doing this heavy work, it's not responding to other users.
\nThis is where we apply the first rule of senior engineering: if it takes more than 100ms, consider making it async. By moving this work to a message queue, you give your users immediate feedback (\"we're processing your file!\") while the heavy lifting happens safely in the background.
\nA robust RAG pipeline isn't just one big function. It's a series of decoupled stages. I like to break it down into modular steps, each triggered by a message in a queue. This lets you scale different parts of the system independently.
\n![\"Pipeline](\"https://ansezz.com/blog/message-queues-document-processing/pipeline-stages.webp\")
Here is how I usually structure it:
\nfile_path and tenant_id.This stage-based approach is exactly what I discuss in my post on 7 RAG mistakes to avoid in production. It provides backpressure control — if your vector DB slows down, the \"index\" queue grows, but the \"parsing\" workers keep humming along.
\nIn the real world, things break. APIs time out. PDFs are malformed. Workers crash.
\nWhen you use a message queue like Redis (with BullMQ or Laravel Queues) or SQS, you get retries for free. If a worker fails, the message goes back onto the queue to be tried again after a short delay. Exponential backoff is your best friend here — don't hammer a failing API every 5 seconds. Wait 10, then 60, then 300.
\n![\"Retry](\"https://ansezz.com/blog/message-queues-document-processing/dlq-retries.webp\")
But what happens when a document simply cannot be processed? Maybe it's a password-protected PDF or a corrupted file. You don't want it retrying forever and clogging up your workers.
\nThis is where a Dead Letter Queue (DLQ) comes in. After a certain number of failed attempts, the message is moved to the DLQ. This acts as a \"quarantine\" zone. I can then inspect these failed jobs, fix the underlying issue, and manually re-queue them. It's a safety net that keeps your main production line moving.
\nIf you are processing 10,000 chunks, you do not want to make 10,000 individual API calls to your embedding provider. That's slow and expensive.
\nMost embedding APIs and vector databases perform much better with batches. A good worker pattern involves pulling multiple messages from the queue (or aggregating them in memory) and sending them as a single bulk request.
\nIn a Laravel environment, I often use job batching to track the progress of a large document. I can see exactly when 95% of a PDF is processed and update a progress bar for the user. If you're interested in how this fits into a larger architecture, check out my thoughts on event-driven pub/sub systems.
\nHere is a \"senior\" tip — queues aren't just for ingestion. You can use them for prefetching.
\nIf a user is chatting with an AI agent and the conversation is heading toward a specific topic, you can fire off a background job to fetch related documents and warm up the cache before the user even asks the next question. This makes your AI feel lightning fast because the context is already \"ready\" when the retrieval step hits.
\nBy using an event bus, you can decouple the chat interface from these optimization tasks. The chat app just emits a user_asked_question event, and a background worker decides whether it should pre-fetch more data or update the semantic cache.
Once you move to a queue-based system, your most important metric is no longer just \"request latency.\" You need to watch your queue depth.
\n![\"Queue-depth](\"https://ansezz.com/blog/message-queues-document-processing/monitoring.webp\")
If the queue depth is growing faster than your workers can clear it, you have a bottleneck. This is where tools like Docker and Coolify make life easy — I can spin up five more worker containers to handle a sudden surge in document uploads. You can read more about how I manage this infra in my Coolify and Docker guide.
\nupsert instead of insert in your vector DB to avoid duplicates.doc_id and tenant_id. Searching for \"why did this file fail?\" is impossible without it.Building a document pipeline is about respecting the time it takes to process data. By moving that work into a queue, you build a system that is resilient, scalable, and — most importantly — provides a smooth experience for your users.
\nHow are you currently handling long-running AI tasks? Are you still fighting with request timeouts, or have you embraced the queue? Drop a note via contact — I love this conversation. 🤘
\n", "date_published": "2026-05-22T00:00:00.000Z", "date_modified": "2026-05-22T00:00:00.000Z", "tags": [ "architecture", "message-queues", "ai", "rag", "document-processing", "redis", "bullmq", "laravel-queues", "dlq", "batching", "infrastructure" ], "image": "https://ansezz.com/blog/message-queues-document-processing/hero.webp" }, { "id": "https://ansezz.com/blog/rate-limiting-ai-wallet/", "url": "https://ansezz.com/blog/rate-limiting-ai-wallet/", "title": "Rate limiting: protecting your AI wallet", "summary": "One runaway agent loop = $5,000 OpenAI bill. Why request-per-second limits lie for LLM apps, how to architect hierarchical token-bucket limits across global / tenant / user layers, and adaptive throttling patterns that protect margins without breaking UX.", "content_html": "One runaway agent loop is all it takes to wake up to a $5,000 OpenAI bill.
\nIf you're building AI-powered SaaS or RAG systems, your biggest threat isn't a server crash. It's a \"denial of wallet\" attack. A buggy client, a malicious user, or even your own experimental agent can spam your API endpoints and burn through your tokens (and credits) in minutes.
\nTraditional web apps care about requests per second to keep the CPU from melting. In the world of LLMs, we care about tokens per minute to keep the bank account from draining. Standard rate limiting isn't enough anymore. You need an architecture that understands cost, context, and the \"noisy neighbor\" problem before a single prompt even hits your vector DB.
\nIn a standard Laravel or Node app, a request is a request. Sure, some take longer than others, but they generally consume similar resources. In AI engineering, one request might be a 50-token greeting, while another is a 128,000-token context dump for a RAG pipeline.
\nIf you only limit requests per second, a single user can stay within their \"10 requests per minute\" limit while still costing you 100× more than everyone else combined. This is where the noisy neighbor problem becomes a financial crisis.
\nYou aren't just protecting your infrastructure. You're protecting your margins. To do this effectively, we have to move from counting \"pings\" to counting \"value.\"
\n![\"Token](\"https://ansezz.com/blog/rate-limiting-ai-wallet/dashboard.webp\")
A denial of wallet attack is the AI equivalent of a DDoS. The goal isn't necessarily to take your site down. It's to exhaust your API quotas or financial budget until your service stops functioning — or you're forced to pay a massive bill.
\nI've seen this happen in three ways:
\nWithout token-aware rate limiting, your provider (like OpenAI or Anthropic) will eventually hit you with a 429 error. But by that time, the damage to your wallet is already done.
To solve this, I implement a three-layer rate limiting strategy at the API gateway level. This ensures that even if one tenant goes rogue, the rest of the platform stays healthy.
\nThis is your final line of defense. If your OpenAI quota is 500,000 tokens per minute (TPM), set your internal global limit to 450,000. This leaves a safety buffer and prevents you from actually hitting the provider's hard ceiling, which can sometimes lead to temporary account bans or throttled priority.
\nEvery customer gets their own bucket. I usually tie this to their subscription tier. A \"Pro\" user might get 50,000 TPM, while a \"Free\" user is capped at 2,000. This ensures no single company can eat up your entire global quota.
\nInside a single tenant, you still need limits. You don't want one single employee at a customer's company hogging all the tokens allocated to that entire organization. I set these at about 20% of the total tenant capacity.
\n![\"Hierarchical](\"https://ansezz.com/blog/rate-limiting-ai-wallet/architecture.webp\")
For most of my builds, I use a \"token bucket\" or \"leaky bucket\" algorithm backed by Redis. It's the gold standard for handling bursty traffic while maintaining a steady flow.
\nHere is the logic: each user has a \"bucket\" of tokens. Every time they send a prompt, we estimate the total cost (input tokens + expected max_tokens). If the bucket has enough, they proceed and the tokens are deducted. The bucket refills at a constant rate over time.
If you're modernizing your stack or building a SaaS on the LEMP stack, you can implement this efficiently in Laravel using middleware and a fast storage layer like Redis.
\n// A simplified token-bucket check in Laravel middleware\npublic function handle($request, Closure $next)\n{\n $tenantId = $request->user()->tenant_id;\n $estimatedTokens = $this->tokenizer->estimate($request->input('prompt'));\n\n if (!$this->limiter->consume(\"tenant:{$tenantId}:tokens\", $estimatedTokens)) {\n return response()->json(['error' => 'token budget exceeded'], 429);\n }\n\n return $next($request);\n}\n![\"Laravel](\"https://ansezz.com/blog/rate-limiting-ai-wallet/code.webp\")
What happens when a user hits their limit? Most devs just throw a 429 error. But as a senior engineer, I prefer a more graceful degradation. We call this adaptive throttling.
Instead of a hard \"no,\" you can:
\nThis keeps the user experience intact while protecting your margins. It's about being smart, not just being a gatekeeper.
\nIn a RAG (retrieval-augmented generation) system, one user query often triggers multiple backend actions:
\nIf you only rate limit the final LLM call, your vector database might still get hammered by search queries. You need to treat the entire \"RAG flow\" as a single unit of work with its own combined budget. I cover some of these common RAG production mistakes frequently, but rate limiting the \"flow\" is often the most overlooked fix.
\nIf you're launching an AI feature this week, do these three things:
\nmax_tokens — never let a user request an uncapped response. Always set a sane default for max_tokens in every API call.Rate limiting isn't just a \"security\" feature. In the AI era, it's a core part of your business model. You can't scale a product that allows a single user to run up a thousand-dollar bill in their first hour.
\nBuild for fairness. Build for cost. Build for the \"noisy neighbor.\"
\nHave you ever seen a \"denial of wallet\" happen in the wild, or are you still running on a wing and a prayer with global provider limits? Drop a note via contact — I love this conversation. 🤘
\n", "date_published": "2026-05-21T00:00:00.000Z", "date_modified": "2026-05-21T00:00:00.000Z", "tags": [ "architecture", "rate-limiting", "ai", "llm", "rag", "multi-tenancy", "redis", "laravel", "denial-of-wallet", "api-gateway" ], "image": "https://ansezz.com/blog/rate-limiting-ai-wallet/hero.webp" }, { "id": "https://ansezz.com/blog/api-gateway-ai-stack/", "url": "https://ansezz.com/blog/api-gateway-ai-stack/", "title": "API Gateway: the front door of your AI stack", "summary": "Stop exposing LLM providers directly to the frontend. The gateway pattern for AI apps — JWT-scoped tenant isolation, model aliases, denial-of-wallet rate limiting, streaming-safe timeouts, and the wallet-saving guardrails every senior engineer needs.", "content_html": "Stop exposing your models to the wild.
\nIf you are building a production AI app, sending requests directly from your frontend to a RAG orchestrator or — god forbid — straight to an LLM provider is a liability. It is slow. It is insecure. And it is the fastest way to wake up to a five-figure bill you didn't plan for.
\nI have spent over a decade building software, and if there is one thing I have learned, it is that engineering for \"it works\" is not the same as engineering for \"it scales.\" In the world of AI, scale isn't just about traffic. It is about cost, latency, and data safety.
\nImagine a \"denial of wallet\" attack where a malicious script spams your completions endpoint. Without a gatekeeper, your API keys are just sitting ducks. Or worse, imagine a multi-tenant app where one user's prompt accidentally retrieves another user's private data from your vector DB.
\nThis is where the API gateway comes in. It is the first line of defense and the brain of your infrastructure. It handles the boring but critical stuff so your RAG logic can stay focused on actually being smart.
\nAt its core, an API gateway is a reverse proxy that sits between your users and your backend services. But for an AI stack, it does more than just forward traffic. It acts as a centralized brain for auth, routing, and rate limiting.
\nWhen a request hits your gateway, it goes through a gauntlet of checks before it ever touches a model. This \"gatekeeper\" ensures that every millisecond of GPU time or every cent of token cost is intentional.
\n![\"Gateway](\"https://ansezz.com/blog/api-gateway-ai-stack/gateway-stack.webp\")
In a typical SaaS, authentication is about knowing who the user is. In an AI-powered SaaS, it is about data sovereignty.
\nIf you are building a RAG system, your biggest risk is cross-tenant data leakage. If you want to avoid common RAG mistakes, you must handle identity at the very edge.
\nI prefer using JWTs (JSON Web Tokens) with custom claims. When a request hits the gateway, I validate the token and extract the tenant_id. That ID is then injected into the headers of the request before it is passed to the RAG orchestrator.
This means the orchestrator doesn't have to \"guess\" who the user is. It receives a verified x-tenant-id header and uses it to apply metadata filters on the vector database. The user only \"sees\" data they are allowed to see. No tenant ID? No query. Period.
The AI world moves fast. Today you are using GPT-4o. Tomorrow, Claude 3.5 Sonnet might be the better play. Next week, you might want to test a fine-tuned Llama 3 model running on your own infrastructure via Docker and Coolify.
\nIf your model logic is hardcoded into your frontend or a single monolithic backend, switching models is a nightmare. An API gateway solves this with smart routing.
\n![\"Smart](\"https://ansezz.com/blog/api-gateway-ai-stack/routing-flow.webp\")
I use the gateway to create \"model aliases.\" Instead of the frontend calling a specific model, it calls a generic endpoint like /v1/chat/completions. The gateway then decides where to send that request based on:
This level of abstraction is what separates a weekend project from a resilient SaaS product.
\nWe used to rate limit to protect our CPUs. Now, we rate limit to protect our bank accounts.
\nAI requests are asymmetric. A user sends a 50-word prompt, and the model might generate a 1,000-word response. The cost difference is massive.
\nA good API gateway implementation allows for tiered rate limiting. Set global limits to prevent your entire system from being overwhelmed, but also set per-tenant or per-user limits.
\nI usually implement this using Redis. The gateway checks the user's quota in real time. If they have exceeded their daily token limit or their requests-per-minute (RPM) cap, the gateway returns a 429 Too Many Requests immediately.
This saves your backend from doing expensive work that you won't get paid for. It also stops \"noisy neighbors\" — one user scripting an automated tool that hogs all your capacity and makes the app slow for everyone else.
\nGateways for AI need to handle two things differently than traditional web apps: streaming and long-running requests.
\nMost modern AI apps use Server-Sent Events (SSE) to stream responses word by word. Some older gateways or load balancers try to \"buffer\" the entire response before sending it to the client. This kills the user experience.
\nMake sure your gateway (whether you are using Kong, Tyk, or a custom Laravel solution) is configured to disable buffering for AI routes. The data should flow through the gateway like water through a pipe, not like a bucket that needs to be filled.
\nTraditional APIs expect a response in 1–2 seconds. A complex RAG query involving multiple vector searches and a large model generation might take 30 seconds or more.
\nYou need to adjust your gateway's \"upstream timeout\" settings. If you keep the default 5-second timeout, your users will see constant 504 Gateway Timeout errors even when your models are working perfectly.
![\"Clean](\"https://ansezz.com/blog/api-gateway-ai-stack/clean-code.webp\")
You don't need a massive team to set this up. Here is how I usually approach it depending on the project size:
\nThe API gateway isn't just a piece of infrastructure. It is a design philosophy. It says that your AI logic is too valuable — and too expensive — to be left unprotected.
\nBy centralizing auth, routing, and rate limiting, you make your system more modular. You can swap models, change pricing tiers, and update security policies without touching the core code that makes your AI \"smart.\"
\nAre you still letting your frontend talk directly to your LLM providers? If so, what is the one thing stopping you from putting a gateway in front of it?
\nStay sharp.\n— a senior dev
\ntenant_id header to enforce data isolation./chat/pro instead of a specific model name to keep your stack flexible.Headless used to mean hiring a team of six engineers just to show a \"Buy\" button.
\nIf you wanted a custom Shopify experience outside of their Liquid-based themes, you were usually forced into a massive architectural decision. You had to build a full React or Hydrogen app, manage server-side rendering, handle complex routing, and pray your SEO didn't tank. For many startups and established brands, this was like buying a semi-truck when all they needed was a bicycle.
\nThe complexity of traditional headless was a gatekeeper. It prevented simple content-driven sites on platforms like Astro or WordPress from easily selling products without a jarring transition to a subdomain. We've spent years over-engineering solutions for problems that could have been solved with a few custom elements.
\nShopify Storefront Web Components have changed the math. Now, adding commerce to any site is as simple as dropping in a script tag.
\nBuilding a headless store often feels like building a house from scratch. You have to worry about the foundation (hosting), the plumbing (GraphQL queries), and the wiring (state management).
\nIf you are a senior engineer, you know the drill. You spend weeks configuring Shopify Hydrogen or a custom Next.js setup just to get a cart that actually works. And once it's live, you're the one who has to maintain the Node.js environment and the middleware.
\nIt's expensive. It's slow to deploy. And for 80% of use cases, it is total overkill. We need a way to get the flexibility of headless without the technical debt of a heavy framework.
\n![\"Headless](\"https://ansezz.com/blog/shopify-storefront-web-components/complexity-vs-simplicity.webp\")
Shopify Storefront Web Components are framework-agnostic. They are standard Web Components (custom elements) that handle the heavy lifting of communicating with Shopify's Storefront API.
\nYou don't need React. You don't need a build step. You just need HTML.
\nThis \"headless light\" approach lets you embed products, collections, and a fully functional cart directly into your existing stack. Whether you are using a static site generator or a legacy CMS, these components act as bridge-builders. They let you keep your content where it is and pull the commerce in dynamically.
\nGetting these up and running is refreshing for any developer used to complex APIs. Here is the workflow I use when I want to move fast.
\nThe first step is adding the script tag and the <shopify-store> component to your HTML. This establishes the connection to your Shopify domain.
<script src=\"https://webcomponents.shopify.dev/components.js\"></script>\n\n<shopify-store store-domain=\"your-store.myshopify.com\"></shopify-store>\nIf you need inventory counts or custom data, add a public-access-token from the Shopify headless channel. For basic title and price display, you don't even need that.
The magic happens with <shopify-context>. This tells the page which product or collection it should be looking at. You just pass the handle from your Shopify admin.
<shopify-context type=\"product\" handle=\"awesome-tshirt\">\n <template>\n <!-- your content goes here -->\n </template>\n</shopify-context>\nInside that template, you use <shopify-data> to pull specific fields. It uses dot notation, making it feel very familiar to anyone who has worked with Liquid or JavaScript objects.
<shopify-data query=\"product.title\"></shopify-data>\n<shopify-money query=\"product.variants.first.price\"></shopify-money>\n![\"AI-assisted](\"https://ansezz.com/blog/shopify-storefront-web-components/ai-assisted-code.webp\")
Here is the part where it gets interesting for modern developers. Shopify has released a specific llms.txt file.
\nIf you've been following the rise of agentic workflows and vibe coding, you know that providing context to an AI model is everything. By pointing your AI agent (like Claude or ChatGPT) to this text file, it learns exactly how to write code for these specific Web Components.
\nThis eliminates the hallucination problem. Instead of the AI guessing how a Shopify component should look, it uses the official spec. I've found that including this link in my system prompt lets me generate entire product landing pages in seconds that actually work on the first try.
\nIt turns \"development\" into \"orchestration.\" For more on how to leverage these tools, check out how MCP context-aware agents are changing the way we handle technical docs.
\n![\"llms.txt](\"https://ansezz.com/blog/shopify-storefront-web-components/llms-txt.webp\")
As a senior engineer, you have to pick the right tool for the job. Here is my rule of thumb.
\nUse Storefront Web Components if:
\nUse Shopify Hydrogen if:
\nFor most people starting out or modernizing a digital presence, Web Components are the winning choice. They offer the best balance of AI-driven development and production stability.
\nllms.txt file to train your AI assistant for perfect code generation.Building for the web in 2026 is about reducing friction. Shopify has finally removed the friction from headless.
\nAre you still building full React apps for simple stores, or are you ready to embrace the simplicity of custom elements? Drop a note via contact — I love this conversation. 🤘
\n", "date_published": "2026-05-19T00:00:00.000Z", "date_modified": "2026-05-19T00:00:00.000Z", "tags": [ "shopify", "shopify", "web-components", "headless", "llms-txt", "hydrogen", "agentic", "storefront-api" ], "image": "https://ansezz.com/blog/shopify-storefront-web-components/hero.webp" }, { "id": "https://ansezz.com/blog/agentic-commerce-shopify/", "url": "https://ansezz.com/blog/agentic-commerce-shopify/", "title": "Why agentic commerce will change the way you build Shopify stores", "summary": "AI agents don't browse — they query. The shift from human-centric Shopify themes to agent-ready infrastructure: Shopify Catalog, UCP, Agentic Storefronts, MCP servers, and why structured data is the new CSS.", "content_html": "Your beautiful Shopify theme is about to become invisible.
\nFor a decade, we have obsessed over conversion rate optimization, pixel-perfect layouts, and fast-loading Liquid templates. We built for human eyes. But a new type of shopper is arriving at the digital storefront. They don't have eyes, they don't click buttons, and they certainly don't care about your hero slider.
\nThey are autonomous AI agents.
\nThe shift from human-centric browsing to agentic commerce is the biggest architectural pivot Shopify has ever seen. If you are still just \"the theme guy\" or \"the Liquid expert,\" your skillset is about to hit a massive wall. I have been building on the web for over ten years, and I can tell you that the era of building for agents is here. It is time to move from designing pixels to designing protocols.
\nMost developers are still stuck in the old way of thinking. We build a site, drive traffic to a landing page, and hope the user navigates to the checkout. This is a manual, high-friction process.
\nToday, buyers are increasingly using tools like ChatGPT, Gemini, or Microsoft Copilot to do the \"work\" of shopping. They ask for a waterproof hiking boot under $150 with specific shipping requirements. The AI doesn't visit your store to browse. It queries data. If your store isn't built to be \"read\" by an agent, you simply don't exist in that transaction.
\n![\"Bento](\"https://ansezz.com/blog/agentic-commerce-shopify/shopping-flows.webp\")
We have spent years building \"utility\" apps that handle simple automations. But Shopify is moving fast to pull those features into the core. With tools like Shopify Magic and Sidekick, the basic stuff — copywriting, image editing, simple workflows — is being commoditized.
\nThe real value is moving deeper into the stack. Agents need more than just a product description. They need structured data, real-time inventory logic, and a way to execute a checkout without a browser window. If you are relying on \"fake\" variants or messy metafields, you are breaking the agent's ability to reason about your store.
\nWhen an agent fails to understand your product structure, the buyer gets a \"no results found\" or a hallucinated alternative. That is a lost sale for your client and a failed project for you.
\nAgentic commerce is a system where AI agents take over the discovery, comparison, and execution phases of shopping. Shopify is already laying the groundwork for this with three major pillars:
\nAs developers, our job is shifting. We are no longer just building visual storefronts. We are building \"agent-ready\" infrastructure.
\n![\"UI](\"https://ansezz.com/blog/agentic-commerce-shopify/ui-comparison.webp\")
In the agentic era, your structured data is your most important asset. A perfectly optimized JSON-LD schema or a clean set of Shopify Metaobjects is now more valuable than a fancy hover effect.
\nAgents rely on clarity. They need to know if a product is compatible with another, what the specific material breakdown is, and exactly when it will arrive. If you want to see how I've helped businesses modernize their digital presence through better architecture, check out some of my previous work.
\nThe focus for developers must move toward:
\nProductVariant records to function.The most exciting part of this shift is building our own agents. The Model Context Protocol (MCP) allows us to connect AI models to external data sources like the Shopify API.
\nImagine building an \"inventory agent\" for a merchant that doesn't just alert them when stock is low. Instead, it queries recent sales trends via the Admin API, checks lead times from a supplier, and suggests a restock amount — all through a chat interface.
\nThis is where tools like Laravel and Docker come in handy. We can build custom middleware that acts as an MCP server, exposing specific Shopify \"tools\" to an AI agent. This is the type of deep technical work that differentiates a senior engineer from a freelancer who just installs themes.
\n![\"MCP](\"https://ansezz.com/blog/agentic-commerce-shopify/mcp-architecture.webp\")
To thrive in the next five years, I recommend focusing on these specific technical areas.
\n1. Data hygiene as a service\nStart offering \"agent-readiness\" audits. Clean up product data, normalize attributes, and ensure all metadata is machine-readable. This is the new SEO.
\n2. Headless and API-first builds\nWhile Liquid isn't dead, headless architectures using Hydrogen and Oxygen are much more aligned with the agentic future. They force you to think in terms of data and APIs rather than just templates.
\n3. RAG and vector databases\nLearn how to use RAG (Retrieval-Augmented Generation) and tools like pgvector. This allows you to build agents that can search through thousands of product reviews or support docs to provide \"expert\" advice to shoppers.
\n4. Focus on the \"agentic plan\"\nShopify is rolling out levels of agentic integration. Stay ahead by understanding how to implement Level 3 — where your store is fully AI-native and provides direct API access for agents to build carts and checkout.
\n![\"Customer](\"https://ansezz.com/blog/agentic-commerce-shopify/shopping-agent.webp\")
The change is happening faster than most of us realize. By 2026, AI-driven traffic will be a double-digit percentage of total orders on major platforms.
\nIf you want to stay relevant, here is your checklist:
\nWe are moving into a world where commerce is autonomous and frictionless. It is an incredible time to be a developer if you are willing to learn the new protocols. If you want to learn more about my background in high-quality web applications, you can read more about me.
\nThe question is — are you building a store that only humans can see, or are you building a store that the whole world can buy from?
\nAre you ready to start building your first AI-native Shopify tool, or are you still holding onto your CSS hacks? Drop a note via contact — I love this conversation. 🤘
\n", "date_published": "2026-05-18T00:00:00.000Z", "date_modified": "2026-05-18T00:00:00.000Z", "tags": [ "shopify", "shopify", "agentic-commerce", "ai", "mcp", "hydrogen", "graphql", "ucp", "metaobjects" ], "image": "https://ansezz.com/blog/agentic-commerce-shopify/hero.webp" }, { "id": "https://ansezz.com/blog/7-rag-mistakes-production/", "url": "https://ansezz.com/blog/7-rag-mistakes-production/", "title": "7 mistakes you're making with your production RAG stack (and how to fix them)", "summary": "Naive chunking, no reranker, embedding drift, latency blowups, vibe-checking — the seven structural mistakes that turn a slick RAG demo into a production nightmare, and the fixes that actually ship.", "content_html": "Getting a RAG (retrieval-augmented generation) demo working is easy. You take a few PDFs, throw them into a vector database like Chroma or Pinecone, and ask a question. It feels like magic.
\nBut shipping RAG to production is where the magic dies.
\nI've seen too many teams launch a feature only to realize that their users are getting irrelevant answers, waiting 10 seconds for a response, or worse, getting hit with \"I don't know\" for questions that are clearly in the documentation. When the \"vibe check\" fails at scale, your users lose trust.
\nYou're likely making at least one of these seven structural mistakes that turn a cool demo into a production nightmare. I've spent the last few years building custom web applications and AI systems, and I've had to fix these same leaks in my own stacks.
\nHere is how to bridge the gap between \"it works on my machine\" and a production-grade AI system.
\nMost people start with a simple character-based or token-based splitter. You tell the library to \"give me chunks of 500 tokens with a 50-token overlap.\"
\nThis is a mistake.
\nThis \"naive chunking\" treats your data like raw soup. It might cut a sentence in half, split a table in the middle of a row, or separate a coding example from the explanation that precedes it. If the retriever pulls only one of those halves, the LLM has zero chance of giving a correct answer.
\nThe fix: use semantic or structural chunking.
\nI always recommend chunking based on the actual structure of the document first. Use headers (H1, H2, H3), paragraphs, or even markdown delimiters to ensure related ideas stay together. If you're working with complex data, consider recursive character splitting that respects newlines and punctuation before falling back to raw token counts.
\n![\"Structural](\"https://ansezz.com/blog/7-rag-mistakes-production/chunking.webp\")
Vector search is great at finding \"roughly similar\" stuff, but it's not a precision instrument. It relies on cosine similarity, which can be easily fooled by documents that share a similar \"vibe\" but don't actually contain the answer.
\nIf you're just taking the top 5 results from your vector store and shoving them into your LLM prompt, you're leaving quality on the table.
\nThe fix: add a reranking step.
\nI look at retrieval as a two-stage process. Stage one is the \"fast and broad\" search where you pull the top 20 or 50 candidates from your vector database. Stage two is using a cross-encoder or a specialized reranking model (like Cohere's Rerank or BGE-Reranker) to score those 50 candidates against the query more accurately.
\nThe reranker acts like a bouncer at a club. It doesn't care if a document looks \"okay.\" It only lets in the ones that are actually relevant to the question.
\n![\"Two-stage](\"https://ansezz.com/blog/7-rag-mistakes-production/reranker.webp\")
This is the silent killer. I've seen teams upgrade their embedding model from text-embedding-ada-002 to text-embedding-3-small without re-indexing their entire database.
Suddenly, the vectors being generated for new queries don't \"line up\" with the vectors stored in the index. The similarity scores go haywire. Even worse is when you change the preprocessing logic (like how you format the chunks) but keep the old vectors.
\nThe fix: pin your models and version your index.
\nTreat your embedding model like a database schema. If you change the model, you must re-index. I always include the model name and version in the metadata of every index I build. This way, if I need to test a new model, I can run them side-by-side without breaking the production flow. My experience in cloud infrastructure has taught me that consistency is better than a \"better\" model that doesn't match its data.
\nEveryone wants more context. We see context windows of 128k or even 1M tokens and think, \"great, I'll just give the LLM everything!\"
\nThis is a trap for two reasons. First, latency — feeding 50k tokens of context into an LLM can make your response time balloon to 20 or 30 seconds. Second, models still struggle with \"lost in the middle\" problems: they tend to ignore information buried in the center of a massive context window.
\nThe fix: optimize your latency budget.
\nI start with a \"latency budget.\" If the user expects a response in under 2 seconds, I can't afford to send 20 chunks. I limit my retrieval to the top 3–5 high-quality chunks and use streaming as soon as the first token is ready.
\nIf you need more data, consider using a multi-step approach: use a cheaper model to summarize the retrieved chunks before passing the refined info to your main model.
\n![\"Latency](\"https://ansezz.com/blog/7-rag-mistakes-production/latency.webp\")
Vector search is terrible at finding specific keywords or unique identifiers. If a user asks for \"error code XF-904,\" a vector search might return documents about \"general error handling\" because the \"vibe\" is similar. But it might miss the one specific document that actually mentions \"XF-904.\"
\nThe fix: implement hybrid search.
\nI always combine dense vector search with traditional sparse search (like BM25). By blending these two results using something like Reciprocal Rank Fusion (RRF), you get the best of both worlds. You get the semantic understanding of vectors and the keyword precision of full-text search. This is non-negotiable for enterprise search or technical documentation.
\nIf your RAG system contains documents for different clients, versions, or dates, pure vector search will betray you. You might ask about \"API changes in 2024\" and get results from 2022 because they share similar keywords.
\nRelying on the LLM to \"ignore\" the wrong dates in the context is a waste of tokens and a recipe for hallucinations.
\nThe fix: use hard metadata filters.
\nBefore the vector search even happens, apply filters. If you know the user is looking for \"v2\" of your documentation, filter the vector query to only include chunks with version: '2'. This drastically reduces the search space and improves accuracy. I use this heavily when building Shopify apps where data must be strictly siloed by shop ID.
How do you know your RAG stack is getting better? Most devs just ask a few questions, see that the answer looks okay, and ship it.
\nThis is called \"vibe-checking,\" and it doesn't work. When you change a prompt or a chunk size, you might improve one answer while breaking ten others you didn't check.
\nThe fix: build a golden evaluation set.
\nI use the Ragas framework or simple LLM-as-a-judge patterns to run automated evals. I maintain a \"golden set\" of 50–100 questions with ground-truth answers. Every time I change the architecture, I run the eval and look for three metrics:
\n![\"Evaluation](\"https://ansezz.com/blog/7-rag-mistakes-production/evals.webp\")
Building production RAG is a game of millimeters. It's about cleaning your data, pinning your models, and actually measuring what's happening under the hood.
\nI've spent years moving from \"it works\" to \"it's reliable.\" If you're struggling with a specific part of your AI pipeline, what's the one thing that's currently keeping you from hitting that \"deploy\" button?
\nDrop a comment or reach out if you're hitting a wall with your architecture. 🤘
\n", "date_published": "2026-05-17T00:00:00.000Z", "date_modified": "2026-05-17T00:00:00.000Z", "tags": [ "ai", "rag", "ai", "llm", "pgvector", "reranker", "hybrid-search", "evals", "production" ], "image": "https://ansezz.com/blog/7-rag-mistakes-production/hero.webp" }, { "id": "https://ansezz.com/blog/scaling-with-rabbitmq/", "url": "https://ansezz.com/blog/scaling-with-rabbitmq/", "title": "Scaling with RabbitMQ: why message brokers matter", "summary": "Synchronous controllers are how monoliths die. RabbitMQ basics, exchanges and queues, the strangler pattern for going async, idempotent workers, and the Laravel queue setup I use to absorb 100k-row spikes without breaking the login page.", "content_html": "The monolith is screaming. Every time a user hits the \"checkout\" button, your server has to generate a PDF, send a welcome email, update the inventory, and ping three different third-party APIs. Your request/response cycle is hanging by a thread. If any of those external services take more than two seconds to respond, your user sees a 504 gateway timeout.
\nIt starts with a small delay. Then it becomes a bottleneck. Before you know it, you are throwing more RAM at a problem that cannot be solved by bigger hardware. This is the \"monolith wall.\" When everything is synchronous, a single failure in a secondary task brings down the entire user experience.
\nI have been in these trenches. I have watched dashboards turn red during a marketing spike because the database was too busy processing background reports to handle new signups. The solution isn't just \"faster code.\" It is a change in how your services talk to each other. It is about decoupling. It is about RabbitMQ.
\nIn a standard web application, we often fall into the trap of doing too much inside the controller. A user makes a request, and we feel the need to finish every related task before sending back a \"200 OK.\" This is fine for a side project with ten users. For a scaling SaaS, it is a recipe for disaster.
\nThink of it like a coffee shop. If the person taking your order also has to grind the beans, froth the milk, and hand-draw the logo on the cup before taking the next order, the line will wrap around the block. The shop fails because the cashier is \"tightly coupled\" to the barista's work.
\nTo scale, you need a system where the cashier takes the order, writes it on a slip, and hands it off. They are immediately free for the next customer. The work happens \"in the background.\" That slip of paper is your message. The counter where they put the slips is your message broker.
\nRabbitMQ is an open-source message broker that acts as the \"middleware\" for your architecture. It doesn't just store messages — it routes them with surgical precision.
\nAt its core, RabbitMQ uses a few key concepts:
\nBy putting RabbitMQ in the middle, your web tier only needs to do one thing: tell RabbitMQ that a task needs to be done. This takes milliseconds. The user gets an instant confirmation, while the heavy work happens whenever your workers are ready.
\n![\"Architecture](\"https://ansezz.com/blog/scaling-with-rabbitmq/architecture-diagram.webp\")
One of the biggest pains in custom web development is handling \"noisy neighbors\" or sudden traffic bursts. If a large enterprise client uploads a 100,000-row CSV for processing, you don't want that to slow down the login page for everyone else.
\nWith RabbitMQ, those 100,000 rows become 100,000 individual messages in a queue. Your workers will chew through them at a steady pace. If the queue gets too long, you don't need to scale your entire application — you just spin up more worker instances.
\nThis is called horizontal scaling. Since the workers are decoupled from the web server, you can scale them independently based on the specific load. If you use modern tools like Laravel and Vue, you can easily manage these background jobs using built-in queue drivers that talk directly to RabbitMQ.
\nYou don't have to rewrite your entire codebase overnight. I usually recommend the \"strangler pattern.\" Pick one slow, non-critical process. Maybe it is the \"forgot password\" email or an image resize task.
\nHere is a simplified look at how you might dispatch a job in a modern PHP environment:
\n// instead of sending the email directly\n// $emailService->sendWelcome($user);\n\n// we dispatch a job to RabbitMQ\nProcessWelcomeEmail::dispatch($user)->onQueue('high-priority');\n\n// the user gets a response instantly\nreturn response()->json([\n 'message' => 'welcome! check your inbox soon.',\n]);\nNow, even if your email provider (like SendGrid or Mailgun) is having a bad day, your application stays up. The message stays safely in the RabbitMQ queue until the service is back online.
\nMoving to a message-broker-first mindset is the first step toward a microservices architecture. Once your monolith starts publishing \"events\" (like order.placed or user.registered), other services can start listening to those events without you ever changing the original code.
It creates a system that is resilient, observable, and significantly easier to debug. You can look at the RabbitMQ management UI and see exactly how many tasks are pending and how fast they are being processed. No more guessing why the server is slow.
\n![\"Monitoring](\"https://ansezz.com/blog/scaling-with-rabbitmq/monitoring-dashboard.webp\")
\n\nAlready running on GCP? The same patterns apply with Google Pub/Sub — pick the broker that matches your hosting stack, not the trend cycle.
\n
Scaling a SaaS isn't about working harder. It is about working smarter by giving your data room to breathe. RabbitMQ is that breathing room.
\nWhat is the slowest part of your application right now? Could it be a background job instead? Tell me — I bet we can move it off the request path.
\n![\"Pop-art](\"https://ansezz.com/blog/scaling-with-rabbitmq/final-visual.webp\")
Building a modern web application usually starts simple. You have a request and you send a response. But as your business grows, that simple flow starts to feel heavy. Maybe you need to send a welcome email, update a CRM, and trigger a data warehouse sync all at once. If you do this synchronously, your users are stuck staring at a loading spinner. If one service fails, the whole request dies. Your system becomes a house of cards.
\nThis is the problem of tight coupling. Your application logic is tangled like old headphones in a pocket. Every new feature adds more risk and more latency. You want to scale, but your monolithic approach is holding you back. You need a way to let your services talk without being glued together.
\nThe solution is event-driven architecture (EDA). And in the Google Cloud world, the heart of that architecture is Google Pub/Sub. It is a globally distributed messaging service that decouples the services that produce events from the services that consume them. It allows you to build systems that are truly scalable, resilient, and ready for the future of AI and big data.
\n![\"Architecture](\"https://ansezz.com/blog/event-driven-pubsub/architecture-diagram.webp\")
At its core, Google Pub/Sub is built on two main concepts: topics and subscriptions. I like to think of a topic as a radio station. It broadcasts information out into the void. It doesn't care who is listening or what they do with the music. It just plays the hits.
\nOn the other side, you have subscriptions. These are the listeners. A subscription represents a stream of messages from a specific topic. The beauty of this system is the decoupling. The service sending the message (the publisher) only needs to know about the topic. It doesn't need to know if there are ten consumers or zero.
\nIn a typical software development workflow, this is a game changer. When a user signs up on your site, you publish a UserSignedUp event to a topic. Your main app is done. It returns a success message to the user immediately. Meanwhile, various subscribers pick up that event and do their jobs in the background.
One of the most effective patterns in Google Pub/Sub is the fan-out. This is where you publish a single message to a topic, but multiple subscriptions receive a copy of that message.
\nImagine you are running an e-commerce store. When an order is placed, you might have three different services that need to act:
\nInstead of your checkout service calling three different APIs, it sends one message to an order-events topic. Three separate subscriptions (one for inventory, one for shipping, one for analytics) each get their own copy of that order message. They process it at their own pace. If the analytics service is down for maintenance, it doesn't stop the shipping label from being created. The messages just wait in the queue until the service is back online.
![\"Dashboard](\"https://ansezz.com/blog/event-driven-pubsub/dashboard-mockup.webp\")
When you set up a subscription, you have to decide how you want to receive messages. Google Pub/Sub gives you two main options: pull and push.
\nPush subscriptions are great for serverless architectures. Google Cloud will literally \"push\" the message to a webhook URL you provide. This is perfect for cloud infrastructure built on Cloud Run or Cloud Functions. It scales automatically and you only pay for what you use. However, you have to make sure your endpoint can handle the sudden spikes in traffic.
\nPull subscriptions work differently. Your consumer service asks Google Pub/Sub for messages when it is ready. This gives you much more control over backpressure. If your worker is busy, it doesn't ask for more work. This is the preferred method for long-running services or when you are using tools like Laravel's queue workers. Pull delivery is generally more robust for heavy processing tasks where you want to fine-tune concurrency.
\n![\"Pop-art](\"https://ansezz.com/blog/event-driven-pubsub/dlq-illustration.webp\")
In a distributed system, things will fail. A database might time out or an external API might be down. If a message can't be processed, you don't want to lose it. This is where Dead Letter Queues (DLQs) come in.
\nA DLQ is just another topic where Google Pub/Sub sends messages that have failed to be acknowledged after a certain number of attempts. Instead of retrying forever and clogging up your main pipeline, the \"poison\" message is moved aside.
\nI always recommend setting up a DLQ for every critical subscription. It acts as a safety net. You can then build a separate dashboard or a small script to inspect these failed messages, fix the underlying issue, and replay them. It is a professional approach to error handling that prevents data loss and keeps your system moving.
\nFor those of us in the PHP and Laravel ecosystem, integrating Google Pub/Sub is incredibly smooth. While Laravel comes with great support for Redis and SQS, using a package like google/cloud-pubsub allows you to tap into GCP's global scale.
You can treat Google Pub/Sub as a custom queue driver. Here is a quick look at how you might publish a message in a typical service class:
\nuse Google\\Cloud\\PubSub\\PubSubClient;\n\n$pubsub = new PubSubClient([\n 'projectId' => 'your-gcp-project-id',\n]);\n\n$topic = $pubsub->topic('user-events');\n\n$topic->publish([\n 'data' => json_encode([\n 'user_id' => 123,\n 'action' => 'signup',\n ]),\n 'attributes' => [\n 'event_type' => 'UserSignedUp',\n 'priority' => 'high',\n ],\n]);\nBy using attributes, you can even filter messages at the subscription level. This means a subscriber can choose to only listen for messages where event_type is UserSignedUp. This saves compute power and money because your worker never even sees the messages it doesn't care about.
Monitoring is not an afterthought. It is a requirement. Google Cloud provides deep integration with Cloud Monitoring for Google Pub/Sub. You should keep a close eye on your \"unacked message count.\" If this number is climbing, it means your subscribers can't keep up with the producers.
\nCost is another factor to watch. Google Pub/Sub is very cheap for low volumes, but as you scale to millions of messages, those bytes add up. Use batching on the publisher side to reduce the number of API calls. Also, be mindful of message retention. If you don't need to keep messages for seven days, shorten the retention period to save on storage costs.
\nMoving to an event-driven architecture with Google Pub/Sub is a major step toward building senior-level systems. It gives you the flexibility to grow your application without it becoming a tangled mess. It is the backbone of many high-performance web applications I build for clients today.
\nHere are the key takeaways for your next project:
\nOrderPlaced) and turn them into events.Building these kinds of systems takes a bit more planning upfront, but the payoff in stability and scalability is worth every second.
\nAre you still using synchronous API calls for everything, or have you started moving toward an event-driven flow? Let me know what's stopping you from making the switch.
\n", "date_published": "2026-05-02T00:00:00.000Z", "date_modified": "2026-05-02T00:00:00.000Z", "tags": [ "architecture", "pub-sub", "event-driven", "gcp", "google-cloud", "laravel", "messaging", "scalability", "architecture" ], "image": "https://ansezz.com/blog/event-driven-pubsub/hero.webp" }, { "id": "https://ansezz.com/blog/coolify-docker-saas-hosting/", "url": "https://ansezz.com/blog/coolify-docker-saas-hosting/", "title": "Effortless SaaS hosting: the Coolify and Docker deployment guide", "summary": "Heroku DX, your own server, none of the cloud tax. How Coolify + Docker on a $5 VPS replaces vendor-lock managed platforms with a control plane you actually own — one-click databases, automatic SSL, and zero-downtime deploys.", "content_html": "Shipping a SaaS is hard enough without the constant anxiety of a \"surprise\" bill from your hosting provider. I have seen developers start a project on a managed platform only to find that as soon as they add a second team member or cross a certain bandwidth threshold, their costs skyrocket. You are trapped between paying a \"convenience tax\" that eats your margins or spending your entire weekend fighting with Nginx configurations and manual SSH commands. It feels like you are either overpaying for simplicity or overworking for control.
\nThe agitation grows when you realize that most managed platforms are essentially wrappers around the same open source tools you could run yourself. You are paying for a pretty dashboard and an easy git-push flow. But when you try to leave, you find yourself deep in vendor lock-in. Your databases, your environment variables, and your build pipelines are all tied to a proprietary ecosystem. If the platform goes down or changes its pricing, your business is at the mercy of their support team.
\nThere is a better way. Coolify combined with Docker gives you the exact same developer experience as high-end managed platforms but on your own infrastructure. You get the \"one-click\" deploy feel and a beautiful dashboard while keeping 100 percent control over your servers. It is the ultimate setup for a modern web application that needs to scale without breaking the bank.
\nIn the early days of a startup, a $20-per-month plan feels reasonable. But as you grow, those costs don't just add up — they multiply. Many platforms now charge per seat. If you have a team of five engineers, you might be paying a hundred dollars a month before you even deploy a single line of code. Then come the usage fees. Bandwidth, image optimization, and serverless function execution costs are often opaque and difficult to predict.
\nI have worked with clients who moved their entire stack from managed services to a self-hosted Coolify setup and saw their monthly infrastructure bill drop by eighty percent. We are talking about moving from $500 a month down to $50 a month while maintaining the same performance and reliability. When you own the server, you own the resources. There are no \"hidden\" charges for extra build minutes or database connections.
\n![\"Architecture](\"https://ansezz.com/blog/coolify-docker-saas-hosting/coolify-architecture.webp\")
Think of Coolify as an open source, self-hosted version of Heroku or Vercel. It is a control plane that sits on your server and manages everything for you. It handles your deployments, your reverse proxies, your SSL certificates, and your databases. It turns a raw Linux VPS into a powerful hosting platform.
\nOne of the best parts about Coolify is that it is built on Docker. Every application you deploy is containerized. This means your environment is consistent across development, staging, and production. No more \"it works on my machine\" excuses. If it runs in a container on your laptop, it will run exactly the same way on your Coolify server.
\nDocker is the silent engine that makes this entire workflow possible. Instead of installing PHP, Node.js, or Python directly on your server, you package them into a container image. This approach has several key benefits for SaaS founders:
\nWhen I build custom web solutions, I always prioritize Docker. It ensures that the handoff to the client is seamless. They don't need to worry about the underlying server configuration. They just need a Docker-compatible environment.
\n![\"Pop-art](\"https://ansezz.com/blog/coolify-docker-saas-hosting/docker-rack.webp\")
Getting started is surprisingly simple. You need a fresh VPS with at least two gigabytes of RAM. I typically recommend Ubuntu for the operating system. Once you have your server, you run a single installation command provided by the Coolify documentation.
\n# the only command you need to bootstrap Coolify\ncurl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash\nThis script takes care of installing Docker, setting up the Traefik reverse proxy, and launching the Coolify dashboard. Within minutes, you can log in to your own private hosting panel. From there, you can connect your GitHub or GitLab account. Coolify will listen for webhooks and automatically trigger a new build whenever you push code to your main branch.
\nIt feels magical. You get the same feedback loop as the big-name platforms. You see the build logs in real time. You get a preview URL for your feature branches. And you do it all on a $5 VPS.
\nOne of the biggest pain points of self-hosting is managing databases. Nobody wants to manually configure Postgres clusters or worry about backing up Redis instances. Coolify solves this by offering \"one-click\" services.
\nYou can spin up a Postgres, MySQL, MongoDB, or Redis instance in seconds. Coolify automatically generates secure credentials and provides you with the connection strings. It also handles persistent volumes. This means that even if your container restarts or you update the image, your data stays safe.
\nFor a SaaS, I usually recommend a dedicated server for your databases if you have high traffic. Coolify makes this easy because it supports multi-server setups. You can have one server acting as your \"control plane\" and several other servers acting as \"worker nodes\" where your apps and databases actually live. (I cover that scaling pattern in more depth in Scaling with confidence: advanced Coolify deployment strategies.)
\nSecurity shouldn't be an afterthought. In the old days, setting up SSL with Let's Encrypt required cron jobs and manual certificates. With Coolify and Traefik, it is entirely automated.
\nWhen you point a domain to your server and add it to your app configuration, Coolify automatically requests and installs an SSL certificate. It also handles the renewal process. Your SaaS is always served over HTTPS without you ever touching a terminal.
\nBeyond encryption, Coolify helps you manage your environment variables securely. You don't need to hardcode secrets in your git repository. You can define them in the dashboard, and they are injected into your containers at runtime. This is a standard best practice that many developers skip when they are in a rush.
\n![\"Pop-art](\"https://ansezz.com/blog/coolify-docker-saas-hosting/ssl-security.webp\")
If you want to do this the \"pro\" way, here is how I structure my deployments.
\nWhile Coolify can automatically detect many frameworks like Laravel or Node.js, I always recommend writing your own Dockerfile. It gives you total control over the build process. You can optimize your image size by using multi-stage builds. This makes your deployments faster and saves disk space.
\nIf you don't want to write a Dockerfile, Coolify supports Nixpacks. It is a tool developed by Railway that looks at your code and builds an optimized container image automatically. It is incredibly smart and works for almost every major framework.
\nNever deploy without a health check. You want to make sure your app is actually responding before the reverse proxy starts sending traffic to it. Coolify allows you to define a health check endpoint. If the check fails, the old container stays running, and the new one isn't promoted. This is the foundation of zero-downtime deployments.
\nSelf-hosting isn't for everyone. If you are a solo developer with zero interest in learning how a server works, then paying the \"convenience tax\" might be worth it. Your time is valuable, and if a managed platform saves you five hours of frustration a month, it might pay for itself.
\nHowever, if you are building a real business, you need to understand your stack. Owning your infrastructure is about more than just saving money. It is about autonomy. It is about knowing that no matter what happens to a specific provider, you can move your business elsewhere in a heartbeat.
\nAt Ansezz, I focus on building robust, scalable systems that empower clients. Whether the work is a complex e-commerce engine on Shopify or a custom Laravel application, the goal is always the same: high performance and long-term stability.
\nHosting shouldn't be a source of stress. By moving to a Docker-based workflow with Coolify, you reclaim your time and your budget. You get the professional features of a top-tier PaaS without the enterprise price tag.
\nHere is your checklist for a successful transition:
\nWhen you stop worrying about the \"how\" of deployment, you can spend more time on the \"what\" of your product. That is where the real value is created.
\nWhat is the one thing stopping you from moving your SaaS to a self-hosted setup today? Tell me about it — happy to share war stories.
\n", "date_published": "2026-04-19T00:00:00.000Z", "date_modified": "2026-04-19T00:00:00.000Z", "tags": [ "devops", "coolify", "docker", "self-hosting", "devops", "saas", "deployment", "vps", "traefik" ], "image": "https://ansezz.com/blog/coolify-docker-saas-hosting/hero.webp" }, { "id": "https://ansezz.com/blog/mcp-context-aware-agents/", "url": "https://ansezz.com/blog/mcp-context-aware-agents/", "title": "MCP and the future of tool-use: building context-aware agents", "summary": "The Model Context Protocol kills the era of brittle one-off integrations. Tools, resources, prompts, and the three primitives that let one server talk to any MCP-aware client — with a working TypeScript example you can ship today.", "content_html": "The current state of AI agents is a mess of fragmented integrations. Every time I want to give an LLM access to a new data source or a specific tool I find myself writing custom glue code that breaks the moment an API version changes. It is a frustrating cycle of building brittle wrappers. We are effectively forcing highly intelligent models to peer through a keyhole when they should have a wide-open window into our data ecosystems.
\nThis fragmentation creates a massive technical debt for developers. You spend eighty percent of your time on plumbing and maybe twenty percent on the actual intelligence of the agent. Without a unified way to share context the model often hallucinates because it lacks the grounding of real-time data. It is stuck in a loop of \"I don't have access to that\" or worse \"I'll guess what that data looks like\" — which leads to unreliable outputs and a poor user experience.
\nThe Model Context Protocol (MCP) changes this dynamic entirely. It is an open standard that allows me to build context-aware agents that connect to any data source using a universal language. By standardizing how servers and clients communicate I can focus on building sophisticated logic rather than managing endless API endpoints. It is the missing link in the agentic workflow.
\n![\"Architecture](\"https://ansezz.com/blog/mcp-context-aware-agents/architecture-diagram.webp\")
I have spent years building custom web applications and one of the biggest hurdles has always been data silos. When I work on complex technical challenges the goal is usually to make data actionable. Traditional tool-use requires the developer to define every schema and every function call manually for the model. MCP flips this script.
\nMCP acts as a bridge. It defines a clear boundary between the AI application (the client) and the data sources (the servers). This separation of concerns means I can swap out the underlying model without rebuilding the entire data integration layer. If I move from Claude to another model that supports MCP, the tools and resources remain the same.
\nIt also solves the \"context window\" problem. Instead of stuffing a massive document into the prompt I can expose it as an MCP resource. The model only fetches what it needs when it needs it. This is significantly more efficient and cost-effective. It allows me to build agents that are aware of their environment without being overwhelmed by it.
\n![\"Visual](\"https://ansezz.com/blog/mcp-context-aware-agents/context-visual.webp\")
To understand how to build with MCP I look at its three core primitives. These are the building blocks for any context-aware system.
\nI prefer using TypeScript for building MCP servers because of the robust SDK provided by Anthropic. However the protocol itself is language-agnostic. Here is a simplified look at how I structure a basic server that exposes a weather tool.
\nimport { Server } from \"@modelcontextprotocol/sdk/server/index.js\";\nimport { StdioServerTransport } from \"@modelcontextprotocol/sdk/server/stdio.js\";\nimport {\n CallToolRequestSchema,\n ListToolsRequestSchema,\n} from \"@modelcontextprotocol/sdk/types.js\";\n\nconst server = new Server(\n {\n name: \"weather-server\",\n version: \"1.0.0\",\n },\n {\n capabilities: {\n tools: {},\n },\n },\n);\n\nserver.setRequestHandler(ListToolsRequestSchema, async () => {\n return {\n tools: [\n {\n name: \"get_weather\",\n description: \"get the current weather for a location\",\n inputSchema: {\n type: \"object\",\n properties: {\n location: { type: \"string\" },\n },\n required: [\"location\"],\n },\n },\n ],\n };\n});\n\nserver.setRequestHandler(CallToolRequestSchema, async (request) => {\n if (request.params.name === \"get_weather\") {\n const location = request.params.arguments?.location;\n // logic to fetch weather from an api goes here\n return {\n content: [{ type: \"text\", text: `it is sunny in ${location}` }],\n };\n }\n throw new Error(\"tool not found\");\n});\n\nconst transport = new StdioServerTransport();\nawait server.connect(transport);\nThis snippet illustrates the simplicity of the protocol. I define the tool and how to handle the call. The MCP client handles the rest. This modular approach is exactly what I look for when managing cloud infrastructure or complex backend systems. It is clean and scalable.
\n![\"Dashboard](\"https://ansezz.com/blog/mcp-context-aware-agents/dashboard-mockup.webp\")
Security is a major concern when giving an AI agent access to your data. I have seen many implementations where API keys are hardcoded or permissions are too broad. MCP addresses this by using a client-server architecture where the server controls exactly what is exposed.
\nThe server acts as a gatekeeper. I can implement fine-grained access control at the server level. For example an MCP server connecting to a database can be restricted to only specific tables or read-only queries. This level of control is essential for enterprise-grade applications.
\nThe ecosystem is growing rapidly. We are seeing early adoption from major players in the dev tools space. Tools like Zed, Cursor, and Claude Code are already integrating MCP to help developers write better code by giving their AI assistants better context. This trend will only accelerate as more developers realize the power of standardized context.
\nIf you are a developer looking to dive into MCP I recommend following these steps.
\nMCP is more than just a new protocol. It is a fundamental shift in how we build AI applications. It moves us away from the era of \"black box\" agents and toward a world of transparent and context-aware assistants. I am excited to see how this technology evolves and how it will transform our development workflows.
\nHow are you planning to use MCP in your next project? Drop me a line — happy to swap notes on real-world MCP server design.
\n", "date_published": "2026-04-05T00:00:00.000Z", "date_modified": "2026-04-05T00:00:00.000Z", "tags": [ "ai", "mcp", "anthropic", "claude", "agentic-ai", "typescript", "tool-use", "context" ], "image": "https://ansezz.com/blog/mcp-context-aware-agents/hero.webp" }, { "id": "https://ansezz.com/blog/agentic-workflows-vibe-coding/", "url": "https://ansezz.com/blog/agentic-workflows-vibe-coding/", "title": "Vibe coding and the architectural shift to agentic workflows", "summary": "MCP, agentic loops, and intent-based engineering. How vibe coding becomes a real architecture pattern when AI stops being a chat sidebar and starts owning stateful loops against your tools. The practical Laravel + MCP stack I run today.", "content_html": "I've spent the last decade building Laravel applications, managing Docker clusters, and fine-tuning Shopify stores. For most of that time, \"coding\" meant one thing: translating a business requirement into a specific syntax that a machine could execute. It was a manual, linear process of writing line by line, debugging stack traces, and managing state.
\nBut recently, the ground has shifted. We're moving away from the era of \"writing code\" and into the era of \"orchestrating intent.\"
\nThis transition — often playfully called vibe coding — is more than just a meme. It represents a fundamental architectural shift in how we build software, moving from sequential instruction to agentic loops powered by protocols like MCP (Model Context Protocol).
\nThe traditional development lifecycle is riddled with invisible friction. You have an idea (the \"vibe\"), you break it down into tasks, and then you spend 80% of your time fighting with syntax, configuration, and boilerplate.
\nIn a standard Laravel environment, even a simple feature — say, an automated reporting tool — requires you to set up routes, controllers, service classes, and database migrations. You are the compiler. You are the architect. You are the labor.
\nThe problem is that our human cognitive load is being consumed by the \"how\" rather than the \"what.\" We get stuck in the weeds of PHP version compatibility or Docker networking issues, losing sight of the actual user value. This manual micromanagement doesn't scale as fast as the demands of modern business.
\nWhen AI first entered the scene with basic autocomplete, it felt like a shortcut. But it wasn't a solution. We ended up with what I call \"the Copilot paradox\": the AI suggests code, but you still have to copy-paste it, test it, find the error, and feed it back to the AI.
\nIt's a broken feedback loop. The AI is a \"black box\" that doesn't actually know your system. It doesn't know your database schema, your MCP servers, or your deployment status on Coolify. You are still the manual bridge between the AI's logic and your local environment.
\nThis creates a new kind of fatigue. Instead of writing code, you're now a high-speed code reviewer, constantly context-switching between your editor and a chat interface. This isn't \"vibe coding\" — it's just accelerated manual labor.
\n![\"Architecture](\"https://ansezz.com/blog/agentic-workflows-vibe-coding/architecture-diagram.webp\")
True vibe coding isn't about being lazy; it's about shifting your role to that of a high-level system architect. This becomes possible through agentic workflows — systems that don't just \"complete text\" but \"execute tasks in loops.\"
\nThe breakthrough here is the Model Context Protocol (MCP) by Anthropic. MCP acts as the \"USB port\" for AI. Instead of you manually giving the AI context, the AI uses an MCP client to talk directly to your tools — your PostgreSQL database, your Slack channels, or your GitHub repositories.
\nIn a traditional chain, you give a prompt and get a result. In an agentic loop, the architecture looks like this:
\nI call this \"intent-based engineering.\" You aren't writing the migration — you are approving the architectural decision.
\n![\"Bento](\"https://ansezz.com/blog/agentic-workflows-vibe-coding/agentic-loop.webp\")
As an engineer who values quality, I don't just let the \"vibe\" take over without guardrails. Here is how I'm currently structuring my agentic stack using Laravel and AI.
\nI build small, dedicated MCP servers that expose only the necessary tools to the AI. This keeps the context window clean and the security tight.
\n// Conceptual MCP tool definition in a PHP environment\npublic function defineTools(): array\n{\n return [\n 'get_database_schema' => [\n 'description' => 'Retrieves the structure of the Laravel application tables.',\n 'parameters' => [],\n ],\n 'run_artisan_command' => [\n 'description' => 'Executes an artisan command safely.',\n 'parameters' => ['command' => 'string'],\n ],\n ];\n}\nInstead of one-off chats, I use tools like Cursor, Claude Code, or Windsurf that maintain a stateful connection to my local file system. This allows the agent to \"see\" the impact of its changes in real-time, just like a human developer would.
\nThe most important part of the architecture is the review gate. Even with agentic loops, the human architect must sign off on the \"plan\" before the \"action\" phase. This ensures the PHP logic follows clean architecture principles rather than just \"making it work.\"
\nIf you're a founder or a CTO, the takeaway is simple: stop hiring for syntax and start hiring for system design. The technical barrier is collapsing, but the architectural stakes are higher than ever.
\nAt Ansezz, I'm not just building apps anymore — I'm building agent-ready ecosystems. Whether it's a complex Shopify integration or a custom SaaS, I ensure the architecture is ready for the agentic future.
\nThe code might be generated, but the vision is entirely yours.
\nAre you ready to stop writing code and start orchestrating your intent? Get in touch — let's design your agent stack together.
\n", "date_published": "2026-03-22T00:00:00.000Z", "date_modified": "2026-03-22T00:00:00.000Z", "tags": [ "architecture", "vibe-coding", "agentic-ai", "mcp", "anthropic", "claude", "laravel", "architecture" ], "image": "https://ansezz.com/blog/agentic-workflows-vibe-coding/hero.webp" }, { "id": "https://ansezz.com/blog/why-your-rag-is-failing/", "url": "https://ansezz.com/blog/why-your-rag-is-failing/", "title": "Why your RAG implementation is failing in production (and how to fix it)", "summary": "Vector-only retrieval is the silent killer of production RAG. Hybrid search with BM25, reciprocal rank fusion, smarter chunking, re-rankers, and an evaluation harness — the production checklist that turns a flaky demo into a reliable system.", "content_html": "You built a RAG (Retrieval-Augmented Generation) demo. On a local machine, with a handful of PDF files, it looked convincing. The answers felt coherent. The system appeared capable.
\nThen you pushed it to production.
\nThat is usually where the illusion breaks.
\nUsers start reporting that the LLM is \"hallucinating\" when the real issue is retrieval. Obvious answers go missing even though they exist in the documentation. Irrelevant chunks surface because they are semantically adjacent, not actually useful.
\nIf your RAG system feels unreliable in production, you are not dealing with a model problem first. You are dealing with a retrieval design problem. Most production RAG systems fail because they rely too heavily on vector search and confuse a strong demo with a robust system.
\nI've spent a lot of time building custom AI solutions at Ansezz, and one pattern keeps showing up: a demo proves possibility, but production demands precision.
\nThe philosophical shift from demo RAG to production RAG is simple: in a demo, semantic resemblance often feels good enough. In production, \"good enough\" is where failures begin.
\nEmbeddings are useful. They let us map text into vectors and retrieve by meaning rather than exact wording. That is powerful. But semantic similarity is not the same thing as retrieval accuracy.
\nThe problem. Vector search is strong at finding related concepts, but weak at handling specificity.
\nIf a user searches for \"Project-X-99 deployment logs,\" a vector search might return documents about \"Project-A deployment\" or \"logging best practices\" because they are semantically close. It can miss the exact identifier \"X-99\" because that string carries little semantic weight in a high-dimensional space.
\nThe agitation. Once retrieval drifts, the LLM inherits the drift. The model cannot reason its way out of missing or irrelevant context. You end up paying for tokens that produce confident but unhelpful answers, and users lose trust for a reason that often sits one layer below the model itself.
\nThe move from demo RAG to production RAG usually starts with one realization: meaning alone is not enough. You need semantic retrieval and lexical precision working together. This is hybrid search.
\n![\"Hybrid](\"https://ansezz.com/blog/why-your-rag-is-failing/hybrid-search-workflow.webp\")
BM25 (Best Matching 25) is the standard lexical ranking method behind classic search systems. It does not try to infer meaning. It rewards exact terms based on how important they are within a document and across the collection.
\nProduction systems need both because user questions are rarely pure meaning or pure keyword. They are usually a mix of the two.
\n![\"Side-by-side](\"https://ansezz.com/blog/why-your-rag-is-failing/vector-vs-keyword.webp\")
When you run two different retrieval strategies, you also create a new design problem: how should they be combined?
\nA practical answer is Reciprocal Rank Fusion (RRF). It is simple, reliable, and does not require you to pretend that scores from different retrieval systems are directly comparable.
\n![\"Annotated](\"https://ansezz.com/blog/why-your-rag-is-failing/rrf-code-logic.webp\")
The logic breakdown:
\nscore = 1 / (rank + k). The k value (often 60) prevents lower-ranked items from contributing too aggressively.Here's the minimal PHP version I drop into a Laravel service:
\nfunction reciprocalRankFusion(array $resultSets, int $k = 60): array\n{\n $scores = [];\n\n foreach ($resultSets as $results) {\n foreach ($results as $rank => $docId) {\n $scores[$docId] = ($scores[$docId] ?? 0.0) + 1 / ($rank + 1 + $k);\n }\n }\n\n arsort($scores);\n\n return $scores;\n}\nThis gives you a cleaner retrieval layer. If a document is semantically relevant and lexically precise, it moves toward the top for a reason.
\nHybrid search is a strong retrieval foundation, but production RAG usually needs one more layer of judgment.
\nIf you want more precise results, add a re-ranker.
\nA re-ranker such as Cohere Rerank or BGE-Reranker is a cross-encoder model that evaluates the query and the document together. That matters because relevance is relational. It is not just about what a document contains. It is about whether that document answers this question.
\nThis reduces context stuffing and improves the quality of what reaches the model. In practice, it is one of the clearest differences between a RAG demo and a production RAG system that behaves consistently.
\nA RAG system can feel impressive in a demo and still be structurally weak in production.
\nOnce real users, messy documents, and ambiguous queries enter the picture, weak retrieval turns the LLM into expensive guesswork. That is when confidence and correctness start drifting apart.
\nTo move from demo RAG to production RAG, I focus on a few non-negotiables:
\nBuilding AI is easy. Building reliable AI is hard. It requires a deeper understanding of retrieval, ranking, and context design, not just the ability to connect an API.
\nIf you are looking to build a high-performance SaaS or need help modernizing your digital presence with AI that actually works, check out what I do at Ansezz. I specialize in solving these exact types of technical problems.
\nWhere does your own system still behave like a demo when it should be behaving like production? Get in touch — I read every war story.
\n", "date_published": "2026-03-08T00:00:00.000Z", "date_modified": "2026-03-08T00:00:00.000Z", "tags": [ "ai", "rag", "ai", "vector-search", "bm25", "hybrid-search", "re-ranker", "production" ], "image": "https://ansezz.com/blog/why-your-rag-is-failing/hero.webp" }, { "id": "https://ansezz.com/blog/monolith-to-microservices/", "url": "https://ansezz.com/blog/monolith-to-microservices/", "title": "From monolith to micro-services: a senior dev's guide to pragmatic scaling", "summary": "Skip the big-bang rewrite. The strangler fig pattern, anti-corruption layers, Docker-first migration, and GKE/Coolify operations — how I peel services off a Laravel monolith one endpoint at a time without breaking revenue.", "content_html": "Your monolith is a ticking time bomb and every feature you add makes the explosion more inevitable.
\nI have seen it happen a dozen times. A startup begins with a clean Laravel or Rails app. It is fast. It is easy. It is productive. Then the team grows. The code base swells. Suddenly, a simple change to the checkout logic breaks the authentication system. Deployments that used to take five minutes now take forty. You are not scaling your business anymore — you are managing technical debt.
\nThis is the point where most developers start dreaming of micro-services. They imagine a world where every service is isolated and deployments are instant. But the reality is often a nightmare. If you do it wrong, you end up with a distributed monolith. You get all the complexity of networking with none of the benefits of isolation.
\nThe solution is not a \"big bang\" rewrite. It is pragmatic scaling. I use the strangler fig pattern to move from monoliths to micro-services without losing my mind or my job.
\n![\"Strangler](\"https://ansezz.com/blog/monolith-to-microservices/strangler-fig.webp\")
When a monolith becomes too heavy, the immediate reaction is to want to scrap it. I have seen companies spend two years on a rewrite only to ship a product that has half the features of the original. The business dies while the engineers play with new toys.
\nThe monolith is not your enemy. It is just a phase. The real problem is coupling. When every part of your app knows too much about every other part, you cannot move. You are stuck in a web of dependencies. If you try to jump straight into micro-services, you will likely just port those dependencies into a network layer. Now, instead of a function call failing, you have a 500 error across a network socket.
\nI prefer a slower, more deliberate approach. I focus on high-value extractions. I look for the parts of the app that hurt the most. Is the image processing service slowing down the web server? Is the reporting engine locking up the database? Those are your first candidates for micro-services.
\nI named this approach after a tree that grows around another tree. It starts as a small vine and eventually replaces the host entirely. In software, this means building new features as services while the old monolith remains.
\nThe process starts with an API gateway or a load balancer. I use Nginx or Cloud Armor on Google Cloud to route traffic. If a request comes for /api/v1/orders, it goes to the new service. Everything else goes to the old monolith.
This allows me to test the new service in production with real traffic while the monolith acts as a safety net. If the new service fails, I just flip the routing back. I do not have to migrate everything at once. I can migrate one endpoint at a time.
\n![\"Annotated](\"https://ansezz.com/blog/monolith-to-microservices/docker-snippet.webp\")
You cannot do micro-services without Docker. I treat every service as a black box. The monolith might be running on an old version of PHP, while the new service is a lean Go binary or a modern Laravel instance. Docker makes this possible.
\nI start by containerizing the monolith. Even if it stays as a monolith for another year, putting it in a container forces me to define its environment. It makes the infrastructure reproducible.
\n# a simplified example of a service container\nFROM php:8.3-fpm\n\nWORKDIR /app\nCOPY . /app\n\nRUN apt-get update && apt-get install -y \\\n libpq-dev \\\n && docker-php-ext-install pdo_pgsql\n\nEXPOSE 9000\nCMD [\"php-fpm\"]\nOnce the monolith is containerized, I can deploy it to a platform like Google Kubernetes Engine (GKE). This is where the real power of micro-services comes in. I can scale the order service to fifty instances during a sale while keeping the blog service at two.
\n![\"Routing](\"https://ansezz.com/blog/monolith-to-microservices/routing-diagram.webp\")
The hardest part of micro-services is not the code. It is the data. Your monolith has a single database. Your micro-services should each have their own. But how do they talk?
\nI use an anti-corruption layer (ACL). When I extract a service, I do not let it reach back into the monolith's database. That would be cheating. Instead, I create an interface. If the new service needs user data, it asks the monolith via a private API or a message queue like Google Pub/Sub.
\nThis keeps the new service clean. It does not care about the messy database schema of the legacy app. It only cares about the data it receives through the ACL. Eventually, when the user logic is also migrated, I just update the ACL to point to the new user service.
\n![\"Cloud](\"https://ansezz.com/blog/monolith-to-microservices/cloud-infrastructure.webp\")
Scaling a monolith usually means buying a bigger server. Scaling micro-services means managing a fleet. I rely heavily on cloud-native tools to manage the complexity.
\nI use Terraform to manage my infrastructure as code. This ensures that my staging and production environments are identical. If I need a new database for a service, I define it in code. I do not click around in a dashboard.
\nOn the DevOps side, I use tools like GitHub Actions or Coolify for deployments. Every service has its own pipeline. If I update the checkout service, I only deploy the checkout service. I do not have to worry about the rest of the system.
\nI would be lying if I said this was all sunshine and rainbows. Micro-services come with a \"complexity tax.\" You now have to deal with distributed logging, service discovery, and eventual consistency.
\nI tell my clients that they should only move to micro-services when the pain of the monolith is greater than the cost of the complexity tax. If your team is three people and your app is simple, stay in the monolith. You will move faster.
\nBut if you are hitting walls every day and your developers are afraid to touch the code, it is time to start strangling.
\nMigration is a marathon, not a sprint. I have spent months on a single extraction just to make sure it was perfect. The goal is not to have micro-services. The goal is to have a system that can grow with your business.
\nHave you ever tried a \"big bang\" rewrite only to regret it six months later? Tell me about it — I collect these stories for a reason.
\n", "date_published": "2026-02-22T00:00:00.000Z", "date_modified": "2026-02-22T00:00:00.000Z", "tags": [ "architecture", "monolith", "micro-services", "scaling", "strangler-fig", "docker", "kubernetes", "devops", "laravel" ], "image": "https://ansezz.com/blog/monolith-to-microservices/hero.webp" }, { "id": "https://ansezz.com/blog/laravel-multi-tenancy/", "url": "https://ansezz.com/blog/laravel-multi-tenancy/", "title": "Laravel multi-tenancy: how I built a scalable SaaS architecture", "summary": "Single DB vs multi-DB, global scopes that stop data leaks, stancl/tenancy in production, isolated storage, automated migrations, and the Docker + Google Cloud setup I run for high-trust SaaS clients.", "content_html": "I still remember the panic of my first SaaS launch. I was watching the logs as the third customer signed up. Suddenly I realized I had no idea if customer A could see customer B's data. That realization is a rite of passage for every developer.
\nBuilding a software-as-a-service (SaaS) platform is a massive technical challenge. The biggest hurdle is almost always data isolation. You need to ensure that every tenant feels like they have the whole application to themselves. If you get this wrong early on, it will haunt you forever.
\nI have spent years refining a scalable architecture using Laravel. It is the most robust way to handle multiple customers on a single codebase. Here is how I approach the architecture to ensure security and scalability.
\nMost developers start with a single database. They add a user_id or team_id to every table. It works fine for the first ten users. Then the complexity grows.
You start adding more relationships. You forget to add a where clause in one obscure controller. Suddenly one customer is seeing another customer's private invoices. This is a catastrophic failure. It kills trust and can end your business overnight.
Performance also becomes a nightmare. As your database grows to millions of rows the queries get slower. Indexing helps, but it does not solve the fundamental problem of data bloat. You need a strategy that isolates data while keeping your infrastructure manageable.
\n![\"Tenant](\"https://ansezz.com/blog/laravel-multi-tenancy/architecture.webp\")
When I build custom web solutions I always start by choosing between two main paths. You either go with a single database or a multi-database setup.
\nThe single database approach uses a shared schema. Every row has a tenant_id. It is cheap to run and easy to update. I recommend this for startups where costs need to stay low. You can manage thousands of small tenants on a single server this way.
The multi-database approach is the gold standard for enterprise. Every customer gets their own database. This offers the best security and makes backups easy. If one database crashes the others stay online. I use this for high-value clients who have strict compliance needs.
\nI often use the stancl/tenancy package for Laravel. It is the most flexible tool in the ecosystem. It allows you to switch between these strategies as your business grows. You can find out more about how I handle these complex technical challenges on the Ansezz work page.
The secret to sleeping well at night is automation. I never rely on my memory to filter data. Instead I use Laravel global scopes.
\nA global scope automatically adds a filter to every query on a model. It ensures that Customer::all() only returns customers for the current tenant. It happens behind the scenes so you cannot forget it.
![\"Annotated](\"https://ansezz.com/blog/laravel-multi-tenancy/code-snippet.webp\")
I create a BelongsToTenant trait. I apply this trait to every model that needs isolation. It handles the filtering and automatically sets the tenant_id when a new record is created. It is a simple solution that prevents 99 percent of data leaks.
Here's what that trait looks like in practice:
\n<?php\n\nnamespace App\\Concerns;\n\nuse App\\Models\\Tenant;\nuse App\\Scopes\\TenantScope;\nuse Illuminate\\Database\\Eloquent\\Relations\\BelongsTo;\n\ntrait BelongsToTenant\n{\n protected static function bootBelongsToTenant(): void\n {\n static::addGlobalScope(new TenantScope());\n\n static::creating(function ($model): void {\n if (! $model->tenant_id && app()->bound('tenant')) {\n $model->tenant_id = app('tenant')->id;\n }\n });\n }\n\n public function tenant(): BelongsTo\n {\n return $this->belongsTo(Tenant::class);\n }\n}\nYou also need to isolate your cache and your file storage. If two tenants upload a file named logo.png they should not overwrite each other. I configure Laravel to use tenant-specific prefixes for all storage paths. This creates a true \"sandbox\" environment for every user.
Your architecture is only as good as the infrastructure it runs on. I usually deploy my Laravel apps using Docker and cloud providers like Google Cloud or AWS.
\nContainerization is key. It allows me to scale the application horizontally. When traffic spikes I can spin up more instances of the web server. Because the multi-tenancy logic is handled at the application level, the infrastructure stays clean.
\n![\"Cloud](\"https://ansezz.com/blog/laravel-multi-tenancy/infrastructure.webp\")
I use managed database services like Google Cloud SQL. They handle the heavy lifting of backups and scaling. For multi-database setups I use automated scripts to provision new databases whenever a customer signs up. This \"infrastructure as code\" approach ensures that scaling is a button click away.
\nIf you are looking to modernize your digital presence with a scalable cloud setup you can see my full range of services at ansezz.com.
\nThe final piece of the puzzle is the user interface. Customers need a seamless way to move between different accounts if they own multiple businesses.
\nI build clean dashboards using Vue. The frontend communicates with the Laravel backend via GraphQL APIs. This setup allows for a very fast and reactive user experience. The tenant switcher is always accessible and shows the user exactly which context they are working in.
\n![\"Tenant](\"https://ansezz.com/blog/laravel-multi-tenancy/tenant-switcher.webp\")
I focus on making the transition between tenants feel instant. I cache the tenant configuration in the frontend to avoid unnecessary API calls. It is these small details that separate a basic app from a high-quality pro solution.
\nIf you are starting a new project today, here are the steps I recommend you follow.
\nstancl/tenancy because of its flexibility. It handles subdomain routing and database switching out of the box.stancl/tenancy have built-in commands for this.Are you building a SaaS or looking to migrate your current app to a multi-tenant structure? What is the biggest technical hurdle you are facing right now? Get in touch — I'd love to hear about it. 🤙
\n", "date_published": "2026-02-08T00:00:00.000Z", "date_modified": "2026-02-08T00:00:00.000Z", "tags": [ "laravel", "laravel", "multi-tenancy", "saas", "architecture", "stancl-tenancy", "docker", "postgres" ], "image": "https://ansezz.com/blog/laravel-multi-tenancy/hero.webp" }, { "id": "https://ansezz.com/blog/ai-vs-traditional-development/", "url": "https://ansezz.com/blog/ai-vs-traditional-development/", "title": "AI integration vs traditional development: which is better for your business in 2026?", "summary": "Speed, control, or a hybrid path? When AI-assisted development pays off, when traditional engineering is non-negotiable, and the hybrid workflow I recommend most often to founders and tech leads.", "content_html": "Most teams are asking the wrong question.
\nThe real problem is not \"AI or traditional development?\" — it is what kind of speed, control, and risk your business can actually afford.
\nI see this mistake a lot. Teams chase AI because it feels faster. Or they reject it because it feels messy. Then they end up with the same problem from both directions. Rushed systems with weak foundations, or polished systems that ship too late.
\nThe better move is to understand where each approach wins, where it breaks, and where a hybrid model gives you the best return.
\nBoth approaches work. They just solve different problems.
\nAI integration changes how I build software. Instead of manually writing every repetitive piece, I can use tools that understand context, generate scaffolding, speed up testing, and remove a lot of the drag from delivery.
\nThis is where AI shines.
\nFor standard workflows, admin panels, CRUD-heavy systems, internal tools, and first-pass prototypes, AI can cut a serious amount of time. What used to take weeks can often be reduced to days if the scope is clear and the review process is tight.
\nThat speed usually comes from a few places:
\n![\"Architecture](\"https://ansezz.com/blog/ai-vs-traditional-development/workflow.webp\")
I would lean toward AI-heavy workflows when speed matters more than perfect customization on day one.
\nThat usually means:
\nIn those cases, AI acts like a power tool. It does not replace the builder. It just makes the first cut much faster.
\nThis is where a lot of teams get burned.
\nAI is fast at common patterns. It is weaker at deep product nuance, strange business rules, and systems that need careful long-term architecture. If you skip review, you can ship something that looks finished but behaves like a prototype wearing a production costume.
\nThat means I would not treat AI output as truth. I would treat it as a draft.
\nTraditional development is slower, but it gives me tighter control over how the system is shaped.
\nThis is the path I trust most when the business rules are complex, the architecture matters, or the cost of failure is high. Every part of the system is designed with intent instead of inferred from a prompt.
\nTraditional development is better when the software needs precision.
\nThat matters for:
\nOne underrated benefit of traditional development is predictability.
\nManual design, explicit code reviews, architecture decisions, and planned testing give me a clearer picture of trade-offs. It is like building with blueprints instead of assembling furniture from a photo.
\nThat slower process often saves time later because fewer assumptions make it into production.
\nThe downside is obvious.
\nManual coding, reviews, debugging, refactoring, and testing take time. You need stronger engineering talent, and you need the discipline to keep standards high when deadlines start squeezing the team.
\nTraditional development gives more control, but you pay for it in time and cost.
\n| Factor | \nAI-Powered Development | \nTraditional Development | \n
|---|---|---|
| Development speed | \n30–50% faster completion | \nStandard industry timelines | \n
| Cost structure | \nLower long-term expenses | \nHigher labor costs | \n
| Team requirements | \nMixed skill levels acceptable | \nRequires senior expertise | \n
| Customization level | \nLimited by AI training data | \nUnlimited customization | \n
| Quality assurance | \nAutomated testing and fixes | \nManual review processes | \n
| Risk management | \nVariable based on AI reliability | \nPredictable risk factors | \n
| Scalability | \nRapid scaling through automation | \nScales with team growth | \n
Choose AI when your bottleneck is delivery speed and the work is close to known patterns.
\nThat usually applies when:
\nChoose traditional development when the cost of being wrong is higher than the cost of being slower.
\nThat usually means:
\nThis is the option I recommend most often.
\nThe strongest teams do not treat this like a religion. They use AI where speed helps and switch to traditional engineering where judgment matters.
\nA practical hybrid setup looks like this:
\nThe hybrid model works because it treats AI like a junior accelerator, not like an autopilot.
\nIf I were introducing AI into an existing team, I would start small.
\nIf the team stays mostly traditional, I would protect the basics.
\nIf the goal is balance, then the workflow matters more than the tools.
\nThe teams that will win in 2026 are not the ones that blindly choose AI or reject it.
\nThey are the ones that know where speed is enough, where control is non-negotiable, and where a hybrid model gives them leverage without chaos.
\nThat is the real solution.
\nUse AI to remove friction. Use traditional engineering to protect the parts that matter. Combine both when the business needs speed and reliability at the same time.
\n![\"Final](\"https://ansezz.com/blog/ai-vs-traditional-development/workspace.webp\")
Your development strategy should match your business goals, not the trend cycle. If you had to choose today, which matters more for your next product: speed, control, or a hybrid path? Reach out — I'd love to hear which side you're leaning toward.
\n", "date_published": "2026-01-25T00:00:00.000Z", "date_modified": "2026-01-25T00:00:00.000Z", "tags": [ "architecture", "ai", "strategy", "hybrid", "business", "decision-making", "productivity" ], "image": "https://ansezz.com/blog/ai-vs-traditional-development/hero.webp" }, { "id": "https://ansezz.com/blog/scaling-with-coolify/", "url": "https://ansezz.com/blog/scaling-with-coolify/", "title": "Scaling with confidence: advanced Coolify deployment strategies", "summary": "Move past the single-server trap. Multi-node Coolify setups, zero-downtime rolling deploys with health checks, dedicated build servers, managed databases, and GitHub Actions wiring — production-grade self-hosting without a DevOps team.", "content_html": "You've finally moved your apps off that messy manual VPS and into Coolify. It feels great. Everything is in one place. But then the traffic starts to spike. You realize that hosting your production database, three web apps, and a memory-heavy build process on a single $10 DigitalOcean droplet is a recipe for disaster.
\nThe \"single server trap\" is real. It's fine for a side project or a quick MVP. But when you're building for real customers, you need more than just a dashboard. You need a strategy. You're worried about what happens when that one server hits 100% CPU or when a simple deployment takes your whole site down for five minutes.
\nI've spent the last decade scaling web applications and building custom solutions at Ansezz. I've seen self-hosted setups crumble under pressure because they lacked the right architecture. The good news is that Coolify is more than capable of handling high-scale workloads. You just need to know how to pull the right levers.
\nIn this guide, I'm going to show you how to move from a basic setup to a production-grade infrastructure using advanced Coolify strategies. We're talking multi-server nodes, zero-downtime deployments, and offloading the heavy lifting so your apps stay snappy.
\nThe biggest mistake I see engineers make is keeping everything on one node. When your build process starts, it eats up CPU and RAM. Your web app starts to lag. Your database gets starved for resources.
\nThe solution is to decouple your \"control plane\" from your \"workloads.\"
\nIn a professional setup, you want one small server dedicated solely to running the Coolify instance itself. This is your mission control. Then, you add separate \"app servers\" where your actual containers live.
\n![\"Multi-server](\"https://ansezz.com/blog/scaling-with-coolify/multi-server.webp\")
To do this in Coolify, you go to the Servers tab and add a new server via SSH. Once it's connected, you can choose which server a specific resource should be deployed to. This gives you instant horizontal scalability. If one server is getting full, you just spin up another one, add it to Coolify, and point your next app there.
\nThis separation of concerns is a core pillar of what we do when building custom web applications. It prevents a single point of failure from taking down your entire digital presence.
\nNothing kills user trust faster than a \"502 Bad Gateway\" every time you push a small CSS fix. By default, many self-hosted setups just kill the old container and start the new one. There's a gap. That gap is where your users get frustrated.
\nCoolify handles this beautifully with \"rolling updates,\" but it only works if you tell it how to check the health of your app.
\nIf you don't configure health checks, Traefik (the reverse proxy Coolify uses) might start sending traffic to your new container before the app inside it has even finished booting up.
\n![\"Dashboard](\"https://ansezz.com/blog/scaling-with-coolify/health-checks.webp\")
Here is the workflow I use to ensure 100% uptime:
\n/healthz. It should return a 200 status code only when the app is ready to serve traffic./healthz and the interval to something like 5 seconds./healthz endpoint returns a success before it switches the traffic over. The old container is only killed after the new one is confirmed live.This is a non-negotiable step for any SaaS or e-commerce store where every second of downtime equals lost revenue.
\nIf you're building a modern app with Docker, the build process can be incredibly resource-intensive. Compiling assets, installing npm packages, and building images can spike your server usage to the moon.
\nIf you're running that build on the same server that's trying to serve your customers, they're going to feel the slowdown.
\nAdvanced users leverage a dedicated build server.
\nYou can designate a high-performance, high-CPU server in Coolify specifically for builds. When you trigger a deployment, Coolify pushes the code to the build server, creates the image there, and then pushes the finished image to your production app server.
\nYour production server never feels a thing. It just gets a fresh, ready-to-run image.
\nWhile Coolify makes it easy to click \"New Database,\" running your production Postgres or MySQL inside a Docker container on the same server as your app is risky.
\nFor production workloads, I almost always recommend using an external managed database like AWS RDS or Google Cloud SQL. It handles backups, point-in-time recovery, and scaling automatically.
\nIn Coolify, you simply provide the connection string as an environment variable. This keeps your state (the data) separate from your compute (the app). If your app server goes up in flames, your data is safe on a managed platform.
\nManual deployments are for hobbyists. For a professional workflow, you want your code to move from GitHub to production without you touching a single button in the Coolify UI.
\nI prefer using GitHub Actions for this. While Coolify has a great GitHub App integration, using Actions gives you more control. You can run your test suite, lint your code, and only if everything passes, trigger the Coolify deployment via a webhook.
\n![\"Pop-art](\"https://ansezz.com/blog/scaling-with-coolify/cicd-pipeline.webp\")
Here is a snippet of how I usually structure a simple deployment step in a .github/workflows/deploy.yml file:
name: deploy to production\non:\n push:\n branches:\n - main\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n steps:\n - name: trigger coolify webhook\n run: |\n curl -X GET \"${{ secrets.COOLIFY_WEBHOOK_URL }}\"\nIt's simple, direct, and ensures that broken code never reaches your servers. It keeps your development cycle clean and your mental health intact.
\nManaging a multi-server setup requires a bit of extra care. Here are a few practical takeaways to keep in your back pocket:
\nScaling isn't about having the most expensive hardware. It's about having a system that is predictable and resilient. Coolify gives us the tools to act like a giant tech company without the massive overhead of a dedicated DevOps team.
\nBy splitting your servers, mastering health checks, and automating your builds, you move from \"hoping it works\" to \"knowing it scales.\"
\nI've helped dozens of founders and tech leads navigate these waters. Whether you're building a Shopify app or a complex Laravel SaaS, the principles are the same. Keep your compute separate from your data, and your builds separate from your traffic.
\nHave you ever had a deployment go sideways because a build process crashed your production server? What's your current \"war story\" from the world of self-hosting? Drop me a line.
\n", "date_published": "2026-01-11T00:00:00.000Z", "date_modified": "2026-01-11T00:00:00.000Z", "tags": [ "devops", "coolify", "deployment", "devops", "docker", "self-hosting", "ci-cd", "scaling" ], "image": "https://ansezz.com/blog/scaling-with-coolify/hero.webp" }, { "id": "https://ansezz.com/blog/shopify-liquid-vs-headless/", "url": "https://ansezz.com/blog/shopify-liquid-vs-headless/", "title": "Shopify Liquid vs. headless: choosing the right stack for scale", "summary": "Hydrogen looks great on paper. Liquid still ships more revenue per week. A practical decision framework for picking between Liquid, headless Hydrogen, and the messy middle — based on what your team can actually operate long-term.", "content_html": "Your store is making money, but every new change feels like surgery on a moving car.
\nTraffic is up. Orders are up. Pressure is up. But the theme layer is starting to fight back. Simple feature requests turn into fragile hacks. App scripts pile up. Mobile performance gets softer with every install. What used to feel fast and convenient now feels like a ceiling.
\nThis is where a lot of brands start looking at headless. The promise sounds great. More freedom. Better performance. Cleaner frontend architecture. But this is also where expensive mistakes happen. A headless rebuild can solve real problems — or create a second system your team now has to babysit forever.
\nThe real question is not which stack sounds more modern. The real question is which stack fits your stage, your team, and your operational reality.
\nLiquid is still the default winner for a reason. It is tightly integrated with Shopify, fast to ship, and much easier to maintain than a custom headless frontend.
\nFor most growth-stage stores, Liquid gives the best speed-to-market. Online Store 2.0 made theme architecture much more modular than the old days, so a solid theme setup can go a long way before it becomes a real blocker.
\nThis is the part people underestimate. A good Liquid stack is like a well-tuned production van. It is not flashy, but it moves product reliably, gets updated quickly, and does not need a pit crew every week.
\nThe problem shows up when business needs outgrow theme constraints. Maybe the storefront needs deeply custom interactions. Maybe product data has to come from an ERP, a PIM, and a custom backend at the same time. Maybe merchandising logic is getting too complex for theme code to stay clean. That is usually the point where headless becomes a serious conversation, not just a trendy one.
\n![\"Performance](\"https://ansezz.com/blog/shopify-liquid-vs-headless/performance-metrics.webp\")
Performance is the most common reason teams start looking at headless. And yes, milliseconds matter. On e-commerce storefronts, small delays compound into lower conversion rates, weaker ad efficiency, and a worse mobile experience.
\nA well-built headless stack using Hydrogen and Oxygen can push performance much further than a typical theme setup. You get finer control over rendering, data loading, caching, and frontend execution. That opens the door for lower LCP and a more responsive storefront.
\nBut this is where the hype needs a reality check. Headless does not automatically mean faster. It only gets faster when the frontend architecture is actually good.
\nIf the team over-fetches GraphQL data, hydrates too much JavaScript, or ships a bloated component tree, the custom storefront can end up slower than a decent Liquid theme. That happens more often than people admit.
\nSo yes, headless can be a performance win. But only if the implementation is disciplined.
\n![\"Architecture](\"https://ansezz.com/blog/shopify-liquid-vs-headless/architecture-diagram.webp\")
Going headless means splitting commerce from presentation. Shopify still handles products, checkout, and admin workflows. Your custom frontend handles the customer experience.
\nThat sounds clean on paper. In practice, it means you now own two systems instead of one.
\nYou need to manage hosting, deployments, caching, GraphQL queries, error handling, observability, and integration behavior across services. Every app in the stack has to be checked for API compatibility. If an app only works by injecting snippets into a theme, that convenience is gone.
\nThis is the part that catches teams off guard. In Liquid, many features feel plug-and-play. In headless, the same features often become custom integration work. Reviews, loyalty, search, subscriptions, personalization, analytics. All of it may need extra engineering.
\nThe easiest way to think about it is this: Liquid is renting a well-equipped shop. Headless is designing your own building. You get more freedom, but now plumbing, wiring, and maintenance are your problem too.
\n![\"Timeline](\"https://ansezz.com/blog/shopify-liquid-vs-headless/timeline-comparison.webp\")
Time and budget usually decide this faster than architecture opinions do.
\nA custom Liquid theme can often be launched in weeks. That means faster testing, faster iteration, and lower implementation cost. If the business mainly needs merchandising flexibility, better UX, and cleaner performance hygiene, Liquid usually gives a better return.
\nHeadless is a different category of investment. The build takes longer. The team needs stronger frontend engineering. The integration surface is bigger. And maintenance does not stop after launch.
\nThis is the important part. With headless, you are not just paying for a redesign. You are taking on a software product that needs ongoing care. Deployments, monitoring, API changes, dependency updates, caching strategy, and developer ownership all become part of normal operations.
\nFor many stores, that trade-off is not worth it yet. More freedom is great, but freedom is expensive when the business does not fully need it.
\nI like to reduce this decision to a few practical questions.
\nThe simplest stack that solves the real bottleneck is usually the best stack. Building a spaceship to cross the street is still a bad decision.
\nIf you are stuck between Liquid and headless, start here:
\nChoosing a stack is a long-term commitment. The right answer is not the most advanced one. It is the one that solves the current bottleneck without creating three new ones.
\nAre you dealing with real technical limits in Shopify, or just feeling the pull of a more customizable stack? Drop me a line — happy to do a 30-minute architecture sanity check.
\n", "date_published": "2025-12-28T00:00:00.000Z", "date_modified": "2025-12-28T00:00:00.000Z", "tags": [ "shopify", "shopify", "liquid", "headless", "hydrogen", "performance", "architecture", "ecommerce" ], "image": "https://ansezz.com/blog/shopify-liquid-vs-headless/hero.webp" }, { "id": "https://ansezz.com/blog/picking-the-right-rag-stack/", "url": "https://ansezz.com/blog/picking-the-right-rag-stack/", "title": "Picking the right RAG stack: vector databases for AI engineering", "summary": "pgvector, Pinecone, Weaviate, Qdrant — a 2026 field guide. Which vector store to pick for your AI app, why hybrid search matters, and how to ship without painting yourself into a corner.", "content_html": "You built a cool chatbot. It works great on your local machine until you feed it 50,000 internal documents. Suddenly, it's hallucinating. It's slow. It's pulling data from three years ago when you specifically asked for last week's report.
\nBuilding a Retrieval-Augmented Generation (RAG) system sounds like a weekend project. But once you move past the \"hello world\" stage, you hit the database wall. Choosing the wrong vector store early on is a silent killer. It leads to high latency, soaring cloud costs, and a painful migration six months down the line when your data outgrows your infrastructure.
\nI've spent over a decade building custom web applications and scaling cloud infrastructure. I've seen teams get paralyzed by the sheer number of options in the AI ecosystem. You don't need a perfect database. You need the right tool for your specific scale and team.
\nLet's break down the 2026 vector database landscape so you can stop scrolling and start shipping.
\nAn LLM like Claude or GPT-4 is a genius without a memory. RAG gives it that memory. Your vector database is the librarian. If the librarian is slow or loses books, the genius can't do its job.
\nWhen we talk about RAG stacks, we're looking for three things:
\n![\"Comparison](\"https://ansezz.com/blog/picking-the-right-rag-stack/comparison-bento.webp\")
If you are already running Postgres for your web applications, pgvector is usually your first stop. It's not a new database. It's an extension that adds vector support to the database you already trust.
\nIt's perfect if you have under 10 million vectors. You get ACID compliance, easy backups, and your relational data stays right next to your embeddings. No new infra. No new security audits.
\nPros
\nCons
\nPinecone is the gold standard for managed service. It's a serverless vector database. You don't manage clusters. You don't tune indexes. You just send vectors and get results.
\nIn 2026, Pinecone is the go-to for teams that want to scale from zero to a billion vectors without hiring a dedicated DevOps engineer. Their serverless architecture means you only pay for what you use.
\nPros
\nCons
\nIf your RAG app needs to combine semantic search with old-school keyword search, these two are the leaders. Weaviate and Qdrant are built from the ground up for high-performance vector retrieval.
\nWeaviate excels at \"out-of-the-box\" hybrid search. Qdrant, written in Rust, is incredibly fast and efficient with memory. Both offer open-source versions and managed cloud options.
\nPros
\nCons
\n![\"Reference](\"https://ansezz.com/blog/picking-the-right-rag-stack/rag-architecture.webp\")
Picking a database isn't about finding the \"best\" one. It's about matching the tool to your engineering constraints.
\nMost startups don't have a billion vectors. They have a few thousand PDFs. If you're in the sub-1M range, pgvector is almost always the right answer. It's simple and it works.
\nIf you are building something like a global legal search engine or a massive e-commerce recommendation system, you need the distributed architecture of Milvus or Pinecone. Don't build a massive distributed system if you don't have a massive amount of data.
\nPure vector search is actually pretty bad at finding specific technical terms. If you search for \"PHP 8.4 features,\" a pure vector search might give you general \"PHP\" articles. A hybrid search combines the \"vibe\" of the vector with the \"exactness\" of a keyword search.
\nIf search quality is your #1 metric, look at Weaviate or Qdrant. They handle the blending of these two search types natively.
\nI'm a huge fan of cloud infrastructure and deployment. But I also know that every new piece of infra you add to your stack is another thing that can break at 3 AM.
\nIf you have a small team, lean on managed services like Pinecone or Zilliz. If you have a strong infra team and want to save on cloud margins at high scale, self-hosting Qdrant on a tool like Coolify or Kubernetes is the move.
\nSince I work a lot with custom web development using Laravel, I want to show you how easy this looks in practice. You don't need a PhD in math to run a vector query.
\n// finding the most relevant document chunks\n$embedding = Ai::embed($query); // get vector from OpenAI/Claude\n\n$results = Document::query()\n ->select('content')\n ->orderByRaw('embedding <=> ?', [$embedding]) // the <=> operator is pgvector's magic\n ->limit(5)\n ->get();\nThat snippet is essentially the core of a RAG system. You find the content, send it to the LLM, and get a grounded answer.
\n![\"Annotated](\"https://ansezz.com/blog/picking-the-right-rag-stack/code-snippet.webp\")
Before you commit to a database, keep these three things in mind. They will save you weeks of refactoring.
\n1. Index early, but not too early.\nVector indexes like HNSW are fast for searching but slow for inserting data. If you are doing a massive initial data load, insert your vectors first, then create the index. It's the difference between minutes and hours.
\n2. Normalize your vectors.\nMake sure your embedding model and your vector database are on the same page. If you use cosine similarity, normalize your vectors. It keeps your results consistent and prevents weird ranking bugs.
\n3. Keep the metadata lean.\nIt's tempting to store the entire JSON object of a document inside your vector database. Don't. Store the vector and a simple ID. Keep the heavy data in your primary database (like Postgres). This keeps your vector index small and fast.
\nI've built systems for startups and established businesses. Here is how I usually guide them:
\nThe \"right\" stack is the one that lets you ship your AI features today, not the one that looks the best on a benchmark chart.
\nAre you building a RAG system right now? What's the biggest hurdle you've hit with your data retrieval?
\nDrop a line or reach out. I'd love to hear your war stories.
\nSummary takeaways
\n![\"Mentor](\"https://ansezz.com/blog/picking-the-right-rag-stack/mentor.webp\")
Most developers are obsessed with logic. We spend years mastering syntax, optimizing database queries, and debating the merits of different architectural patterns. We build systems that are technically perfect but somehow feel completely hollow. They work, but they don't sing.
\nThe problem is that your users don't care about your clean code or your clever recursive functions. They care about how the software feels. They care about the \"vibe.\"
\nIf you keep building purely for the machine, you are going to lose. The next generation of successful products won't be the ones with the most features or the tightest algorithms. They will be the ones that master the art of vibe coding.
\nI've spent over a decade in the trenches of software development. I've built custom web applications for startups and managed complex cloud infrastructure on Google Cloud and AWS. For a long time, I thought my job was to be a logic machine. I thought that if I followed every best practice and wrote the most efficient Laravel code possible, the project would be a success.
\nI was wrong.
\nLogic is just the foundation. It is the skeleton that keeps the building from falling down. But nobody wants to live in a skeleton. People want a home with character, warmth, and a specific feeling. In software, that character comes from the vibe.
\nWhen we focus purely on logic, we end up with \"boring\" software. It is the kind of software that does what it says on the tin but leaves the user feeling nothing. Or worse, it feels frustrating because the developer didn't think about the emotional friction of a slow-loading button or a confusing layout.
\n![\"Side-by-side](\"https://ansezz.com/blog/vibe-coding/logic-vs-vibe.webp\")
The term \"vibe coding\" was popularized recently by Andrej Karpathy. It describes a shift in how we build things in the age of AI tools like Cursor and Claude. It is a transition from being a writer of code to being a curator of intent.
\nVibe coding is about letting go of the need to micro-manage every semicolon. It is about using natural language to describe the feel and behavior you want, and then letting AI handle the heavy lifting of the implementation.
\nIn this world, your value as an engineer isn't in how fast you can type. It's in your taste. It's in your ability to recognize when a user interface feels \"off\" and knowing how to steer the AI to fix it. It is about prioritizing the outcome over the output.
\nI've seen this shift firsthand in my own work at Ansezz. When I'm working on a Shopify store development project, the technical logic of the checkout is important. But the vibe of the checkout — the smooth transitions, the reassuring feedback, the perfect typography — is what actually drives conversions for the business.
\nTo embrace vibe coding, you need tools that don't get in your way. You need tools that allow you to stay in a state of flow where the distance between your idea and the execution is as small as possible.
\nTools like Cursor have changed the game for me. Instead of spending twenty minutes setting up boilerplate for a new Vue component, I can describe the \"vibe\" of the component in the chat. I can say, \"build me a dashboard widget that feels airy and modern, uses a bento grid layout, and gives the user a sense of calm control over their data.\"
\n![\"AI-powered](\"https://ansezz.com/blog/vibe-coding/ai-ide.webp\")
The AI generates the code. I review it. If the vibe isn't right, I don't fix the code line-by-line. I talk to the model again. I give it feedback on the feeling. \"This feels too cramped. Give it more white space and make the shadows softer.\"
\nThis is the essence of vibe coding. It's a high-level conversation about intent.
\nNow, I know what some of you are thinking. \"This sounds like a recipe for a messy, unmaintainable codebase.\"
\nYou are right to be worried. If you just \"vibe\" your way through a project without any discipline, you will end up with a \"ball of mud.\" This is where the senior engineer perspective becomes more critical than ever.
\nVibe coding isn't about being lazy. It's about shifting your focus. You use your senior-level expertise to build the \"robust core\" that allows the \"vibe layer\" to exist.
\nFor me, that core is often built with Laravel and Docker. I use Laravel because it is built for \"developer happiness.\" The framework itself has a vibe of elegance and simplicity. It provides the solid, logical foundation — the authentication, the database migrations, the API structures — that I can trust.
\nOnce that robust core is in place, I can afford to be more exploratory with the frontend and the user experience. I can \"vibe code\" the top layer because I know the foundation is solid.
\n![\"Architecture](\"https://ansezz.com/blog/vibe-coding/architecture.webp\")
If you work in e-commerce, vibe coding is your secret weapon. Shopify is a platform that already understands the importance of the feel. They have spent years perfecting the checkout flow and the admin experience.
\nWhen I do Shopify customization, I'm not just writing Liquid code. I'm trying to match the brand's vibe. A luxury jewelry brand needs a completely different \"vibe\" than a high-energy fitness store.
\nOne should feel slow, deliberate, and expensive. The other should feel fast, punchy, and motivating. You can't achieve that through logic alone. You achieve it by obsessing over the details that the logic-only dev ignores.
\nIf you want to move beyond being a logic-only developer, here are some practical steps you can take:
\nWe are entering a time where \"coding\" as we knew it is becoming a commodity. Anyone can generate a function to sort an array. But not everyone can create an experience that moves people.
\nThe future of software development belongs to the engineers who can bridge the gap between the machine and the human heart. It belongs to the people who understand that the best code is the code you don't even notice because you're too busy enjoying the vibe.
\nI've seen the results of this approach in my own projects and for the clients I work with. When you stop fighting the logic and start leaning into the flow, everything becomes easier. The work becomes more fun, and the results become more impactful.
\nAre you ready to stop just writing logic and start building vibes?
\nWhat is the one app you use that just \"feels\" right, and what can you steal from its vibe for your next project?
\n", "date_published": "2025-11-30T00:00:00.000Z", "date_modified": "2025-11-30T00:00:00.000Z", "tags": [ "ai", "vibe-coding", "ai", "cursor", "claude", "taste", "dx", "laravel" ], "image": "https://ansezz.com/blog/vibe-coding/hero.webp" }, { "id": "https://ansezz.com/blog/hello-world/", "url": "https://ansezz.com/blog/hello-world/", "title": "Hello, world. Yes, another developer blog.", "summary": "Why this site exists, what I'll write about, and why neobrutalism is the right call for an engineer's portfolio in 2026.", "content_html": "import SpeechBubble from \"@/components/neobrutalist/SpeechBubble.astro\";\nimport StickyNote from \"@/components/neobrutalist/StickyNote.astro\";\nimport CodeBlock from \"@/components/neobrutalist/CodeBlock.astro\";\nimport ComparisonTable from \"@/components/neobrutalist/ComparisonTable.astro\";\nimport BurstBadge from \"@/components/neobrutalist/BurstBadge.astro\";
\nMost developer blogs read like a LinkedIn post had a baby with a Medium article.\nThis one won't. I'm Anass. I ship Laravel + Shopify + AI for a living, and this is\nwhere I take notes out loud.
\nI've spent 10+ years remote, mostly head-down in client codebases. The patterns I keep\nreaching for — Laravel Octane at scale, RAG done right, agentic commerce — don't show up\nin tutorials. So I'm writing them down.
\n\n Strong opinions, loosely held. Code that runs in production.\n\n<ComparisonTable\ncolumns={[\n{ label: \"This blog\", tone: \"yellow\" },\n{ label: \"AI-slop blog\", tone: \"red\" },\n]}\nrows={[\n{\nicon: \"lucide:check\",\nlabel: \"Real production code\",\ncells: [true, false],\n},\n{ icon: \"lucide:zap\", label: \"Opinions\", cells: [true, false] },\n{ icon: \"lucide:bot\", label: \"GPT-written filler\", cells: [false, true] },\n{ icon: \"lucide:smile\", label: \"Personality\", cells: [true, false] },\n]}\n/>
\nEvery post that needs code gets the syntax treatment:
\n<CodeBlock\ncode={use Prism\\\\Prism\\\\Prism;\\n\\n$response = Prism::text()\\n ->using('anthropic', 'claude-opus-4-7')\\n ->withSystemPrompt('You are a senior Laravel engineer.')\\n ->withPrompt('Refactor this controller for clarity.')\\n ->asText();}\nlang=\"php\"\nfilename=\"app/Actions/AskClaude.php\"\n/>
That's it. First post live. More incoming.
\n", "date_published": "2025-11-16T00:00:00.000Z", "date_modified": "2025-11-16T00:00:00.000Z", "tags": [ "career", "meta", "intro" ] } ] }