<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
     xmlns:atom="http://www.w3.org/2005/Atom"
     xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Shaoom Limited — Insights</title>
    <link>https://shaoom.ai/insights</link>
    <atom:link href="https://shaoom.ai/feed.xml" rel="self" type="application/rss+xml" />
    <description>Practical engineering writing on AI adoption, data platforms, cloud cost, DevOps and security certification.</description>
    <language>en-GB</language>
    <lastBuildDate>Tue, 14 Jul 2026 00:00:00 GMT</lastBuildDate>
    <ttl>1440</ttl>
    <item>
      <title>Why your AI pilot never reached production</title>
      <link>https://shaoom.ai/insights/ai-pilot-to-production</link>
      <guid isPermaLink="true">https://shaoom.ai/insights/ai-pilot-to-production</guid>
      <pubDate>Tue, 14 Jul 2026 00:00:00 GMT</pubDate>
      <category>AI &amp; Automation</category>
      <description>The demo worked. The rollout stalled. Almost always it is one of four things — no evaluation set, no owner, no data access path, or no cost ceiling. Here is how we de-risk each one before writing code.</description>
      <content:encoded><![CDATA[The demo worked. Everyone in the room agreed it was impressive. Nine months later it is still a demo. This is the most common shape of an AI project we are asked to rescue, and the cause is almost never the model.

Across the assessments we have run, stalled pilots fail on one of four things. None of them is about capability. All of them are decided before a line of code is written.


## 1. There is no evaluation set

A demo is judged by whether the room nods. Production is judged by whether it is right often enough to trust, and nobody can answer that without a set of cases with known answers.

The work is unglamorous: sit with the people who do the task today, collect one or two hundred real examples, and write down what a correct response looks like for each. That set becomes the thing you run against every change. Without it you cannot tell an improvement from a regression, which means you cannot safely change anything, which means the pilot freezes.

If you take one thing from this article: build the evaluation set before you choose a model. It will outlive whichever model you pick.


## 2. Nobody owns the output

Ask who is accountable when the assistant is wrong. In a stalled project the answer is a shrug, or worse, "the AI". Systems without an owner do not get deployed, because no one is willing to sign for them.

The fix is organisational, not technical. Name a person in the business — not in IT — who owns the quality of the output, give them the evaluation results, and give them the authority to turn it off. Adoption follows accountability far more reliably than it follows accuracy.


## 3. There is no path to the data

Pilots are built on an export. Somebody pulls a spreadsheet, the assistant answers beautifully against it, and then the question arrives: how does this stay current?

That question is usually harder than the AI work. It means agreeing a source of truth, getting read access through the right boundary, handling permissions so the assistant cannot surface something a user should not see, and keeping it fresh on a schedule someone maintains. Teams that treat this as an afterthought lose months.

- Which system is authoritative for this data, and who says so?
- How does access work without copying the data somewhere less governed?
- If a document is restricted, does the assistant respect that restriction?
- What is the acceptable staleness — minutes, hours, or a day?


## 4. Cost is unbounded

A pilot serving five people costs nothing worth measuring. The same design serving five hundred, with long documents in every request, can produce a bill that ends the project in its second month.

Model the cost per interaction before you build, then set a hard ceiling in the system itself — a budget per user, per day, per workflow, enforced in code rather than watched on a dashboard. Caching repeated context and routing simple requests to smaller models routinely cuts spend by more than half without a change anyone notices.


## How we de-risk it

Our discovery engagement answers all four questions before committing to a build. Two weeks, fixed fee: we map the workflow, collect the evaluation set with the people who do the work, establish the data path and its permission model, and model cost at realistic volume.

Sometimes the honest answer is that the process should be fixed rather than automated. That finding is worth more than a pilot that never ships, and you get it in a fortnight rather than a year.]]></content:encoded>
    </item>
    <item>
      <title>Build the warehouse before you buy the model</title>
      <link>https://shaoom.ai/insights/warehouse-before-model</link>
      <guid isPermaLink="true">https://shaoom.ai/insights/warehouse-before-model</guid>
      <pubDate>Wed, 24 Jun 2026 00:00:00 GMT</pubDate>
      <category>Data &amp; Analytics</category>
      <description>The fastest route to a working AI feature usually runs through six weeks of unglamorous data work. What we check before agreeing to an AI engagement at all.</description>
      <content:encoded><![CDATA[Most requests that arrive as "we want AI" are, on inspection, requests for numbers people can agree on. The fastest route to a working AI feature usually runs through six weeks of unglamorous data work first.


## The tell

Ask three people in the business for last quarter's revenue and see whether the answers match. If they do not, the disagreement is not a reporting problem — it is a definitions problem, and no model will resolve it. An assistant reading from disagreeing sources will confidently produce a fourth answer.


## What we check before agreeing to an AI engagement

- Is there a single system that is authoritative for each entity — customer, order, product — or several that partially overlap?
- Are the key metrics defined once somewhere, or re-implemented in each report?
- Can the data be read on a schedule without someone exporting a file by hand?
- Is there a test that fails when the data is wrong, or does a human notice eventually?
- Do permissions travel with the data, or are they applied only at the reporting layer?

Three or more "no" answers and we recommend a data engagement first. It is a less exciting proposal and it is usually the one that makes the AI work possible.


## What that actually involves

Less than people fear. A warehouse for a mid-sized business is not a year-long programme. It is a managed database, pipelines that pull from the systems you already run, a modelling layer where each metric is defined exactly once, and tests that fail loudly when a number goes strange.

The modelling layer is the part that matters. Once "active customer" is defined in one place, every dashboard, every report and every assistant inherits that definition. That is what makes the answer the same whoever asks.

The warehouse is not a prerequisite because it is fashionable. It is a prerequisite because an assistant is only ever as trustworthy as the numbers underneath it.


## The sequence we recommend

Warehouse and definitions first. Then reporting, so people can see the numbers and argue about them while they are cheap to change. Then, once the definitions have survived contact with real users, the assistant on top. Teams that invert this order spend the same money and arrive later.]]></content:encoded>
    </item>
    <item>
      <title>Microsoft 365 Copilot readiness: the permissions problem nobody mentions</title>
      <link>https://shaoom.ai/insights/copilot-readiness</link>
      <guid isPermaLink="true">https://shaoom.ai/insights/copilot-readiness</guid>
      <pubDate>Tue, 02 Jun 2026 00:00:00 GMT</pubDate>
      <category>Modern Workplace</category>
      <description>Copilot inherits your sharing model. If SharePoint permissions have drifted for a decade, it will happily surface that drift to everyone. A practical pre-rollout checklist.</description>
      <content:encoded><![CDATA[Microsoft 365 Copilot does not have its own permission model. It inherits yours. Everything a user could already find through search, Copilot can surface, summarise and quote — instantly, and without the friction that kept it buried.

For most organisations that is the entire risk, and it has nothing to do with AI.


## Why permissions have drifted

SharePoint and OneDrive make sharing easy, which is the point. Over a decade the result is predictable: sites shared with "everyone in the organisation" for a project that ended years ago, files inheriting permissions nobody reviewed, and links passed around that never expired.

None of that hurt while finding a document required knowing it existed. Copilot removes that requirement. A question like "what are we paying our senior engineers" now returns an answer if a spreadsheet was ever shared too widely.


## A pre-rollout checklist

- Run a sharing report across SharePoint and OneDrive and list every site shared organisation-wide.
- Identify sites holding HR, finance, legal or client-confidential material and confirm their membership explicitly.
- Expire or revoke anonymous sharing links; set a default expiry for new ones.
- Turn on sensitivity labels for the categories that matter most, and apply them to the highest-risk sites first.
- Check that departed staff have actually lost access, rather than merely being disabled.
- Pilot with one department and ask them to try to surface something they should not see.

That last step is the one people skip and the one that finds problems. Give a small group an afternoon and an incentive to break it.


## What good looks like afterwards

Sensitivity labels applied where they matter. Sharing links with expiry by default. A quarterly review of organisation-wide sites with a named owner. And, importantly, a rollout that continues — the goal is not to delay Copilot but to deploy it without discovering your permission history in public.


## How long it takes

For an organisation of a hundred people with a decade of SharePoint behind it, four to six weeks of part-time work. Considerably less if sharing was governed from the start, and considerably more if the tenancy has been through a merger.]]></content:encoded>
    </item>
    <item>
      <title>Deployment frequency is a business metric</title>
      <link>https://shaoom.ai/insights/deployment-frequency</link>
      <guid isPermaLink="true">https://shaoom.ai/insights/deployment-frequency</guid>
      <pubDate>Tue, 12 May 2026 00:00:00 GMT</pubDate>
      <category>DevOps &amp; Platform</category>
      <description>Teams that deploy daily change their minds cheaply. Teams that deploy quarterly commit to guesses. How to move from one to the other without a platform rewrite.</description>
      <content:encoded><![CDATA[Teams that deploy daily change their minds cheaply. Teams that deploy quarterly commit to guesses. That difference shows up in the product long before it shows up in any engineering metric, and it is why deployment frequency belongs in a business conversation rather than a technical one.


## The compounding effect

A quarterly release cycle forces every decision to be made months ahead of the evidence. Scope is padded because the next window is far away. Risk accumulates because a hundred changes ship together, so when something breaks, the cause is somewhere in a hundred changes.

Shorten the cycle and the incentives invert. Small changes are safe to try. Being wrong is cheap. The organisation starts asking "what could we learn this week" instead of "what can we commit to for the quarter".


## The two numbers worth tracking

- Deployment frequency — how often a change reaches users.
- Change failure rate — how often a deployment causes a problem needing a fix.

They are usually assumed to trade off. In practice they improve together, because the same discipline that makes deploys frequent — small changes, automated tests, fast rollback — is what makes them safe.


## Getting there without a rewrite

The common objection is that frequent deployment requires re-architecting first. It rarely does. Most of the gain comes from four changes that sit alongside the existing system.

- Automate the release. If a deploy involves a checklist someone follows by hand, that is the constraint.
- Put the tests that actually catch regressions into the pipeline, and delete the ones nobody trusts.
- Separate deploying from releasing, with feature flags. Code can ship dark and be turned on later.
- Make rollback a single, rehearsed action. Teams deploy cautiously when undoing is uncertain.

Deployment frequency is not a measure of how fast engineers work. It is a measure of how quickly the business can act on what it has learned.


## What to expect

For a team releasing monthly, weekly is achievable in a quarter and daily within two. The limiting factor is almost always the manual steps in the release, not the architecture — and manual steps are the cheapest thing on the list to remove.]]></content:encoded>
    </item>
    <item>
      <title>Cyber Essentials in a month: what actually blocks certification</title>
      <link>https://shaoom.ai/insights/cyber-essentials-in-a-month</link>
      <guid isPermaLink="true">https://shaoom.ai/insights/cyber-essentials-in-a-month</guid>
      <pubDate>Tue, 21 Apr 2026 00:00:00 GMT</pubDate>
      <category>Compliance</category>
      <description>Most failures come down to unsupported software, missing MFA on admin accounts, and default firewall rules. A realistic four-week path for a team without a security specialist.</description>
      <content:encoded><![CDATA[Cyber Essentials is a short questionnaire covering five controls. Most organisations that fail do so on the same three points, and all three are fixable in weeks rather than months.


## What actually blocks certification

- Unsupported software. A handful of machines on an operating system past end-of-life, or a browser nobody updated. This fails outright — there is no partial credit.
- Missing multi-factor authentication on administrative accounts, particularly the cloud admin accounts created during setup and never revisited.
- Default firewall and router configuration, including the administrative password that shipped with the device.

Everything else in the scheme tends to be either already true or quick to arrange. These three account for most of the failures we see.


## A realistic four-week path

This assumes a team without a dedicated security specialist and one person able to give it a few hours a week.

- Week one — inventory. Every device, every operating system version, every account with administrative rights. Most of the eventual work is discovered here.
- Week two — patch and retire. Update what can be updated; replace or isolate what cannot. Unsupported software is the single most common cause of failure.
- Week three — accounts and access. Multi-factor authentication on every administrative account, removal of accounts belonging to people who have left, and separation of admin accounts from everyday ones.
- Week four — boundary and evidence. Change default credentials, close ports nothing needs, and assemble the evidence for the questionnaire.

Do the inventory honestly. A certificate obtained around a machine you did not declare protects nobody, and the first incident will find it.


## Why bother

Two practical reasons beyond the security itself. It is increasingly a procurement requirement — public sector contracts and larger private buyers ask for it, and its absence quietly removes you from consideration. And it lowers cyber insurance premiums often enough to cover its own cost.


## Staying certified

Certification lapses annually, and the second year is harder than the first if nothing changed structurally. Build the evidence into how you already work — automated patch reporting, a joiners and leavers process that actually removes access, a quarterly review of administrative accounts — and recertification becomes an afternoon.]]></content:encoded>
    </item>
    <item>
      <title>Reading a cloud bill properly — a 90-minute audit</title>
      <link>https://shaoom.ai/insights/cloud-bill-audit</link>
      <guid isPermaLink="true">https://shaoom.ai/insights/cloud-bill-audit</guid>
      <pubDate>Tue, 10 Mar 2026 00:00:00 GMT</pubDate>
      <category>Cloud &amp; Infrastructure</category>
      <description>Idle environments, oversized instances, forgotten snapshots and egress you never modelled. The four line items that account for most avoidable cloud spend, and how to check yours today.</description>
      <content:encoded><![CDATA[Most avoidable cloud spend hides in four line items. You can check all of them in about ninety minutes, and the first pass typically finds between fifteen and thirty per cent.


## 1. Environments nobody is using

Staging, demo and test environments provisioned for a project that ended, running continuously because nothing ever turned them off. This is the largest and easiest saving in almost every audit we do.

Non-production environments rarely need to exist outside working hours. Scheduling them to stop overnight and at weekends removes roughly two thirds of their cost without anyone noticing.


## 2. Instances sized for a guess

Almost everything is sized at provisioning, before anyone knows the real load, and almost nothing is revisited. Pull the last month of processor and memory utilisation. Anything sitting under twenty per cent has been paid for twice over.

Resize downward one step and watch for a week. The risk is far lower than teams assume, and the saving is immediate.


## 3. Storage nothing points at

Snapshots from a migration two years ago. Volumes detached when their instance was deleted. Backups with no retention policy, accumulating for ever.

- List snapshots older than your actual retention requirement.
- List volumes not attached to anything.
- Check whether infrequently accessed data is on storage priced for frequent access.


## 4. Egress nobody modelled

Data leaving the provider is billed, and it is the line item that surprises people most. Common causes are backups written to another region, chatty inter-service traffic crossing a zone boundary unnecessarily, and media served directly rather than through a content delivery network.

A CDN in front of static assets usually pays for itself immediately, because its egress is cheaper than the origin's and most requests never reach the origin at all.


## Making it stick

A single audit is a one-off saving; costs drift back within two quarters. Three habits keep it: tag every resource with an owner so orphans are identifiable, set a budget alert at a threshold that will actually fire, and put a fifteen-minute cost review in an existing recurring meeting rather than creating a new one.]]></content:encoded>
    </item>
    <item>
      <title>Flutter or native in 2026? An honest decision tree</title>
      <link>https://shaoom.ai/insights/flutter-vs-native-2026</link>
      <guid isPermaLink="true">https://shaoom.ai/insights/flutter-vs-native-2026</guid>
      <pubDate>Thu, 05 Feb 2026 00:00:00 GMT</pubDate>
      <category>Mobile Applications</category>
      <description>Cross-platform is the right default for most business apps — and the wrong one for a few specific cases. The questions we ask before recommending either.</description>
      <content:encoded><![CDATA[Cross-platform is the right default for most business applications in 2026, and the wrong answer for a few specific ones. The decision is easier than the debate suggests, because it turns on a small number of questions.


## Choose native when any of these is true

- The application's core value depends on platform capability that arrives first on native — advanced camera control, ARKit or its equivalent, complex background processing, or deep widget and watch integration.
- You need day-one support for platform features announced at the vendor's developer conference. Cross-platform frameworks follow, they do not lead.
- Sustained high-frame-rate custom rendering is central — games, real-time visualisation, heavy media editing.
- You already employ competent iOS and Android teams. Do not restructure a working team to save a codebase.


## Choose Flutter when these are true instead

- The application is primarily forms, lists, data display and workflow, which describes most business software.
- Consistent brand presentation across both platforms matters more than matching each platform's native conventions exactly.
- You have one team and need both platforms shipping on the same schedule.
- Time to market matters more than the last few per cent of platform polish.


## The questions people forget

The framework debate absorbs attention that the harder questions deserve. In our experience these determine success far more than the choice above.

- What happens without connectivity? Offline behaviour and conflict resolution are the largest hidden cost in mobile work, and they are framework-independent.
- Who holds the signing keys and the store accounts? They should be yours, in your name, from the first release.
- What is the update cadence after launch? An app is not a project with an end date; store requirements alone force changes annually.
- How will you know it is broken? Crash reporting and analytics from the first release, not retrofitted after the first bad review.

We have never seen a business application fail because of the framework. We have seen several fail because nobody planned for the second year.


## Our default

For business applications we recommend Flutter and are comfortable defending it: one codebase, one team, one release schedule, and a rendering model that behaves the same on both platforms. Where the questions above point to native, we say so — usually in the first conversation, because the answer rarely changes later.]]></content:encoded>
    </item>
    <item>
      <title>Buy, build, or configure: a framework for the middle option</title>
      <link>https://shaoom.ai/insights/buy-vs-build</link>
      <guid isPermaLink="true">https://shaoom.ai/insights/buy-vs-build</guid>
      <pubDate>Fri, 16 Jan 2026 00:00:00 GMT</pubDate>
      <category>IT Consulting</category>
      <description>The interesting answer is rarely at either extreme. How to judge whether a configured platform beats bespoke software for your process — before you commit a budget.</description>
      <content:encoded><![CDATA[The build-or-buy question is usually posed as a binary, and the interesting answer is almost always in the middle: configure a platform you buy, and build only the part that is genuinely yours.


## Start with what is actually distinctive

Write down the process you are trying to support, then mark each step as either something a competitor does identically or something that is genuinely particular to you.

Almost everything is the former. Invoicing, authentication, notifications, document storage, scheduling — these are solved, and solved better than you will solve them, by products that have had thousands of customers find their edge cases.

The parts that are genuinely yours are usually few and specific: a pricing rule nobody else has, a compliance workflow peculiar to your sector, an integration between two systems only you run together. That is the part worth building.


## A framework for the middle option

- Would a competitor recognise this process as the same as theirs? If yes, buy it.
- Does a platform do eighty per cent of it out of the box? If yes, configure it and build the remaining twenty as an extension rather than a replacement.
- Does the platform have an API that would let you build that twenty per cent without forking it? If not, that is a serious mark against it.
- What does leaving cost? If the answer is unknown, find out before signing, not during the renewal.
- Who maintains the configuration? Configured platforms still need an owner; "nobody" is how they rot.


## Where buying goes wrong

Two failure modes, both avoidable. The first is buying a platform then customising it so heavily it can never be upgraded — you now own bespoke software with a licence fee attached. The second is buying several overlapping products that each hold part of the truth, which is how an organisation ends up reconciling by hand.


## Where building goes wrong

Almost always by underestimating the second year. The build is budgeted; the maintenance, the security patching, the dependency updates and the person who understands it leaving are not. A useful discipline is to budget three years of ownership and compare that against the licence, rather than comparing the build cost against the first year's subscription.

If you take a single rule from this: buy the process, build the difference. Most disappointing systems are the result of doing exactly the opposite.]]></content:encoded>
    </item>
  </channel>
</rss>
