Working document · Skeleton v0.1 · 19 August 2026

Business Plan
Skeleton

The structure a Start Up Loan assessor reads, in their order, with ProofGuard content slotted in and ownership marked section by section. A scaffold to fill on the call — not a finished plan.

How to use this

A skeleton, not a template

This is the structure a Start Up Loan assessor reads, in the order they read it, with the ProofGuard-specific content we already hold slotted in. Sections marked Aaron need his input and cannot be written for him; sections marked Paul are drafted from existing project material.

The assessor is answering one question: can this person repay £X a month for Y years? Every section either supports that or wastes their time. Market size matters far less than a credible route to the first hundred sales.

Status: skeleton only. No figures below are final, and nothing here has been agreed with a lender. The financial sections are placeholders until the funding amount and scope are settled — see the funding page.

01

Executive summary

Written last, read first. One page maximum.

Cover

  • What ProofGuard is, in one sentence a stranger understands
  • The problem and who has it
  • Stage reached — working prototype proven, not an idea
  • How much is being borrowed, what it buys, and over what period
  • How it gets repaid

Lead with the proven POC. Most applications at this stage have nothing built.

02

The founder

Aaron — this is the section the assessor weights most heavily, because the loan is personal.

  • Background and relevant experience
  • Why this problem, and why you specifically
  • Current employment and how that continues alongside the business
  • Skills gap and how it is covered (external technical delivery — named)
  • Time commitment, honestly stated

Do not hide the day job. Continuing income strengthens affordability rather than weakening the plan.

03

The problem and the product

Problem

  • Who is at risk, when, and what existing options fail to do
  • Evidence — not anecdote

Product

  • The device, the app, and how they work together
  • The three states: Watch / Shield / Emergency
  • The unique mechanism — the evidence loop
  • What is deliberately out of the first release (no microphone, no camera) and why

Pull from the POC Lab and Phase 2 Spec pages. Keep it plain — the reader is not an engineer.

04

Proof it works

The strongest section available, and the one most applications cannot write at all.

  • POC gate passed — three-button BLE control of Watch / Shield / Emergency, demonstrated on video
  • iOS and Android apps built and running on real handsets
  • Milestone 1 outstanding: ESP32-C3 with on-board antenna validated against through-wall range and phone-locked triggering
  • Development spend to date, and by whom

Include a photograph of the bench rig and a still from the demo video.

05

Market and competition

  • UK market size and growth — from the Market Intel page
  • Named competitors and what each does badly
  • The positioning gap being taken
  • Who the first customer actually is — be narrow

Assessors discount big market numbers. A narrow, reachable first segment is worth more than a large addressable one.

06

Route to market

  • Channels, in priority order, with cost per channel
  • Pricing: device, app subscription, bundle
  • First 100 units — concretely, where do they go?
  • Current demand evidence: none. No waitlist, no sign-ups, the page has not been shown to anyone. State that plainly and say what will be done about it — an assessor will spot an unevidenced demand claim faster than an absent one
  • Partnerships under consideration (24/7 monitoring providers)

This is the section that most often sinks an application. Vagueness here reads as no plan.

07

Operations, compliance and risk

  • Manufacture: prototype route, then production run, MOQ and lead times
  • UKCA / CE marking, radio compliance, battery shipping
  • GDPR — what data is held, where, and for how long
  • Product liability and insurance
  • Risk register with mitigation for each item

Naming your own risks builds credibility. Omitting them does not hide them.

08

Use of funds

Line by line. Assessors compare this against the amount requested.

LineAmountNote
MVP developmentTBCPhased, evidence-gated
Hardware & prototype toolingTBCAt cost
First production runTBCSubject to MOQ
Certification & complianceTBCUKCA, radio, safety
Launch marketingTBCFirst 100 units
Working capitalTBCBuffer
Total requestedTBCAgainst £25,000 per-applicant ceiling

Complete this before deciding the loan amount, not after. Because the £25,000 cap is on total outstanding balance per person, this table has to cover the route to revenue — not just the MVP.

09

Financial forecast

  • 12-month cash flow — monthly, opening and closing balance, showing the loan repayment as a line
  • Unit economics: BOM cost, landed cost, retail price, gross margin per unit
  • Subscription economics: ARPU, churn assumption, contribution
  • Break-even volume and the month it is reached
  • Three scenarios — conservative, expected, optimistic

Existing material to draw on: the Revenue Projection Scorecard and Subscription Economics Analysis already in the project folder.

The one number that must work: the conservative scenario still has to service the monthly repayment. If it does not, borrow less or lengthen the term.

10

Personal Survival Budget

Aaron only — submitted alongside the plan, and assessed alongside it.

  • Average monthly personal income — employment, contract work, any benefits
  • Every monthly outgoing — housing, utilities, food, transport, credit commitments, childcare
  • The surplus, and how the loan repayment fits inside it

Understating outgoings is counterproductive: the assessor is testing whether repayment is survivable, and an implausibly low figure invites scrutiny.

Official PSB template → Back to funding →