AI development, Build or Buy

Pay for SaaS, or Build It Yourself with AI?

Build selectively, keep what adds value, and cancel more than you think.  AI coding tools have changed the maths of software. A CRM, a booking page or an approvals workflow that once took a contractor weeks can now be scaffolded in an afternoon. It is tempting to look at your monthly licensing bills, count the subscriptions, and replace them all.  I think that is mostly the wrong move. Not because AI can't build the software, but because building was never the expensive part.

Building is cheap. Owning isn't.

When you replace a SaaS tool, you are not just replacing the app. You are replacing everything the vendor quietly does around it:

• Security and patching. Every homegrown tool is another attack surface, and you are now accountable for it.
• Uptime, backups and restores. When it breaks at 2am, you are the support desk.
• Regulatory change. Tax rules, GDPR, payroll and e-invoicing requirements move constantly. A good vendor shares that burden and absorbs it for you.
• Integrations. The APIs your tool depends on will change, and your glue code will break.
• Your attention. This is the big one. Every hour you spend maintaining an internal CRM is an hour you're not spending on your role.

Run the numbers honestly. A £30-a-month tool costs £360 a year. If owning your replacement takes more than a few hours a year at your day rate, you have lost money, even if the first version took an AI agent an afternoon.  When you multiply by thousands or tens of thousands, the answer looks straightforward, but if this system goes down or data is breached, the true cost can be extreme.

Five questions before you build

Before you cancel a subscription or set of licences and open your AI coding tool, run it through these five questions. If the answers point more often to "buy" than "build", keep paying.

1. Who sets the rules?

If the rules come from HMRC, the card schemes, a regulator or a standards body, buy it unless it gives you a competitive advantage. Accounting, payroll, payments, e-signature and tax filing all fall here. You don't pay for the screens. You pay for someone else to track every rule change and carry the risk if they get it wrong.

2. Is it cheap and working?

Keep it. A tool that costs a few pounds a month and does its job without fuss is the worst possible candidate for a rebuild. The saving is tiny, and you swap a solved problem for a new one you have to maintain.

3. Is it priced per seat?

This is where building starts to make sense. Per-seat pricing grows with every hire, contractor and partner you add. A simple tracker or approvals tool that costs £9 a user a month looks very different at 4,000 users than at 4. If the tool is essentially a few forms, a list, and a workflow, you can pay it back quickly.

4. Does it set you apart?

If the tool encodes how you do things differently from competitors, it is worth owning. Your pricing logic, onboarding flow, or lead-scoring process is part of your edge. Renting them means renting your differentiation, and shaping your process around someone else's product.

5. Who looks after it?

If the honest answer is "nobody", don't build yet. Every piece of software needs an owner: someone who patches it, answers questions and fixes it when an API changes. No owner means the tool slowly rots until it fails at the worst moment. Name the person first, then build.

A practical playbook

1. Audit first. List every subscription + licence. Look for easy wins first.
2. Consolidate onto what you already license. If you pay for Microsoft 365 or Google Workspace, check what is already included. Forms, bookings, lists, task planners and simple low-code apps quietly replace a surprising number of small tools.  Find out whether your employees are using rogue tools; then normalise them.
3. Build only the few that pass the test. Pick the two or three tools where per-seat pricing hurts, the logic is simple, an outage would be an inconvenience rather than a crisis, and you have named an owner.
4. Watch for product signals. If a tool you build solves a pain your peers keep describing too, it may be a product rather than an internal tool.

Summary

AI has made software almost free to build. It has not made software cheap to own. So before you build, ask the five questions. 

1. Who sets the rules? 
2. Is it cheap and working? 
3. Is it priced per seat? 
4. Does it set you apart? 
5. Who looks after it?

Mendix Testing Inside VS Code

 MendixWright: Mendix Testing Inside VS Code

MendixWright is a VS Code extension that lets Mendix teams check every environment and run Playwright regression tests without leaving the editor. Version 1.2.3 is out now, and this post walks through what it does, with annotated demo screenshots.

The problem

On most Mendix projects I work on, a simple question like "Is Acceptance up, and do the regression tests still pass?" can mean four tools. You open the Mendix Portal for environment status, a browser to sign in, a terminal for Playwright, and a spreadsheet to tie results back to requirements.

Each switch costs a few minutes and some context. Across a team running daily regression, that adds up fast. MendixWright brings it all into one VS Code panel.

What MendixWright is

MendixWright is the Mendix Testing Plugin for VS Code, published by KaizenFix. Search "Mendix" in the Extensions Marketplace, install it, and a Mendix Testing icon appears in the activity bar.

On first start, it checks for the Chromium build that its bundled Playwright uses, and for @playwright/test each Playwright project in your workspace. If anything is missing, it offers to install it for you.

Local Mendix servers

Open the panel and any Mendix app running on your machine is already listed. In the demo it picks up an app on port 8080 running Mendix 11.11.0, with no configuration.

For each local app, you get the URL, Mendix version, admin API port, response time, Java process ID, and bind address. That's everything you'd otherwise dig out of Studio Pro or Task Manager before pointing a test run at it.

Every Mendix Cloud environment in one tree

Below the local servers sits Mendix Cloud Environments: every licensed app you can see, each with its Production and Acceptance environments. A green dot means the environment is up, and each row shows its URL, response time and Mendix version.

Expand an environment, and you get two checks. Health is the platform status. Home page health checks that the app's home page is authenticating and working, so it catches an app that's "running" but serving errors.

App details holds the metadata you usually need from the Portal: App ID, technical contact, region, subdomain, licence, and whether the project is checked out on this machine. It also clearly tells you when your API key doesn't have permission to see an app's environments.

From health check to test run in one click

Click the link icon on any environment, and you get four actions: open it in a new browser window, copy the URL, run Playwright tests against this URL, or authenticate and save the session.

The last two are where the time savings are. Run Playwright Tests points your existing suite at that environment, so the same tests run against local, Acceptance or Production without editing config. Authenticate and Save Session signs you in to the Mendix app once and stores the session, so later runs skip the login step.

Beyond testing: requirements and reporting

Two more features close the loop between what the app should do and what the tests prove.

• Documentation. MendixWright reads your app's model and generates a business requirements document (BRD): overview, user stories and acceptance criteria. Requirement IDs stay the same when you regenerate, so tests can reference them and stay valid as the app changes.
• MendixFix Insights. Playwright runs, and BRDs are published to a shared dashboard, broken down by requirement, test runner and persona. Product owners and testers see coverage and results without opening VS Code.

Why use it

• One place. Environment health, sign-in and regression runs all live in the editor where you already write tests.
• Zero discovery work. Local apps and every licensed cloud environment appear without configuration.
• Catch real outages. Home-page checks spot an app that's up but broken, not just a container that's running.
• Same suite, any environment. Point your Playwright tests at local, Acceptance or Production from a menu.
• Traceable quality. Stable requirement IDs and a shared Insights dashboard give stakeholders evidence, not just a green tick.

Mendix VSIX for IDEs to do AI regression E2E testing

MendixWright is a free VS Code plug-in; please ask, and I'll email you a copy.

• Documentation that matches the app, generated from the model rather than written by hand afterwards.
• Regression coverage from day one, without hand-scripting each test.
• Traceability from requirements to acceptance criteria to tests.
• Built for Mendix developers, working in VS Code beside Studio Pro.

https://youtu.be/Z4r3jKSCyRY

OWASP API Risks Updated - BOLA

As AI use and sophistication grow, BOLA attacks have risen rapidly.  Broken Object Level Authorisation (BOLA) is when an authenticated user can switch parameters like the URL in an API request and access other users' data. For example, GET https://api.example.com?client=32 returns the authenticated user's information, such as your age or other PII.

The authenticated user changes the client to "33"; I now get someone else's records, as the API only checks that I am an authenticated user, not that I am authorised to check another client.

Action	URL	Result
GET	https://api.example.com?client=32	The user sends valid authentication for their own client.  The result returns their data.  Correct.
GET	https://api.example.com?client=33	The user sends valid authentication for their own client data but requests another client's info.  The result returns the other client's private data.  Incorrect behaviour.  Major security issue.

Tools like Wiz and StackHawk will pick up BOLA API weaknesses.

Using StackHawk for DAST and API Security Testing on Azure

I recently started using StackHawk, and I am impressed with the tooling.  Its DAST and API security testing are outstanding, and it integrates beautifully with VS Code.

Application security requires more than simple source code scanning. While SAST, SCA, and secrets scanning are great in CI pipelines, key vulnerabilities remain hidden until an application is running. This is where Dynamic Application Security Testing (DAST) becomes essential.

In my development environment, Claude and GitHub Copilot are building my code and do so much of the Static Application Security Testing (SAST) 7I don't feel compelled to use them in the IDE.  Claude does a great job; it can do SAST and implement security best practices extremely well.

Software Composition Analysis (SCA) focuses on the third-party and open-source components our code relies on.  Claude once again does a great job of identifying vulnerabilities and upgrading to the latest versions.

Security secrets: Claude once again does a great job, especially with remote repo integrations such as GitHub, ADO, and GitLab.

Conclusion:

For enterprises building Azure-hosted web applications and APIs, StackHawk offers a developer-focused DAST approach that integrates directly into modern DevSecOps workflows. Unlike traditional DAST tools, which security teams often operate, StackHawk is designed to work with developers, providing rapid feedback during testing and deployment.  This "shift left" saves time and money. There are various DAST options, but StackHawk has become my favourite.  With the rise of AI coding, developer-level DAST is more important than ever.

BURP has been the standard for pen testing for many years.   Three DAST tools focus on different things: Burp Scanner, OWASP ZAP, and StackHawk.
Wiz API is a great test tool for API Security: runtime security, covering much of the same area as StackHawk for API security, but its key differentiator is runtime threat detection.

Native Mobile App Development Notes

Overview: Many approaches exist for building and deploying native apps to the App Store (Apple) and Play Store (Android).  This post shows an approach that works well for converting a React web app into a Play Store app using the Expo toolchain.  The choice remaining is whether to use a wrapper or port the code to native UI. 

EXPO, as a company, has two independent products that work together nicely for mobile apps.

At one of my businesses, we are using the approach below successfully to deploy the core SaaS app onto the stores:

Using Expo products to build and deploy native Apps onto the two main public stores using a wrapper or native approach) 

An Introduction to Microsoft Azure SRE Agent

Managing cloud environments often involves jumping between alerts, logs, dashboards, and code repositories when something breaks.  Azure SRE Agent aims to simplify operational troubleshooting.  The tool:

1. Investigate incidents
2. Automates routine workflows
3. Helps resolve issues faster

What is the Azure SRE Agent?

The SRE Agent combines 1) Brain - Large Language Models (LLMs, either OpenAI or Anthropic models) with 2) Azure-specific product knowledge - tools and knowledge, and 3) Instructions - custom configuration.  Allowing it to reason over operation support data.

The agent is deployed directly inside an Azure Resource Group, which sits within an Azure Subscription.  I have only used the Reader Scope for my assigned identity permissions; it can operate in Reader Scope (for inspection and telemetry analysis) or Privileged Scope (to execute changes and automated mitigations).

The Azure SRE Agent operates across three main operational patterns

Automate Incidents: When an alert fires, the agent queries monitoring platforms, correlates signals across systems, determines probable root causes, and suggests or executes fixes

Automate Scheduled Workflows: It can perform scheduled background tasks, such as routine health checks and compliance sweeps

Investigate and Advise (Virtual Team Member): Engineers can ask natural-language questions (e.g., "what changed in the last hour?") in chat interfaces like Microsoft Teams to get grounded operational insights.

Running Incident Response Issues

Instead of forcing engineers to manually correlate disparate data, the agent follows a streamlined incident workflow: when an alert fires (in Azure Monitor, in my case), the SRE agent picks it up.  It queries logs using correlation IDs to connect the data so that the agent can do the Root Cause Analysis & Ticketing: The agent identifies the probable cause (such as a bad commit or memory trend) and can prefill an incident ticket in ServiceNow or PagerDuty with diagnostic findings

The support engineer, in this case me, reviews and approves the remediation.

Connects natively with Azure Monitor, Application Insights, Log Analytics, PagerDuty, ServiceNow, GitHub, and Azure DevOps

Tip: External tools can also connect via the Model Context Protocol (MCP), basically making any API accessible.

Customisation: Capabilities can be extended using Skills (Azure CLI scripts and marketplace runbooks), Python tools, Custom sub-agents, and Agent hooks

Billing: Operational reasoning is metered using Agentic Units (AUs) rather than standard raw tokens, with standard monthly allocations; I still have no idea what this will cost or how it is calculated.

Summary

The Microsoft Azure SRE Agent provides a structured, governed way to use AI for incident management. By pulling together context from observability tools and code repositories into a single thread, it reduces tool switching and speeds resolution.