Planily_Integrated_Strategy_Report (1)

1.

P L A N I LY
Integrated &
AIProduct
Strategy,Report
Marketing
From mental load to shared responsibility — one strategy across product, marketing and AI
AI Strategy Consulting Project · June 2026

2.

INTEGRATED STRATEGY REPORT
Executive Summary
O N E PRO DUC T, O NE STO RY — ACRO SS MA RK E T I NG , PRO DUCT JO URNE Y A ND A I
Lead with what Planily removes
Trust is the strongest differentiator
The value proposition
theand
experience
not being
the parent
who always
remembers
— mental is
load
invisibleof
labour
removed,
not another
app added.
Privacy be
is built
in by marketing
design, notasset.
bolted on. It is Planily's most defensible advantage and
should
an active
Convert information into confirmed action
Right model for the right task
The product
turn family
messytasks.
school emails, PDFs and WhatsApp messages
into
assigned,journey
visible,should
confirmed
A five-layer
routing order
rules, retrieval,
small scales.
model, large model, human —
keeps
AI cost-effective
and—trustworthy
as Planily
The API wins at pilot scale
Human oversight stays mandatory
At ~50Self-hosting
families, paid
APIs to
with
batchnot
processing
beat
self-hosting
several times
over.
is aLLM
number
watch,
a phase to
budget
for.
Payments,
medical,
safeguarding and location are never automated. AI cuts manual
work,
not human
control.
Planily | Integrated Strategy Report
2

3.

01
Marketing & Trust Strategy
Positioning Planily around trust, not features

4.

MARKETING & TRUST STRATEGY
What We'll Cover
T HE MA RK E T I N G & T RUST ST RAT EGY AT A G LA NCE
01
02
03
Client & product context
Target audience
Positioning & differentiators
Where Planily is today and who it competes with
The default parent and the real friction point
Four genuine edges no competitor matches
04
05
06
Growth & acquisition
Pricing & objections
Trust, privacy & GDPR
Relationship-led referral before paid spend
Selling back time, not storage
Privacy by code as a marketing asset
Planily | Integrated Strategy Report
4

5.

MARKETING & TRUST STRATEGY · SECTION 1
Marketing Executive Summary
T HRE E REA LI T I ES G RO UND T HI S ST RAT EGY
A UK AI family organiser
Planily turns school emails, WhatsApp and PDFs into structured shared tasks, reducing the mental load carried by one parent.
Pre-pilot, relationship-driven
The product is pre-pilot; growth has been entirely relationship-led; the strongest differentiator is trust, not features.
Privacy built in by design
Not bolted on. This is Planily's most defensible competitive advantage and should be an active marketing asset.
Lead with what is removed
Lead with what Planily removes — mental load, invisible labour — rather than what it adds: another app, another subscription.
Planily | Integrated Strategy Report
5

6.

MARKETING & TRUST STRATEGY · SECTION 1
Client & Product Context
PRO DUC T STAT US A ND T HE CO MPE T I T I VE LA NDSCA PE
Product status
Late alpha — full redevelopment underway
Competitive landscape
Cozi / FamilyWall
US-built, manual entry, poor reviews — direct opportunity
Pilot launch expected imminently
Google Calendar
Stores what you put in; can't read or act on information
AI layer: Google Gemini (evaluating smaller / open-source LLMs to cut cost at
scale)
WhatsApp / Email
WhatsApp concierge tested internally — not yet stress-tested with real users
Where information arrives — but no processing layer
ParentMail / ClassDojo
More capable than a calendar: task assignment, shopping lists, meal planning
School comms only; no household coordination
Planily's edge: the automation gap — no competitor reads and acts on family information automatically.
Planily | Integrated Strategy Report
6

7.

MARKETING & TRUST STRATEGY · SECTION 2
Target Audience
T HE DE FAULT PA RE NT — ST RUCT URA LLY OVE RBURDE NE D, NOT DI SO RG A NI SE D
The Default Parent
1
Dual-working households
Both adults employed; admin competes with work
Typically a mother in her 30s–40s
Carries 65–75% of household planning
At least one school-age child
2
Lone parents
No second adult to share the cognitive load
Not disorganised — structurally overburdened
“It's less about
assigning
removing
mental
load.” the task — it's more about
3
4
Separated / blended families
Coordination across multiple adults and homes
School-connected families
High-volume comms requiring regular action
— Sachin Patel, Founder
Planily | Integrated Strategy Report
7

8.

MARKETING & TRUST STRATEGY · SECTION 3
Positioning & Value Proposition
MO N E Y FO R T I ME — LEA D W I T H W HAT I S RE MOVE D
Working positioning statement
ForsoUK
families
school-age
children,
Planily not
is the
AI layeralone.
that turns the endless stream of emails, messages and school communications into clear, shared tasks
—
the
mentalmanaging
load of family
life is carried
together,
bycalm
one person
Core message: ‘Money for time’
Lead with what is removed
Planily doesn't
compete
onthe
price
with free tools.
It asks
families to pay for the
experience
of not
carrying
coordination
burden
themselves.
Fewer
forgotten.
Fewer
last-minute
scrambles. Fewer conversations that start
with
‘I things
assumed
you knew
about
that.’
65–75%
of family admin falls on one parent
Planily | Integrated Strategy Report
4
genuine differentiators vs. all competitors
0
competitors read & act on family emails automatically
8

9.

MARKETING & TRUST STRATEGY · SECTION 3
Four Genuine Differentiators
E DG ES COZ I , FA MI LYWA LL , G O O G LE CA LE NDA R A ND W HAT SA PP CA NNOT MATCH
Automation over storage
UK-native design
Every competitor
is a container for information. Planily reads and acts on it. School email →
calendar
event, automatically.
Built withUS
specific
knowledge
of UK school systems, academic calendars and communication
formats.
tools don't
have this.
Shared responsibility
Calm by design
Built forincluding
multi-adult
coordination,
not personal to-do lists. Tasks visible and assignable across
adults,
separated
households.
The WhatsApp
is explicitly
designed to feel calm and trustworthy, not add more
noise.
A design concierge
principle, not
a tagline.
Planily | Integrated Strategy Report
9

10.

MARKETING & TRUST STRATEGY · SECTION 4
Growth & Acquisition Strategy
RE LAT I O N SHI P - LE D RE FE RRA L BE FO RE PA I D ACQ UI SI T I O N
Current model
Usage insight
100% relationship-led.
Founder's
network
users'
networks
→ community
connectors
embedded
in multiple school
/ club
circles.→
First
sign-ups:
personal
LinkedIn and
1-to-1.
~1,000
WhatsApp
requests/day · ~40 per family/week · Activity peaks on weekends —
time
content
accordingly.
1
2
3
Support referrals — don't replace them
Equip community connectors
Build B2B2C credibility in parallel
Shareableparents
explainers,
before/after
examples,
language
can repeat
to other
parents.simple
parents groups)
active inand
multiple
networks
+ sports club
+Find
WhatsApp
give them
tools(PTA
to share
naturally.
A school recommendation
carries more
trust than
Requires
data governance structures
in place
first. any ad.
Planily | Integrated Strategy Report
10

11.

MARKETING & TRUST STRATEGY · SECTION 5
Pricing & Objection Handling
T HE A N SW E R I S T HE AUTO MAT I O N G A P, NOT T HE FEAT URE LI ST
The core objection: “Families already use WhatsApp, email and Google Calendar for free. Why pay?”
Objection
Recommended response framing
“I already use Google Calendar”
Planily fills it for you. Google Calendar stores what you put in; Planily creates events from your school emails automatically.
“WhatsApp does this for us”
WhatsApp is where information arrives. Planily turns that information into a task assigned to the right person — without manual
processing.
“It's expensive for what it does”
The value is time and mental energy returned. 20 minutes saved per day = hours per week. Planily sells back time, not storage.
“I don't trust it with my kids' data”
This deserves a direct answer — see the Trust & Privacy slide.
Google Calendar stays. Planily sits between it and the chaos — doing the work no existing tool does.
Planily | Integrated Strategy Report
11

12.

MARKETING & TRUST STRATEGY · SECTION 6
Trust, Privacy & GDPR as a Value Proposition
PRI VAC Y BY CO DE — PROT ECT I O N E MBE DDE D I N T HE A RCHI T ECT URE
What ‘privacy by code’ means
Why it's a marketing asset
Public-facing trust layer
Data protection is architectural, not a policy document
Data is uniquely sensitive: children, schools, health,
finances
Privacy Policy live at planily.co.uk/PrivacyPolicy
Six-week data retention window
Schools and MATs need auditable privacy to recommend
Planily
Terms of Service live at planily.co.uk/TermsOfService
Minimal dataset: name, phone, email only
Cozi and
don't make privacy prominent —
own
this FamilyWall
space
Dedicated Trust & Support page — canonical trust answer
All WhatsApp inputs high-risk by default (UK GDPR Art.
25)
Link from onboarding, school materials, any paid
marketing
Note: all specific privacy claims require sign-off from the GDPR & Compliance Analyst before any external publication.
Planily | Integrated Strategy Report
12

13.

MARKETING & TRUST STRATEGY · SECTION 7
Summary of Recommendations
SI X MOVES T HAT T URN ST RAT EGY I NTO ACT I O N
Lead with mental load removal
1
The value
prop
is not
features — it's the experience of not having to be the
person
who
always
remembers.
Treat privacy by design as a brand position
2
Support referrals before paid acquisition
3
Trust-based referral is the right channel. Make referral easier, not more
expensive.
Position Google Calendar as complementary
4
Develop Trust & Support as a marketing asset
5
Prerequisite for school partnerships and reduces consumer sign-up friction.
Planily | Integrated Strategy Report
A genuine architectural commitment competitors lack — make it visible and
marketable.
Remove the perceived conflict. ‘Planily plus your calendar’ lowers the barrier to
trial.
Time content to weekend peaks
6
~40 requests/family/week,
skewed to weekends. Sunday evening is the highestintent
moment.
13

14.

02
Product & User Journey
Turning information into confirmed, shared action

15.

PRODUCT & USER JOURNEY ANALYSIS · SECTION 1 –2
Purpose & Core User Problem
F RO M UN ST RUCT URE D FA MI LY I NFO RMAT I O N TO CLEA R, SHA RE D ACT I O NS
Purpose of this analysis
The core user problem
This section
analyses
how
Planily's
product
can reduce
family
mental
load by
turning
unstructured
family
information
intojourney
clear,
shared
actions
—
from
receiving
school
or
family
information
to creating
tasks,
reminders,
calendar
events
and
responsibility
assignments.
The hidden coordination work behind family tasks. The key questions Planily must
answer:
What needs to happen?
Who is responsible?
Refined from
client feedback,
it connects
the userparsing
journey
directly
Planily'ssystem.
actual
features:
the WhatsApp
concierge,
school-letter
and
familytoplanning
What supporting information is needed?
Has the responsible person confirmed it?
Is there any risk requiring stronger confirmation?
Planily | Integrated Strategy Report
15

16.

PRODUCT & USER JOURNEY ANALYSIS · SECTION 3
Current User Journey
A F LOW F RO M MESSY I NPUT TO ST RUCT URE D FA MI LY ACT I O N
Receive
Parent
receives
info
fromphoto
a school
email, WhatsApp
PDF, screenshot,
or
message
›
Interpret
AI extracts
key
dates,
deadlines,
people,
activity
type,
actions
anddetails:
conflicts
›
Suggest
Planily
suggests
a task,
reminder,
calendar
event
or
responsibility
assignment
›
Confirm
Thesuggestion
user reviews
andanything
confirmsisthe
before
added
›
Assign & sync
Tasksynced
assigned
toexternal
a family calendars
member
and
with
Planily is the
organising structures
layer between
existing
communication
toolsalready
and practical
interprets
information,
it, and
pushesfamily
it back
into the tools they
use. household action. Families don't replace WhatsApp, email or Google Calendar — Planily
Planily | Integrated Strategy Report
16

17.

PRODUCT & USER JOURNEY ANALYSIS · SECTION 4
AI Intervention Points
A I O N LY W HE RE I T CLEA RLY RE DUCES FRI CT I O N I N T HE JO URNE Y
Information extraction
Intent interpretation
Dates,
times, deadlines, locations, costs, permissions and people from emails, PDFs, photos
or
messages.
Understanding
WhatsApp commands like ‘add football club on Saturday
and
assign it to natural-language
Dad’.
Task generation
Activity classification
Converting extracted information into structured tasks, reminders, calendar events or
checklists.
Recognising
a school trip, sports club, medical appointment, party, homework deadline or
payment
reminder.
Contextual support
Conflict detection
Suggesting what's needed: football kit, packed lunch, permission form, payment or travel
time.
Identifying clashes between a new event and existing family commitments.
Responsibility allocation
Query support
Helping users assign tasks to the right adult or family member.
Answering ‘what's happening this week / at the weekend / assigned to me’ via WhatsApp.
Planily | Integrated Strategy Report
17

18.

PRODUCT & USER JOURNEY ANALYSIS · SECTION 5
Priority Use Cases Linked to Features
PRAC T I C A L , T ESTA BLE JO URNE YS FO R T HE I NI T I A L LAUNCH O R PROTOT YPE
Priority use case
Example input
Feature
School email → calendar event
Parent forwards a school email about a trip
School-letter parsing; calendar creation
Extracts date, time, location, deadline,
action
User confirms before event added
WhatsApp → assigned task
“Add football club Sat 10am, assign to Dad”
WhatsApp concierge; task assignment
Interprets intent, creates task, assigns
adult
User confirms before task created
School activity → checklist
Letter mentions club, PE day or trip
Activity classification; checklist/reminder
Suggests kit, lunch, payment or
permission form
User confirms checklist & reminder
Weekly family plan query
“What do I need to do this weekend?”
WhatsApp concierge; plan summary
Retrieves upcoming tasks & events for
user
Low-risk read-only; no action added
Calendar sync & sharing
User confirms event, assigns to another
adult
Planily calendar; external sync
Adds event and syncs relevant calendars
Confirmation required before sync
Planily | Integrated Strategy Report
AI action
Confirmation
18

19.

PRODUCT & USER JOURNEY ANALYSIS · SECTION 6
Risk-Based Confirmation Framework
N OT A LL AC T I O NS CA RRY T HE SA ME RI SK — CO NFI RMAT I O N SCA LES W I T H I T
Low risk
Medium risk
High risk
Example tasks
Shoppingitems
list items, simple household reminders, routine
checklist
Example tasks
School clubs, homework
deadlines, ordinary
appointments,
sports activities
Example tasks
School trips,
payments,separated-family
medical appointments,
location,
safeguarding,
access child
Confirmation
Light confirmation or partial automation once tested
Confirmation
User confirmation before adding
Confirmation
Strong confirmation, clear user control, possible human
review
Future model
Rules, templates or narrow SLM
Future model
SLM or LLM with structured prompt and validation
Future model
LLM/SLM only with strict guardrails & mandatory
confirmation
Planily | Integrated Strategy Report
19

20.

PRODUCT & USER JOURNEY ANALYSIS · SECTION 7
Link to Scaling & Roadmap
A STAG E D A PPROACH — DO N'T AUTO MAT E E VE RY USE CA SE AT O NCE
1
Short term
Pilot
2
Medium term
Growth
3
Longer term
Scaling
Small set of high-value journeys, easy to explain &
test
Once more user-behaviour data exists
A more layered AI system
School email→event,
WhatsApp→task,
activity→checklist,
weekly
plan query
Move repeatable low-risk actions into structured
workflows
Rules / SLMs handle routine, low-risk tasks
Most actions require confirmation
Reduces reliance on expensive general-purpose LLM
calls
Larger modelsinputs
reserved for ambiguous, complex,
high-context
Planily | Integrated Strategy Report
20

21.

PRODUCT & USER JOURNEY ANALYSIS · SECTION 8 –9
Recommendations & Further Research
PRI O RI T I SE JO URNE YS T HAT RE DUCE HI DDE N CO O RDI NAT I O N WO RK
Initial recommendations
Further research needed
Prioritise journeys that convert unstructured info into confirmed, assigned, visible
actions
Example
user flows
or anonymised emails, PDFs and WhatsApp-style messages to
test
proposed
journeys
Show
what the
AI understood before acting (‘I found a school trip Friday 9am
—
addusers
and assign
to Sarah?’)
Current product screenshots or process maps of the web app and WhatsApp
concierge
Avoid over-automation early; a clear confirmation system builds trust
Confirmation of which journeys matter most for the next three months vs. the longer
roadmap
Design around calmness and clarity — reduce noise, don't create more alerts
Expected usage volume per core journey, to link journey design with cost & scaling
assumptions
Planily | Integrated Strategy Report
21

22.

03
AI Strategy & Use-Case Prioritisation
Choosing the right model for the right task

23.

Executive Summary
T HE ST RA T E G I C O VE RVI E W A ND PRI MA RY RE CO MME NDA T I O NS
Focus AI investment on solving a clear user problem.
Build privacy by design through minimal data retention and a clear AI access
framework to support GDPR compliance.
Continue using paid LLM APIs with batch processing where possible, as selfhosting is unlikely to be cost-effective at Planily’s current scale.
Prioritise AI features that clearly reduce friction for parents, such as task
generation and structured organisation of school communications.
Adopt a hybrid AI approach: use smaller or fine-tuned models for routine tasks,
with escalation to larger models or human review only for ambiguous or highrisk cases.
Planily’s value proposition is saving parents time by taking the remembering off
their plate — not replacing their decision-making.
Ensure AI reduces repetitive administrative work while maintaining human
oversight and user control.
1

24.

AI Strategy &
Use-Case Prioritisation
Choosing the right model for the right task, at the right point in Planily's growth

25.

AI STRATEGY & USE -CASE PRIORITISATION
The Problem We're Solving
Settled vs. still open
Planily already runs on Gemini, and the core WhatsApp loop has been tested. The question isn't whether to use AI — that's settled. What's still open is how
Planily gets from a working demo to something families trust day to day, without cost or risk creeping up as the pilot grows.
The real question
For each AI task in the product — school-email parsing, WhatsApp task capture, weekly digests, calendar suggestions — should Planily use a third-party
LLM API, a smaller self-hosted model, a rule-based shortcut, or a human reviewer? And does the answer change as the product scales?
This lines up with what Planily already said matters: weighing LLM APIs against smaller/open-source models, finding tasks that can be done more cheaply, and building
an escalation path so a stronger model or a person only steps in when something is genuinely ambiguous or high-risk.
AI Strategy & Use-Case Prioritisation | Planily
2

26.

AI STRATEGY & USE -CASE PRIORITISATION
Key Findings
F I VE T A K E A W A YS T HA T SHA PE E VE RYT HI NG DO W NST RE A M
2.1
2.2
2.3
Task scope beats model size
The edge is automation, not another
calendar app
At pilot scale, the API wins on cost
A smaller model earns trust through a narrower job,
not by being smaller. A date in a school email doesn't
need a large model — a rule, or at most a small
classifier, handles it.
Cozi and FamilyWall already cover shared calendars
and lists. Neither reliably turns a messy email or
WhatsApp message into a structured task — that's the
gap worth Planily's AI spend.
Around 50 families at ~40 messages/week, even the
cheapest realistic self-hosting setup costs more per
month than the entire pilot's API bill, several times
over.
2.4
2.5
One model for everything isn't the
answer
Privacy can't be an afterthought
A five-layer routing order — rules, retrieval, small
model, large model, human — is the most costeffective and trustworthy setup (detailed next page).
Planily touches school, family and children's data. UK
ICO guidance, including the Children's Code, applies
directly to how data is minimised, retained and
automated.
AI Strategy & Use-Case Prioritisation | Planily
3

27.

AI STRATEGY & USE -CASE PRIORITISATION · KEY FINDING 2.4
One Model for Everything Isn't the Answer
E A C H ME SSA G E O R E MA I L I S CHE CK E D, I N T HI S O RDE R, BE FO RE A NYT HI NG I S A C T I O N E D
1
2
3
4
5
Rules & templates
Retrieval
Small model
Large model
Human in the loop
Dates, amounts, recurring
formats, consent-form language
Pull from Planily's own stored
tasks/calendar before generating
Messy but narrow text the rules
can't catch
Escalation only — genuinely
ambiguous or mixed-intent
Always, for payments, medical,
safeguarding, location
This ordering matters later, too — the model evaluation ahead is really about finding the right tool for layer 3, the small model, since that's where the choice between
an API and self-hosting actually matters.
AI Strategy & Use-Case Prioritisation | Planily
4

28.

AI STRATEGY & USE -CASE PRIORITISATION · KEY FINDING 2.5
Privacy Can't Be an Afterthought
Planily touches school, family, and sometimes children's data — so the UK ICO's guidance applies directly: keep data to the minimum necessary,
don't hold it longer than needed, and treat any fully automated decision with a real effect on someone as needing extra safeguards. The ICO's
Children's Code goes further: geolocation should be off by default for anything children might access.
Never automated
Nothing in the high-risk category — medical, safeguarding, payments,
location — should ever get actioned automatically.
AI Strategy & Use-Case Prioritisation | Planily
Retention as policy
Data retention needs to be written down as actual policy, not handled
informally on a case-by-case basis.
5

29.

AI STRATEGY & USE -CASE PRIORITISATION
Calculations & Assumptions
SO T HE C O ST F I G URE S E LSE W HE RE I N T HI S SE CT I O N A RE CHE CK A BLE , NO T JUST A SSE RT E D
40 messages / family / week
1,500 input / 300 output tokens
4.33 weeks / month
Working estimate for how often a family interacts
with Planily via WhatsApp — school-email
forwards, task requests, digest queries.
Placeholder based on a typical short message plus
surrounding context. To be swapped for a real
figure once sample messages are available.
Monthly volume uses 52 weeks ÷ 12 months, not a
flat 4 — otherwise monthly figures quietly
underestimate the real annual cost.
Carried through the family-count milestones used for planning: 50 families at pilot launch, scaling to 100, then 500, then 1,000.
AI Strategy & Use-Case Prioritisation | Planily
6

30.

AI STRATEGY & USE -CASE PRIORITISATION · CALCULATIONS 3.2
Request Volume by Family Count
A PPLYI N G T HE 4 0 ME SSA G E S/FA MI LY/W E E K A SSUMPT I O N A CRO SS T HE FO UR PLA N N I N G MI LE ST O N E S
Families
Weekly requests
Monthly requests (×4.33 weeks)
50 (pilot launch)
2,000
~8,670
100
4,000
~17,330
500
20,000
~86,670
1,000
40,000
~173,330
Request volume scales linearly with family count under this model — the cost question (next page) is where the real decisions live.
AI Strategy & Use-Case Prioritisation | Planily
7

31.

AI STRATEGY & USE -CASE PRIORITISATION · CALCULATIONS 3.3
Monthly Cost by Family Count & Pricing Tier
C URRE N T PUBLI SHE D G O O G LE G E MI NI RA T E S, SA ME 1 , 5 0 0 /3 0 0 T O K E N A SSUMPT I O N
Families
Flash-Lite, standard
Flash-Lite, Batch
Flash 3.5, standard
50
$7.15
$3.58
$42.90
100
$14.30
$7.15
$85.80
500
$71.50
$35.75
$429.00
1,000
$143.00
$71.50
$858.00
Even at 1,000 families — the top of the current 3-year horizon — the cheapest tier stays under $150/month. The gap between tiers is large: routing
structured, low-ambiguity tasks to Flash-Lite Batch instead of defaulting to Flash 3.5 saves roughly 80-90% on its own. The biggest cost lever isn't self-hosting
— it's not over-using the expensive tier.
AI Strategy & Use-Case Prioritisation | Planily
8

32.

AI STRATEGY & USE -CASE PRIORITISATION · SECTION 4
SLM Cost Threshold: What We'd Be Hosting
SE C T I O N 2 . 3 SA I D T HE A PI W I NS A T PI LO T SCA LE — T HI S I S T HE W O RK BE HI ND T HA T C LA I M
Email and WhatsApp parsing is fixed-schema extraction — pulling dates, names and task types into structured fields, not open-ended reasoning. It
doesn't need a frontier model, and it's not a great fit for a general-purpose always-on GPU. The realistic candidate is a small model, fine-tuned on
Planily's own extraction schema, on modest hardware.
RAG (rejected)
$350–$2,850/mo
Looks things up at query time — suits open-ended Q&A over a large, changing
knowledge base. That's not this job. The ongoing infrastructure cost would
dwarf Planily's entire AI budget.
Fine-tuning (selected)
<$100 one-off
Trains the model directly on a fixed, repeatable extraction job. A one-off
training run, often under $100 for a few hundred examples, with near-zero
marginal cost afterwards.
Strongest fits: Phi-4-mini (3.8B, runs without a GPU) and Mistral's Ministral 3B. Both run on an entry-level GPU (or CPU-only for the smallest variants) at roughly $250–$400/month —
replacing the $384/month general-purpose GPU figure used in the draft, which overstated the cost of an untuned, always-on instance.
AI Strategy & Use-Case Prioritisation | Planily
9

33.

AI STRATEGY & USE -CASE PRIORITISATION · SECTION 4.2
Where the Threshold Actually Sits
SE LF - HO ST I N G ($ 2 5 0 – $ 4 0 0 /MO ) CO MPA RE D A G A I NST T HE A PI CO ST S FRO M SE C T I O N 3 . 3
Comparison tier
Self-hosting becomes cheaper at
Notes
Flash-Lite, Batch
~3,500–5,600 families
Best case for the API — most routine, queueable traffic
Flash-Lite, standard
~1,750–2,800 families
More realistic if a meaningful share needs a near-instant reply
Flash 3.5, escalation tier
~290–470 families
Caution — this comparison is misleading (see below)
The honest headline
For the traffic a fine-tuned small model would actually replace — routine structured extraction — self-hosting doesn't become cost-comparable until roughly 1,750–5,600
families, well beyond the 1,000-family ceiling this roadmap plans for. The 290–470 figure compares against the escalation tier, which exists specifically for ambiguous, highrisk messages that routing logic deliberately keeps away from smaller models. Treat that row as a sense check, not a recommendation.
AI Strategy & Use-Case Prioritisation | Planily
10

34.

AI STRATEGY & USE -CASE PRIORITISATION · SECTION 4.3 –4.4
What This Means for the Decision
T HE F O UR - LA YE R RO UT I NG ST RUCT URE , W I T H T HE SMA LL - MO DE L LA YE R MA DE E XPLI C I T
Layer
Handles
Tool
Cost
Rules
Dates, amounts, recurring formats
Regex & templates
Zero
Small model
Structured but messy text rules can't catch
Fine-tuned Phi-4-mini or Ministral 3B
Near-zero once trained
Large model
Ambiguous or mixed-intent messages, used sparingly
Gemini API
Per-request
Human review
Payments, medical, safeguarding, location
Planily team or parent
Mandatory, never automated
Self-hosting isn't a Years 1–3 decision — it's a number worth watching, not a phase worth budgeting for. If growth tracks at or below the planned 1,000-family ceiling,
stay on the API throughout. If it heads toward 2,000+ families inside three years, that's the point to revisit this section with updated numbers.
Note: the $250–$400 hosting estimate and the token assumption behind it are both estimates, not measured figures — worth checking against real sample messages and a tested model
checkpoint before leaning on this threshold too heavily.
AI Strategy & Use-Case Prioritisation | Planily
11

35.

AI STRATEGY & USE -CASE PRIORITISATION · SECTION 5
Use-Case Priority
PLA N I LY'S A I USE CA SE S, RA NK E D BY VA LUE , CO ST , A ND RI SK
Use case
Value
Cost
Risk
Priority
School-email parsing into events/tasks
Very high
Low-medium
Medium
Very high
WhatsApp free-text task capture
Very high
Medium
Medium
Very high
Weekly 'what do I need to remember' digest
High
Low
Low-medium
High
Calendar-sync suggestions with confirmation
High
Low
Medium
High
Payment/consent/deadline extraction w/ confirmation
High
Low-medium
High
High
Geolocation-aware reminders
Medium
Medium
Very high
Low for now
Fully autonomous task assignment (no confirmation)
Medium
Medium
Very high
Defer
Parsing, summarising and confirming come first, deliberately. A fully autonomous 'agent' is not recommended during or right after pilot launch — the value of AI right now is cutting
manual work, not cutting human oversight.
AI Strategy & Use-Case Prioritisation | Planily
12

36.

AI STRATEGY & USE -CASE PRIORITISATION · SECTION 6
Roadmap
HOW THE AI STRATEGY PHASES IN OVER THREE YEARS, KEYED TO FAMILY -COUNT MILESTONES
1
Year 1
2
Pilot launch · ~50–100 families
Year 2
Growth · ~100–500 families
Stay entirely on the third-party API
Introduce a fine-tuned small model
Flash-Lite for routine extraction &
classification
(Phi-4-mini or Ministral 3B) via managed
inference
Default to Batch pricing where reply isn't
instant
Flash 3.5 kept in reserve for ambiguous cases
No self-hosting infrastructure work begins
3
Sits inside the Section 4.4 routing layer
Driven by quality & latency, not cost yet
Stay on managed service — infra stays light
Year 3
Scaling · ~500–1,000 families
Reassess the self-hosting trigger vs. real
growth
Heading past ~1,750–2,000 families → plan
infra
Tracking the planned 1,000 ceiling → stay
hybrid
No cost case for going further at that volume
Why this order: each phase is justified by data the previous phase produces — committing real infrastructure spend only once the numbers say it's worth it, not on a guess about where
Planily might be in three years.

37.

O N E L I N E TO L E AV E W I T H
Planily
organise
It gives doesn't
back thejust
mental
spacefamily
to livelife.
it.
P
pared b
y
AIr eStrategy
Consulting
Project · June 2026
All claims pending GDPR & Compliance Analyst sign-off before external publication.
SClient
o u r cbriefing
es
· Follow-up from Sachin Patel · planily.co.uk