AZURE ARCHITECTURE BLOG · 8 MIN READ

Author: Arturo Quiroga, Senior Partner Solutions Architect — Microsoft

---

Two months ago I published From Prompt to Production: Building Azure Architecture Diagrams with AI, introducing the open-source Azure Architecture Diagram Builder. The response was humbling — thousands of you read it, tried the tool, and filed issues and feature requests. A follow-up on how the Well-Architected Framework scoring works went deep on validation.

You asked, and the tool grew. This post is about what’s new since May — and one change big enough to reframe the whole project: the Azure Architecture Diagram Builder is no longer just an app you click. It’s a partner you chat with, and a tool other agents can call.

TL;DR. Three arcs of new capability: (1) Architecture Chat turns diagram design into a multi-turn conversation over the live canvas; (2) Blueprint Diagrams produce hand-drawn, whiteboard-style deliverables alongside the formal topology; and (3) the app now exposes its capabilities as a Model Context Protocol (MCP) server, so AI agents can generate, validate, cost, and render Azure architectures programmatically. Plus a 13-model fleet, deployment guides grounded in Microsoft Learn, and July output enhancements.

---

What’s new at a glance

---

From clicking to conversing: Architecture Chat

The single most common request after the launch post was some version of “I love the first diagram, but I want to iterate without re-writing the whole prompt.” Regenerating from scratch every time you tweak a requirement is slow and loses context.

Architecture Chat solves this. It’s a conversational panel that sits alongside the canvas and treats your diagram as a living document. Each message is a turn in an ongoing design session:

• “Add an Azure Front Door with WAF in front of the app tier.”
• “Now make the data layer zone-redundant.”
• “Swap the SQL Database for Cosmos DB and update the connections.”

Every turn reads the current state of the canvas — not the original prompt — so refinements compound naturally the way they would with a human architect at a whiteboard. The conversation auto-saves to history, so you can step back through the evolution of a design or branch from an earlier point.

Figure 1. Architecture Chat treats the diagram as a living document. Each message refines the current canvas — adding services, changing SKUs, or reorganizing groups — and the full exchange is saved to history.

The shift is subtle but important: architecture design stops being a one-shot prompt and becomes an iterative dialogue.

---

The whiteboard deliverable: Blueprint Diagrams (BETA)

Formal topology diagrams with official Azure icons are perfect for documentation and stakeholder decks. But early-stage design conversations often want something looser — the hand-drawn feel of a whiteboard sketch that communicates intent without implying finality.

Blueprint Diagrams generate exactly that: a whiteboard-style render with nested zones (subscription → VNet → subnet), numbered flow arrows, and a deliberately sketchy aesthetic. You choose the output mode:

• Topology — the formal, icon-based diagram from the launch post
• Blueprint — the hand-drawn whiteboard style
• Both — generate the two side by side

Figure 2. The same architecture in two visual languages. Left: the formal, icon-based topology. Right: Blueprint mode — a whiteboard-style render with nested zones and numbered flow steps, plus a numbered legend explaining each hop. Use Blueprint for early design conversations and Topology for final documentation.

It’s the same underlying architecture — two visual languages for two different moments in the design lifecycle.

---

A fleet of 13 models: pick the right brain per task

The launch post shipped with multi-model support. That fleet has grown to 13 models across five providers, so you can match the model to the job — fast models for iteration, reasoning models for complex designs, code-optimized models for Bicep generation:

• OpenAI GPT-5.x — GPT-5.1, GPT-5.2, GPT-5.2 Codex, GPT-5.3 Codex, GPT-5.4, GPT-5.4 Mini
• DeepSeek — V3.2 Speciale, V4 Pro
• xAI Grok — 4.1 Fast, 4.3
• Mistral — Large 3
• MoonshotAI Kimi — K2.5, K2.7 Code

The Compare Models feature runs the same prompt through any subset of these in parallel and ranks them on service count, token usage, latency, and cost — with Fastest / Cheapest / Most Thorough badges — so you can make an evidence-based choice rather than a guess.

Figure 3. Multi-model comparison across the full 13-model fleet. Top: the results grid ranks every model on service count, connections, token usage, latency, and cost, with Fastest / Cheapest / Most Thorough badges. Bottom: an optional AI Critique uses a critic model to rank the outputs and explain each model’s strengths and gaps.

Adding a model is now a small, well-understood change — a testament to how the multi-provider abstraction has matured since May.

---

The headline: the Diagram Builder is now an MCP server

Here’s the change that reframes the project. Everything above is about a person using a web app. But the same capabilities — generating a diagram, validating it against WAF, estimating its cost, producing Bicep — are exactly the things an AI agent needs when it reasons about Azure architecture.

So we exposed them. The Azure Architecture Diagram Builder now runs as a Model Context Protocol (MCP) server. Any MCP-capable agent can call its tools with typed inputs and structured outputs:

This means an agent can hold a conversation like “design a HIPAA-compliant platform, check it against the Well-Architected Framework, tell me the monthly cost in West Europe, and give me the Bicep” — and the Diagram Builder answers each part programmatically, returning structured data the agent can reason over and chain.

Figure 4. The Diagram Builder as an MCP server inside Microsoft Scout. Top: from a natural-language request, the agent calls the render_diagram tool with structured parameters (title, format, direction, theme, region) and saves the returned SVG to its workspace. Bottom: the rendered architecture — grouped zones, labeled flows, and cost badges — appears inline in the conversation, generated entirely through agent tool calls.

The tool that started as a canvas for humans is now also a building block for agents. That’s the arc: from an app you click, to a partner you chat with, to a tool other agents call.

---

Grounded in Microsoft Learn, and sharper output

Two smaller-but-meaningful improvements round out the release:

• Microsoft Learn grounding. Deployment guides now search official Microsoft Learn documentation at generation time and cite it, so the guidance reflects current, authoritative practice rather than a model’s training snapshot.
• Output enhancements (July 2026). Rendered diagrams now carry per-service cost badges, support light and dark render themes, and include metadata panels that summarize the architecture — service counts, regions, and estimated cost — directly on the image.

---

Highlights

Since the May launch, the Azure Architecture Diagram Builder has grown from a design tool into an agent-ready platform:

• Conversational design: iterate on a diagram by chatting over the live canvas, with full history
• Two visual languages: formal topology and hand-drawn Blueprint, from the same architecture
• 13 models, five providers: choose the right brain per task, with evidence-based comparison
• Agent-ready: an MCP server exposing generation, validation, costing, and IaC as callable tools
• Grounded guidance: deployment guides cite live Microsoft Learn documentation
• Still open source: every capability above is available to inspect, extend, and contribute to

Try It Today

• Live demo: https://aka.ms/diagram-builder
• Source code: GitHub repository
• Documentation: See the Getting Started Guide for setup, and the repository’s MCP server directory for agent integration.

If you read the first post and tried the tool — thank you. The features above exist because you told me what you needed. Keep the feedback coming via GitHub Issues.

---

Tags: artificial intelligence · application · apps & devops · well architected · infrastructure

Keeping the UI thread free is always the best option. Unfortunately, there are situations where this is not entirely possible. Here’s a small progress spinner which keeps animating when the UI thread is busy.

This new alpha build has a quality of life improvement for the Move tools, support for CICP metadata, and good quality HDR->SDR tone mapping when opening HDR images with supported file types (including plugins).

You can read more about the CICP and HDR tone mapping support at https://x.com/rickbrewPDN/status/2072357433390047252 or https://bsky.app/profile/rickbrew.bsky.social/post/3mplx7ujotk2a

You can read more about 5.2 and what it includes by reading the release notes for the first alpha.

Change Log

Changes since 5.2 Alpha (build 9650):

• Changed: The Move Selection and Move Selected Pixels tools will now behave more intuitively when using constrained resizing (when holding shift). The aspect ratio that was used for a constrained resize used to be “locked in” when the selection was first drawn. The aspect ratio is now picked up when you start a constrained resize, and remembered until a non-constrained resize is performed.
• Added CICP metadata and color management support to the imaging framework 
  • See the CicpColorSpace struct in the PaintDotNet.Imaging namespace.
  • It has a CanColorTransformFrom property, indicating that it can be used as the source color space for the IImagingFactory.CreateColorTransformedBitmap or IBitmapSource.CreateColorTransformer extension methods.
  • It also has a CanCreateColorContext property that indicates when it is possible to create an IColorContext directly (ICC profiles can’t be generated for all CICP combinations) with the IImagingFactory.CreateColorContext(CicpColorSpace) extension method.
  • These can then be used by a FileType to provide a compatible image (“document”). Paint.NET’s color management is based on ICC color profiles, and some CICP color spaces (those involving PQ or HLG) cannot be expressed as an ICC color profile. Those images can, however, be transformed to an ICC-compatible color space with the aforementioned extension methods.
• Added HDR support to the new FileType plugin system
  • An image is tagged as HDR at load time via the IFileTypeDocument.Metadata.Hdr metadata section. Set IsHdrDocument to true, and optionally specify luminance data. The pixel format must be floating point (PixelFormats.Rgba64Half or PixelFormats.Rgba128Float), and the color context must be linearized.
  • Paint.NET does not yet support HDR editing, so it will convert the image to SDR with appropriate, high quality tone mapping.
• Added CICP support for AVIF, JPEG XL, and PNG.
• Added HDR tone mapping support for AVIF, HEIC, JPEG XL, JPEG XR, and PNG. If the image file being opened is HDR then it will be converted to SDR in an appropriate manner. Eventually Paint.NET will support HDR editing, this conversion process will go away, and the FileType plugins won’t even need to be updated.
• Added Rgb64, Rgb64Half, and Rgb128Float pixel formats for the imaging framework.
• Added a /disableCompositionSwapChain command-line parameter. This disables the use of Windows.UI.Composition, and should enable easier progress on the WINE effort.
• Fixed: When right-clicking on an image tab at the top, and then clicking on Open Containing Folder, two Explorer windows were being opened.
• Added a note in the installer about the new website address (https://www.paint.net). You can read more about it here: https://x.com/rickbrewPDN/status/2060397901650825238 or https://bsky.app/profile/rickbrew.bsky.social/post/3mmz73u6lzs2t

Download and Install

This build is available via the built-in updater as long as you have opted-in to pre-release updates. From within Settings -> Updates, enable “Also check for pre-release (beta) versions of paint.net” and then click on the Check Now button. You can also use the links below to download an offline installer or portable ZIP.

You can also download the installer here (for any supported CPU and OS), which is also where you can find downloads for offline installers, portable ZIPs, and deployable MSIs.

Hello Folks!

Welcome Back to AZ Update

A few years ago, Antony Bartolo and I launched a simple idea called AZ Update.

The goal was to provide a place where IT professionals could quickly understand what was changing in Azure, why it mattered, and what they should pay attention to next. The show became a weekly conversation focused on Azure news, infrastructure, operations, security, and the real-world impact of Microsoft's latest cloud updates.

Today, Azure is moving faster than ever.

Every week brings new services, platform capabilities, operational improvements, AI innovations, and architectural guidance. Keeping up is a full-time job. Most of us don't have time to read every blog post, release note, announcement, and documentation update.

That's why I'm bringing AZ Update back.

This time, as a weekly LinkedIn newsletter and this blog.  To be completely transparent I am using an AI Agent to parse the update list for any in the last 7 days, filter for Infra/Ops content and research product docs and help with the draft. I do review content and write the post myself.

Each edition will cut through the noise and focus on what matters most for cloud architects, platform engineers, infrastructure teams, SREs, security professionals, and IT operators. I'll share the Azure announcements worth your attention, explain why they're important, highlight practical implications, and point you to the resources that can help you go deeper.

Just a concise weekly briefing from one ITPro to another.

If your day-to-day involves building, operating, securing, or modernizing infrastructure in Azure, Azure Arc, AKS, hybrid environments, or the growing world of AI-powered operations, this newsletter is for you.

Welcome to the next chapter of AZ Update.

 

Here is week 1!

This week’s Azure infrastructure updates bring practical operational gains for security, platform reliability, disaster recovery, and identity-driven access control. Here is a detailed ITPro breakdown with implementation guidance you can use in production planning.

• Update #1 - Generally Available: Network Security Perimeter support for Azure Event Hubs
• Update #2 - Generally Available: Confidential Computing support for Azure Event Hubs Dedicated
• Update #3 - Generally Available: Support 5x churn in Azure Site Recovery
• Update #4 - Generally Available: Microsoft Entra ID-based access for Azure Blob Storage SFTP

Update #1 - Generally Available: Network Security Perimeter support for Azure Event Hubs

Why ITPros should care

Network Security Perimeter for Event Hubs changes how ITPros enforce connectivity boundaries around mission-critical event pipelines. Instead of depending only on isolated firewall rules per namespace, you can apply perimeter-aware controls that are easier to govern consistently across multiple services.

From an operations perspective, this is a service-level hardening improvement. It helps reduce accidental exposure and supports better audit conversations when security teams ask for clear evidence of allowed and denied paths.

Operational value

The operational value is stronger day-two control. You can standardise network access policy patterns for producer and consumer applications, reduce policy drift, and simplify incident investigations when unexpected traffic appears.

For production rollout, validate all dependencies first: private endpoints, DNS resolution, trusted service exceptions, managed identities, and cross-subscription network paths.

Real-world example with step-by-step guidance

1. Inventory current producer and consumer traffic flows, including private endpoints, DNS zones, and any trusted service allowances.
2. Deploy a pilot Event Hubs namespace with perimeter controls in non-production and mirror realistic ingestion and consumption traffic.
3. Apply least-privilege inbound and outbound perimeter rules, then execute end-to-end send/receive tests with representative message volume.
4. Review diagnostic logs for denies, refine exceptions only where business-justified, and capture evidence for change management.
5. Promote to production in stages with a rollback plan that restores previous network policy if message flow health degrades.

Technical details including code examples

Use the following sequence when validating that perimeter onboarding did not break data plane operations. The first command confirms your active Azure context, the second verifies endpoint reachability, and the third validates Event Hub metadata retrieval.

Run this safely in a test window before production enforcement. If connectivity and control-plane checks pass in test, repeat with production namespace read-only checks before enabling stricter policies.

az account show --output table Test-NetConnection <namespace>.servicebus.windows.net -Port 5671 az eventhubs eventhub show --resource-group <rg> --namespace-name <namespace> --name <eventhub> --output table

Expected outcome: TCP probe to port 5671 succeeds, and Event Hub metadata query returns without auth or network timeout errors. If probe fails, check DNS, NSGs, route tables, private endpoint linkage, and perimeter rule assignment scope.

Comprehensive Resources

• Azure update: Network Security Perimeter support for Azure Event Hubs
• Network Security Perimeter concepts
• Azure Event Hubs documentation
• Event Hubs networking and security

•  

Update #2 - Generally Available: Confidential Computing support for Azure Event Hubs Dedicated

Why ITPros should care

Confidential Computing support for Event Hubs Dedicated matters when ITPros operate regulated or high-sensitivity event streams. It extends protection expectations beyond encryption at rest and in transit, into stronger assurances during processing.

Compared with older architectures, this reduces the need for some compensating controls and helps security and operations teams align on platform-native protections for streaming workloads.

Operational value

Operationally, this strengthens trust boundaries for event ingestion platforms that feed analytics, SIEM, and business-critical automation. It also improves evidence posture for compliance reviews where data handling controls must be demonstrated end to end.

Before rollout, validate throughput impact, partition behaviour, client compatibility, and observability baselines so confidentiality controls do not create unexpected SLO regressions.

Real-world example with step-by-step guidance

1. Classify Event Hubs namespaces by sensitivity and select the first dedicated environment where enhanced confidentiality requirements apply.
2. Enable and validate in non-production with representative producer and consumer load, including peak and burst patterns.
3. Measure latency, throughput, and throttling trends before and after enablement to confirm workload behaviour remains acceptable.
4. Capture attestation and configuration evidence required by internal security governance or external auditors.
5. Roll out in waves by workload criticality, with rollback criteria tied to message latency, error rates, and throttling thresholds.

Technical details including code examples

This validation example confirms namespace details and metrics health so you can compare baseline vs post-change behaviour. The metrics query focuses on ingestion, egress, and throttling signals that commonly surface operational risk first.

Run with a least-privileged operations identity that can read namespace configuration and metrics. Avoid making unrelated changes while collecting baseline evidence.

az eventhubs namespace show --resource-group <rg> --name <namespace> --output jsonc az monitor metrics list --resource /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.EventHub/namespaces/<namespace> --metric IncomingMessages OutgoingMessages ThrottledRequests --interval PT5M az account show --query user.name -o tsv

Expected outcome: namespace query succeeds, metrics return consistently, and no abnormal throttling spike appears after control changes. If results diverge, review dedicated capacity planning, partition strategy, RBAC scope, and workload profile fidelity.

Comprehensive Resources

• Azure update: Confidential Computing support for Azure Event Hubs Dedicated
• Event Hubs Dedicated overview
• Azure Confidential Computing overview
• Monitor Azure Event Hubs

•  

Update #3 - Generally Available: Support 5x churn in Azure Site Recovery

Why ITPros should care

Higher churn support in Azure Site Recovery is directly relevant for ITPros protecting write-intensive systems. It expands what can be replicated reliably, reducing DR exceptions for fast-changing workloads.

Compared with the previous operational envelope, this gives more room for modern transactional applications while still requiring disciplined capacity and replication health management.

Operational value

Operational value is improved DR coverage and better alignment between production write behaviour and recovery plans. Teams can protect more workloads without bespoke workaround architecture.

For production rollout, validate process server sizing, bandwidth headroom, cache storage performance, and sustained replication lag during peak change windows.

Real-world example with step-by-step guidance

1. Baseline current churn and replication lag for candidate workloads to identify which systems benefit most from the increased support.
2. Enable replication in a pilot for one high-churn workload and observe initial seeding and steady-state health.
3. Run test failover and reprotect to verify recovery objectives and operational runbook completeness.
4. Tune bandwidth and cache settings if lag increases during peak write intervals or backup overlap windows.
5. Onboard additional workloads incrementally and use replication health gates before each expansion wave.

Technical details including code examples

These commands are relevant for validating actual recovery readiness instead of configuration-only status. They expose protected item health and support controlled failover rehearsal.

Use a non-production network for test failover and document outputs so operations and business continuity stakeholders share the same readiness evidence.

az site-recovery fabric list --resource-group <rg> --vault-name <vault> -o table az site-recovery protected-item list --resource-group <rg> --vault-name <vault> --fabric-name <fabric> --protection-container <container> -o table az site-recovery recovery-plan test-failover --resource-group <rg> --vault-name <vault> --name <recoveryPlan> --network-id <testNetworkId>

Expected outcome: protected items remain healthy, lag remains within target, and test failover completes without consistency errors. If failures occur, inspect connectivity, process server capacity, cache throughput, and policy mappings.

Comprehensive Resources

• Azure update: Support 5x churn in Azure Site Recovery
• Azure Site Recovery documentation
• Monitor and troubleshoot Site Recovery
• Site Recovery capacity planning

•  

Update #4 - Generally Available: Microsoft Entra ID-based access for Azure Blob Storage SFTP

Why ITPros should care

This launch modernises SFTP access for Azure Blob Storage by bringing identity control closer to Microsoft Entra. ITPros gain stronger governance options than local-account-only models for many enterprise scenarios.

Operationally, the key change is identity lifecycle alignment: provisioning, review, and revocation can be managed with central identity processes instead of fragmented local credentials.

Operational value

The value is reduced credential sprawl, better auditability, and clearer access accountability across teams and external partners exchanging files over SFTP.

Before production, validate client compatibility, RBAC scope, network restrictions, access review cadence, and emergency break-glass procedures.

Real-world example with step-by-step guidance

1. Confirm SFTP is enabled on the storage account and validate networking model (public endpoint restrictions or private access path) matches policy.
2. Assign Entra-based permissions with least privilege and validate scope at storage account and container boundaries.
3. Test SFTP authentication and file operations using approved clients while collecting diagnostic logs for audit evidence.
4. Validate joiner-mover-leaver scenarios by changing membership and role assignments, then confirming access updates propagate correctly.
5. Roll out in stages by partner or workload segment with clear support ownership and incident response runbooks.

Technical details including code examples

This sequence verifies account capability and role assignment posture before user acceptance testing. It is useful for catching scope mistakes that often cause authentication-success/data-access-failure patterns.

Run safely by using a dedicated test identity and non-production storage account first; then repeat read-only validation in production before broad enablement.

az storage account show --name <storageAccount> --resource-group <rg> --query "{name:name,isSftpEnabled:isSftpEnabled,allowBlobPublicAccess:allowBlobPublicAccess}" -o jsonc az role assignment list --assignee <principalObjectId> --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<storageAccount> -o table az account show --query user.name -o tsv

Expected outcome: SFTP capability is enabled, expected role assignments are present, and test identity can perform allowed operations only. If sign-in works but file actions fail, inspect RBAC propagation delay, ACL/permission scope, and storage network restrictions.

Comprehensive Resources

• Azure update: Microsoft Entra ID-based access for Azure Blob Storage SFTP
• SFTP support for Azure Blob Storage
• Authorize blob data with Microsoft Entra ID
• Azure Storage security baseline

If you are planning adoption, start with one workload per update area, collect operational evidence, and standardise the validated pattern in your runbooks and IaC modules. That approach keeps change safe while accelerating delivery.

Cheers!

Pierre

Summary

In this episode, Andy sits down with Attia Qureshi, a coach and negotiation expert who is co-author, with John Richardson, of Never Settle. There's no shortage of great negotiation advice out there, yet in real conversations with real stakes and real emotions, that advice often fails to turn into action. This book tackles that gap between insight and habit.

Attia shares why emotions are not a distraction from negotiation but central to it, why getting clear about what you actually want is harder than it sounds, and how we leave value on the table without realizing it. You'll hear practical stories, from resetting a difficult relationship with a glass of lemonade to expanding the pie in a salary negotiation, plus small daily exercises for building resilience to rejection and learning to say no in a way that strengthens relationships rather than damaging them.

If you're looking for practical, doable ways to become a more confident negotiator and influencer, this episode is for you!

Sound Bites

• "You can get more by caring about what the other person needs and building a strong relational foundation."
• "People are not born amazing negotiators. They develop that skill over time, just like people are not born confident."
• "You have to practice that small step out in the real world where the stakes are low and build that skill day after day, month after month."
• "You and I have probably already negotiated half a dozen times today."
• "When someone gives us something, we want to return the favor."
• "New studies now show that 90 to 95% of decision-making comes from unconscious emotional processing."
• "So many of us quit before we even start."
• "But if we do have a goal and we do prepare for the conversation, our likelihood of success is double."
• "A good negotiation doesn't always mean getting 'yes' at the end of it."
• "I always tell my students, people can almost always help you. It depends on if they want to or not."

Chapters

• 00:00 Introduction
• 02:06 Start of Interview
• 02:17 Growing Up: Early Lessons in Conflict
• 07:10 Negotiation and Confidence Are Skills, Not Personality
• 08:04 Life Is Full of Everyday Negotiations
• 10:30 Why Negotiation Training Often Fails
• 12:30 Resetting a Difficult Relationship
• 17:20 Influence vs. Manipulation
• 22:33 Emotions, Fear, and Building Resilience
• 28:00 Using the Emotion Wheel
• 29:36 Getting Clear on What You Really Want
• 33:39 Expanding the Pie: Creating Value
• 40:50 The Power of Saying No
• 47:27 Teaching Kids to Negotiate
• 51:23 End of Interview
• 51:55 Andy Comments After the Interview
• 55:22 Outtakes

Learn More

You can learn more about Attia and her work at AttiaQureshi.com.

For more learning on this topic, check out:

• Episode 157 with Dr. Robert Cialdini. Known as the godfather of influence, his name came up several times during today's discussion, making this a great follow-up.
• Episode 412 with Scott Walker. A former Scotland Yard hostage negotiator who shares a lot of practical lessons about influence.
• Episode 385 with Vanessa Patrick. She wrote one of the best books on how to say no, a fitting companion to today's conversation.

Chat with PMeLa

You can chat directly with PMeLa—the podcast's AI persona—to get episode recommendations and answers to your project management and leadership questions. Visit PeopleAndProjectsPodcast.com/PMeLa to chat with her.

Join Us for LEAD52

I know you want to be a more confident leader–that's why you listen to this podcast. LEAD52 is a global community of people like you who are committed to transforming their ability to lead and deliver. It's 52 weeks of leadership learning, delivered right to your inbox, taking less than 5 minutes a week. And it's all for free. Learn more and sign up at GetLEAD52.com. Thanks!

Thank you for joining me for this episode of The People and Projects Podcast!

Talent Triangle: Power Skills

Topics: Negotiation, Influence, Leadership, Project Management, Reciprocity, Emotional Intelligence, Resilience, Saying No, Stakeholder Management, Relationship Building, Value Creation, Confidence

The following music was used for this episode:

Music: Quantum Sparks (Full Version) by MusicLFiles
License (CC BY 4.0): https://filmmusic.io/standard-license

Music: Tropical Vibe by WinnieTheMoog
License (CC BY 4.0): https://filmmusic.io/standard-license

Download audio: https://traffic.libsyn.com/secure/peopleandprojectspodcast/514-AttiaQureshi.mp3?dest-id=107017

I killed a SaaS product a few years ago. Not because the idea was wrong, and not because the market wasn’t there. Because the platform underneath it changed ownership, repriced its API overnight, and what had been a viable foundation rapidly became an unworkable cost centre.

I’ve been watching the AI space closely ever since.   I’m seeing the same structural pattern forming -just with larger numbers, more VC money, and bigger stakes.

This post isn’t about what I lost. It’s about what I think is coming for a lot of people building on LLM APIs right now, and what you can do about it before it happens to you.

Some Background, How I Know What a Rug Pull Feels Like

In 2013 I started building a product called Social Opinion. The idea was to use NLP and sentiment analysis to mine social data for real-time signals of commercial intent, then enable marketers to act on those signals with targeted advertising.

Right message, right person, at the right time.

It worked well enough that the platform I’d built on top of invited me to their HQ’s in San Francisco and New York.

They gave me access to internal alpha APIs. They told me in writing that they were “invested in this partnership” and intended to “move forward at full speed.”

A few years later, under new ownership, they killed free API access with almost no notice. The product I’d built entirely on top of that access was no longer viable. I shut it down.

I’m not telling that story for sympathy. I’m telling it because the dynamics that played out are almost identical to what’s happening in AI tooling right now, and most people building in this space haven’t lived through the other side of it yet.

~

What’s Happening in AI Right Now

Many products are being built on top of Open AI, Anthropic, Google, and other LLM providers. The access is cheap. In some cases it’s nearly free, backed by organisations willing to absorb losses while pursuing long-term strategic goals.

That’s a deliberate strategy. Get builders dependent on your infrastructure. Get end users habituated to the experience. Then, once the ecosystem is locked in, figure out the economics.

None of that is secret. The providers aren’t hiding it. But there’s a gap between knowing something abstractly and actually pricing it into your product decisions, and right now, a lot of teams are building as if today’s API costs are a permanent feature of the landscape rather than a temporary one.

~

The Specific Risks Worth Naming

Some risks to consider and worth noting:

• Pricing isn’t static. Today’s API costs reflect a market that’s still expanding rapidly, with providers prioritising growth, adoption, and market share alongside profitability. As those priorities evolve, pricing will too. If your product’s unit economics only work at today’s rates, you’re relying on an assumption you don’t control. Know where your break-even point is before someone else decides it for you.
• Ownership and strategy changes. I know what it looks like when a platform changes hands and the new owners have different priorities. Models get acquired. Labs get bought. Priorities shift. The relationship you have with a platform today is only as stable as that platform’s ownership and incentive structure  -neither of which you control.
• Model deprecation. The specific model your product is tuned around may not exist in two years. Providers are moving fast, retiring older versions, and the prompt engineering, fine-tuning, or integration work you’ve done against a specific version doesn’t automatically transfer. This isn’t hypothetical -it’s already happening.

 

What you’re allowed to build on top of a given API can change. Use cases that are permitted today may be restricted tomorrow. Output you’re allowed to store, repurpose, or sell downstream is subject to terms that can be updated with relatively little notice.

~

This Isn’t an Argument Against Building

It would be easy to read this as “don’t build on LLM APIs.” That’s not what I’m saying. The capabilities available right now are remarkable, and the right time to build with them is while the access is good and the cost is manageable.   I am building with these tools too.

The argument is about how you build. Specifically, about whether you’re designing for the risk that already exists, or pretending it doesn’t.

~

What I’d Do Differently

Having been burned before, here are some things to approach differently:

• Abstract the model layer from day one. Your application logic should not be tightly coupled to a specific provider or model. If switching from OpenAI to Anthropic to an open-source alternative requires a significant rewrite, you’ve already lost flexibility you’ll eventually need.
• Model your unit economics at 10x current API cost. If the product stops working at ten times today’s inference price, that’s a risk you’re carrying. Know where the break-even is. Have a plan for what you do when — not if — costs move.
• Watch where the VC money actually is. The providers keeping prices low are doing so with someone else’s capital. Track the funding cycles, the runway signals, the revenue disclosures. When the subsidised period ends, it tends to end fast.
• Don’t mistake a good relationship for a contractual one. A dedicated support contact, early access to new models, enthusiastic partnership emails — these are signs of goodwill, not protection. Goodwill is not transferable when ownership changes.
• Keep an eye on open-source alternatives. The gap between frontier closed models and capable open-source alternatives is narrowing. Building with an awareness of what you could run yourself — if you had to — changes the risk calculation significantly.

 

Make sure something survives the product. This might be skills, architecture patterns, domain knowledge, or customer relationships.  The things that compound regardless of what happens to any specific product or API.

~

Transparency

I didn’t fully apply these rules when I was building Social Opinion. I knew platform risk was a concept. I didn’t treat it as an active design constraint. The relationship with the platform felt strong enough that I underweighted what would happen if it changed.

What did I get out of it?

The NLP work, the real-time architecture, the understanding of intent detection at scale, the experience of presenting a product at a global competition -none of that went away when the product did. That part I did right, even if accidentally.

But I’d have built the product differently if I’d genuinely designed for the risk from the start. If I were starting something today on top of LLM credits that exist because a hyperscaler is buying market share, I’d be asking harder questions about what the product looks like when those credits cost ten times as much.

Whether it happens in two years or ten is impossible to know. The point is that platform incentives eventually change.

But platforms eventually optimise for their own economics, not yours.

If you’re building on someone else’s infrastructure, design as though that day will come.

~