Introduction to the Investment Landscape in the UK for SaaS Startups

Elevator Pitch - 30 seconds

1. Hook: Start with the problem
2. Who you are
3. What problem you solve
4. Why your solution is special
5. What is the goal of each elevator pitch? Did I get it?
   
   AI generate template: "[Target customer] struggles with [problem], which costs them [$ / hours / risk]. I'm [name], founder of [company], and I [credibility]. We [solution], so they [key benefit]. Unlike [current alternative], we [differentiator]. We already have [traction]. I'd love to [specific ask]."

Product/Market Fit

You're in a good market with a product that meets its needs. Customers pull the product from you instead of you pushing it on them.  Have data that proves the business will work. Aim to be the best-in-class solution; attracting paying customers without advertising is ideal.  

Investors Looking for:

1. Size of the business; how quickly can the product/business get there.
2. Is AI a threat to the business,
3. People's needs/wants - do they need this going forward, will they?  Move up the Maslow hierarchy of needs chain.
4. Cloud native, API-centric, data-centric, AI, ML, security, 
   
5. Show the roadmap, it must be clear: how will finance be used?
6. They don't want capital-intensive businesses
   

Investment Stages

1. Idea,
2. Secure Founders,
3. MVP,
4. Seed (Angels, & Early VCs),
5. Scale (Series A)
6. Exit - Sell or IPO, average 7 years.

Capitalisation Table (who owns what in the business)

e.g. 50% ordinary shares to both founders
e.g. 35% each to both founders, Angel 20%, VC 10% at year 2.

Angels invest their own money; attractive to Angels get favourable tax breaks (SEIS/EIS)
Angel syndicates: groups of angels who invest; tools such as Odin/Funderbeam/FundMyPitch.
Venture Capitalist (VS) - Use "Risk and Reward" to decide on investing.  Seed VCs, focus on sectors or tax efficiency (EIS funds)

Ways to raise Funding:

1. Bootstrapping (self-funding and/or customer financing thru revenue) 
2. Equity (Pre-seed valuation typically £0.5-£1.5m, Seed with Revenue typically £1.5-£3m with Monthly Recurring Revenue MRR)
3. Crowd Funding (can be a good fit but generally tougher than most think)
4. Grants
5. Debt funding

Tip: Don't let it drag on - get it done fast, 3- 6 months max.
Tip: Raise investment as late as possible.  
Tip: Build my investment strategy before looking for investors.
Tip: The investor must fit with the startup
Tip: UKPostbox.com apparently offer good services for registered offices.

"Delaware flip" is how a startup can switch to being incorporated in Delaware. Delaware company owns the original company.

IP: Business & IP Centre

General Business Readiness (Business plan including project financials and GTM): 

1. Roadmap/Map your Journey
2. Where is the startup on the journey
3. Prove/show what has been done on the roadmap - Proof Points
4. Client validation
5. Differentiator
6. Scale Potential
7. Team

Recommended to me:

Zero to One by Blake Masters & Peter Thiel book

Testing for Coded Apps (automated E2E testing to get high quality)

Overview: Automation testing using AI generally ends with "test rot".  Kaizen Fix gets around test rot by switching the test source from the analysed system requirements to the code source as the logic to test.

Why: Gathering requirements in Agile software is continuously changing, so building tests based on the ask coupled with AI updating code realistically means the behaviour will change, DOM/Shaow DOM updating per build, and the full code base needs to be retested to ensure operational behaviour.

Hypothesis: Break the E2E testing into two distinct parts:
1) Does what the user asked for match what is delivered?  Ask AI to document the requirement from the code and compare it to the requirement the stakeholder signed off on. 
2) When code is updated, does this break any existing logic?  Regression tests to check existing logic work; if not, this requires a man in the loop to validate the change.

Proposed Solution: 
The four-step loop: 1. Code with AI → 2. Generate the code specification → 3. Tests generated by AI and MCP → 4. Test Baselines (run the dynamic Playwright test suites).  As the release occurs, the developer can automatically run the old tests and identify what is no longer working and why.  This can also be run during development.  I've been working on this different approach: an AI-assisted testing framework that treats the source code as the single source of truth — and turns it into a living, executable specification.

Key Point: reruns against the original/previous baseline catch genuine behaviour changes, not test rot. I deliberately left it unbranded so you can drop in KaizenFix (or keep it vendor-neutral) depending on where you're posting it.

How it works, in four steps:

1. Read the AI-generated code

AI (Claude or GitHub Copilot, working inside the IDE) analyses the application's source — components, routes, validation, business logic — and generates a full behavioural specification: what the system does today, fully documented, straight from the code.

2. Turn behaviour into programmed behaviour requirements

That specification becomes a structured requirements document. Not aspirational requirements — actual behaviour. If the app rounds a value, enforces a limit, or hides a button under a condition, it's captured.

3. Generate the regression suite

From the actual requirements into Playwright tests. AI generates detailed Playwright end-to-end tests — using platform-specific best practices for selectors and patterns, and environment configuration so the same suite runs against dev, UAT, or production. Each web app lives as its own isolated project with its own context and rules.

4. Lock in the baseline

At this point, the tests and the app agree by construction — the suite documents and validates the working behaviour. The tests part of the documentation.

The payoff comes when things change:

When the app or its logic evolves, rerun the original suite. Anything that breaks is a genuine, intentional-or-not change in behaviour — surfaced immediately, with the old expected values as evidence. Regenerate the spec, diff it against the last one, and you can see exactly what changed and whether you meant it. 

Amended +- June 2026 with Picture below: Source unknown

Simple Explanation of LLM's, Coding Agents

      GitHub Copilot, Claude Code, and Cursor are not AI models!  They are Coding Agents/Assistants.

They are the developer experience layer that sits in your IDE and seamlessly accesses various Large Language Models (LLMs) such as Claud Opus/Fable/Sonnet/Haiku or GPT5.

The actual intelligence comes from the underlying Large Language Model (LLM) such as GPT-5, Claude Opus/Sonnet, Gemini, 

Naming breakdown:

  VS Code / Visual Studio /Claude Code (IDE)    

      ─────▼────

GitHub Copilot / Cursor Extension / Claude Code Extension        (Coding Agent)      

      ─────▼────

 GPT-5 / Claude Opus / Gemini (LLMs)

Local vs Premium LLMS: 

Cursor can reference online LLMs like Claude Opus and use Ollama to run Qwen3-Coder (my pref. for now), DeepSeek-Coder, Llama 3.x, Mistral.  Ollama lets me point to a local LLM and use it for free (saving on tokens; there are other advantages as well).

My Setup for local LLM usage:

VS Code                                   +

Cursor Extension                     +

Ollama                                     +

Local LLM (Qwen3-Coder)    = 🚀 AI-Powered Software Development

Azure Container Jobs with Docker containing E2E Playwright testing

Overview: I recently did a great project with Playwright to continuously test Canvas Apps.  This post outlines how I did it.

Reporting: Every test suite run and the tests inside are documented in SharePoint lists. p Below you can see for a project called feedback the tests that verify DTAP Canvas apps (Dev, Test, and Prod).

The Feedback app, in production, is showing the availability tests run recently

 

CI: I decided to use Azure Container Jobs to run the Playwright tests on a Docker image.

Jobs: The Docker image get params and starts the type of tests, the trigger uses cron timing.

Azure Container Job: Each time a job is called, a new instance is created. This means multiple jobs can run simultaneously, and on each job instance I get multiple COUs, so I spawn out 2-4 Playwright processes so the tests run faster.

Client-Side vs Server-Side Rendering Websites

Web applications generally fall into the CSR or SSR.

Feature	Client-Side Rendering (CSR)	Server-Side Rendering (SSR)
Rendering location	Browser	Server
Initial page load	Slower	Faster
SEO	Worse	Better
Server workload	Lower	Higher
Browser workload	Higher	Lower
Typical use	Internal apps, dashboards	Public websites, e-commerce
System Classification	Power Apps Canvas App OutSystems (Low Code) Mendix (Low Code) React SPA Flutter Blazor WebAssembly Angular Vue	Power Pages Next.js Website ASP.NET MVC PHP E-commerce Product Page Blazor Server Ruby on Rails Razor Pages

The table is worth understanding as it affects architectural decisions as the project progresses.

Code Apps (Power Platform)

Code Apps (Power Platform) look to be gaining momentum. I think they will work for corporate app development as they offer governance and ALM as part of the Power Platform.   I saw this summary and thought it was a great overview.

AI infiltrates Development Segments so quickly

A decade ago, the companies that used Agile processes along these lines built the best software using CI/CD, and Automated Testing were the big winners. 

5 Years ago, low-code and platforms provided governance and faster ways to build apps.

We are seeing AI coming into all 6 steps, and low code is optional; it still offers good governance for businesses.

Test
Was: Unit Tests, Postman, Spec Flow, Selenium 
Becoming: Postman, MCP, Unit test generation

Deploy
Was: Scripts, PowerShell, TeamCity, Ansible, ARM, Portal UIs, TFS, Git, Terraform, Pulumi
Becoming: BICEP, MCP, VS Code/IDEs, GitHub, Claude CLI, GitHub Copilot

Code
Was: Java, C#, NodeJS, SDKs, RUST, GO APIs, Low-code/No-code
Becoming: Python, TypeScript, Power Platform, Agents