Specs for apps that do not exist yet.

Why it has to be local

Every free PDF tool uploads your document to someone's server. The files people need this for are contracts, bank statements, medical letters and scanned passports — the precise documents you would not hand to a stranger. Doing the work in the browser is not a cost saving, it is the product, and it is provable: there is no network call for the app to make.

Where the real work is

Real page-tree manipulation with pdf-lib: reordering and extracting pages, rotating, merging documents while preserving metadata, and re-encoding images to shrink a file. Not a wrapper around someone else's API.

What it does

• Merge several PDFs, with drag-to-reorder before you commit
• Split by page range, by every N pages, or extract a selection
• Rotate, delete and reorder pages with visual thumbnails
• Compress by re-encoding embedded images, with before-and-after sizes shown
• Batch mode: apply the same operation across several files
• A running list of what you have done in this session, so a wrong step is undoable

What it must not do

• Nothing is uploaded, and nothing is stored between sessions unless the user asks
• No OCR and no cloud conversion — both need a server, and pretending otherwise would be the fake claim this catalog exists to avoid
• Large files must degrade honestly with a size warning rather than freezing the tab

Shape of the data

• LoadedFile — name, byte size, page count, the raw bytes held in memory only
• Operation — the kind, its parameters, and which file it applies to
• No persistence by default: a document toolkit that quietly kept your bank statements would be its own kind of betrayal

Honest difficulty

The heaviest dependency of any app in the catalog, and browser memory is the real limit — a 200MB scanned PDF will not behave. The fix is to say so before the user finds out.

What people search for

merge pdfsplit pdf freecompress pdf without uploadingpdf tools offline

Why it has to be local

This is the strongest privacy argument in consumer software, and it is not close. Since 2022 the question of where this particular data lives stopped being abstract for a lot of people. Every mainstream tracker is a data business with a health app attached. An app with no account and no server has nothing to sell, nothing to leak, and nothing to disclose when asked.

Where the real work is

Cycle length and variability from the actual log, phase estimation, and prediction stated with a range rather than a false point estimate. The honest version reports its own uncertainty: six cycles of data supports a different confidence to two.

What it does

• Log periods, flow, symptoms and notes in a few taps
• Predicted next start shown as a range, with the confidence the data actually supports
• Cycle length history and variability, because the pattern matters more than any one month
• Full export, and a delete-everything that genuinely deletes
• Works entirely offline once installed

What it must not do

• Not a contraceptive, not a fertility tool, and it must never present itself as either
• No diagnosis, no medical claims, no interpretation of symptoms
• No account, no sync, no analytics, no crash reporting — the whole argument collapses the moment any one of those arrives
• Prediction must show uncertainty rather than a confident single date

Shape of the data

• Cycle — start date, end date, and flow observations
• Entry — date, symptoms, notes
• Settings — average cycle length override, prediction on or off

Honest difficulty

The framing carries more weight than the code. Getting the tone wrong, or letting an agent later add 'helpful' cloud backup, would be worse than not building it. The agent instructions need to be unusually firm.

What people search for

period tracker no accountprivate period tracker offlineperiod tracker that doesn't sell dataopen source cycle tracking

Why it has to be local

Hospitality, nursing, retail and security run on spreadsheets nobody can read or on SaaS that charges per head per month. The fairness constraints are the actual product, and they are exactly what a spreadsheet cannot show you: who has had the last three weekends, who is on their fifth consecutive day, where coverage silently drops to one person.

Where the real work is

Genuine constraint checking rather than a grid: coverage minimums per shift, consecutive-day limits, minimum rest between shifts, and a fairness score distributing unsociable hours across the team. The hardest arithmetic on this list and the most defensible.

What it does

• Week and month grid, staff down the side, days across
• Coverage warnings when a shift drops below its minimum
• Consecutive-day and minimum-rest violations flagged as you build
• Fairness view: weekends, nights and bank holidays per person across the period
• Availability and time-off marked per person and respected by the warnings
• Print and CSV export, because the rota still ends up on a wall

What it must not do

• It warns, it does not auto-generate. A rota an algorithm wrote and nobody understands is worse than a bad rota someone can defend
• No payroll, no clock-in, no surveillance features
• Local-first: a rota holds names, availability and sometimes the reason someone cannot work Tuesdays

Shape of the data

• Person — name, contracted hours, availability, colour
• ShiftType — name, start, end, minimum staff
• Assignment — person, date, shift type
• Rules — max consecutive days, minimum rest hours, weekend fairness target

Honest difficulty

Scope creep towards auto-scheduling is the danger, and it is where the build stops being finishable. Warnings first; solver never.

What people search for

shift schedule templaterota planner freestaff scheduling app small businessemployee rota software open source

Why it has to be local

The answer is usually startling — years off the term and a five-figure interest saving — and every bank's calculator asks who you are before it will tell you. This one runs the schedule in the browser and shows the arithmetic rather than a lead-capture form.

Where the real work is

A full month-by-month amortisation, run twice: your current schedule and the overpayment scenario, compared. Handles regular overpayments, one-off lump sums, and a rate change when a fixed term ends — which is the case most calculators quietly ignore and the one that matters most.

What it does

• Balance, rate, term in; monthly payment and total interest out
• Overpayment scenario side by side: months saved, interest saved, new payoff date
• One-off lump sums at any point in the schedule
• Rate change at the end of a fixed period, with the payment shock shown
• The amortisation table itself, because the number is more convincing with the schedule under it
• Annual overpayment cap warning — most lenders limit you to 10% a year

What it must not do

• A modelling tool, not advice. It cannot know about early repayment charges, offset accounts, or whether the money is better in a pension
• No lead capture, no email gate, no broker referral
• Currency and rounding stated plainly, since compounding conventions differ by lender

Shape of the data

• Mortgage — balance, annual rate, remaining term, payment
• Overpayment — amount, frequency, start month
• LumpSum — amount and month
• RateChange — month and new rate

Honest difficulty

Low technically. The care needed is in the disclaimer: the moment it looks like it is recommending overpaying rather than modelling it, it is the wrong app.

What people search for

mortgage overpayment calculatorpay off mortgage early calculatorextra payment mortgage calculatormortgage overpayment vs savings

Why it has to be local

The good tools in this space gate saving behind an account, which is an odd thing to require for a diagram of a database that does not exist yet. Developers link to tools like this, and that is worth more than the raw search volume.

Where the real work is

Real DDL generation for Postgres, MySQL and SQLite from the visual model, plus static analysis of the schema: foreign keys with no index, nullable columns in a composite key, missing primary keys, and many-to-many joins with no unique constraint.

What it does

• Tables, columns, types, and relations laid out visually
• Generated SQL DDL, switchable between Postgres, MySQL and SQLite
• Schema warnings: unindexed foreign keys, missing primary keys, unconstrained joins
• Import an existing schema by pasting CREATE TABLE statements
• Export as SQL, as JSON, or as a printable diagram

What it must not do

• It never connects to a database. Generating SQL is safe; running it against someone's production instance is a different product
• Warnings are advisory and say why, rather than refusing to generate
• Paste-to-import must fail gracefully — a partial parse beats a blank screen

Shape of the data

• Schema — name and dialect
• Table — name, position on the canvas, columns
• Column — name, type, nullability, default, key flags
• Relation — from column, to column, cardinality

Honest difficulty

The canvas is the build cost. A simple auto-layout with drag-to-adjust is enough; a full graph layout engine is where a weekend becomes a month.

What people search for

database schema design tooldbdiagram alternative open sourceER diagram to SQLfree database designer no account

Why it has to be local

Mint and everything after it needs your online banking login, which means handing a third party the keys to your account and trusting an aggregator you did not choose. Every bank on earth exports CSV. That file is a thing you already have, and it is enough.

Where the real work is

A rules engine that learns: categorise a merchant once and every past and future line matching it follows, with the rule visible and editable rather than a black box. Plus recurring-charge detection by finding similar amounts at regular intervals — which is how you discover the subscription you forgot in 2023.

What it does

• Import CSV from any bank, with a column mapper for the ones that disagree about date formats
• Rules that match on merchant text and apply retroactively
• Recurring charge detection: same-ish amount, regular interval, flagged with confidence
• Monthly and category breakdowns from your real history rather than a projection
• Export the categorised data back out, so it can feed Budget Planner

What it must not do

• No bank connections, no Open Banking, no credential entry of any kind
• The column mapper must handle a badly formed CSV without losing rows silently
• Categorisation is always attributable: every transaction can say which rule put it there

Shape of the data

• Import — source name, column mapping, row count
• Transaction — date, description, amount, category, the rule that assigned it
• Rule — match text, category, created date
• Recurring — merchant, cadence, typical amount, confidence

Honest difficulty

CSV variance between banks is the whole difficulty. The mapper needs to be genuinely good, and the seed data should include two deliberately awkward formats.

What people search for

bank statement csv categorisercategorise transactions spreadsheetbudget app without bank loginfind recurring subscriptions in bank statement

Why it has to be local

Most mood apps offer a slider and a streak. The thought record is an actual clinical format with a structure that does the work — situation, automatic thought, evidence for, evidence against, the distortion named, the reframe. What people write in one is the most private text they will produce all week, which makes the absence of a server the entire point.

Where the real work is

Less arithmetic than the others, and more structure: guided steps that will not let you skip the evidence-against section, a named list of common distortions to choose from, and belief ratings before and after so the change is visible. Patterns over time surface which distortions recur.

What it does

• Guided record: situation, feeling and intensity, automatic thought, evidence both ways, reframe
• Belief rating before and after, so the shift is a number you can see
• The standard distortion list, chosen rather than typed
• History showing which distortions recur most
• Export and delete-everything, both obvious rather than buried

What it must not do

• Not therapy, not a diagnosis, and it must say so plainly rather than in a footer
• A visible route to real help, shown always rather than triggered by keyword detection — keyword scanning of private text is exactly what this app exists not to do
• No streaks, no gamification, no notifications nagging someone to record distress on schedule
• No account, no sync, no analytics

Shape of the data

• Record — date, situation, emotion and intensity, automatic thought, belief before and after
• Evidence — for or against, text
• Distortion — the named pattern selected

Honest difficulty

The most care of anything here. The format is well established and free to use, but the tone has to be right and the app must never imply it is a substitute for treatment.

What people search for

cbt thought record templatethought diary app privatecognitive distortion worksheetfree cbt worksheet app

Why it has to be local

It is the standard advice after every burglary and every flood, and the tools for it are grim enough that almost nobody follows it. A full inventory of what you own, with values and serial numbers, is also a list you would rather not upload anywhere.

Where the real work is

Replacement-value totals by room and by category, checked against your policy's contents limit so the gap is a number rather than a feeling. Single-item limits flagged too — most policies cap any one item well below what a bike or a laptop costs.

What it does

• Room by room, with categories and a running total per room
• Purchase price, replacement value, serial numbers and purchase dates
• Cover gap: total replacement value against your policy limit
• Single-item limit warnings for anything above the policy's per-item cap
• A printable schedule formatted for a claim, plus CSV export
• Photo notes per item, stored locally

What it must not do

• Photographs never leave the device, which is the reason to use this rather than a spreadsheet in cloud storage
• No valuation service and no price lookups — the user sets replacement values
• The printed schedule must be plain enough for a loss adjuster to read

Shape of the data

• Room — name, order
• Item — room, name, category, purchase price, replacement value, serial, purchased date, notes
• Policy — contents limit, single-item limit, renewal date

Honest difficulty

Low. The design problem is data entry: an inventory nobody finishes is worthless, so the add-item path has to be fast and the app should reward a partial inventory rather than an empty one.

What people search for

home inventory list for insurancehome contents inventory templatebelongings inventory appinsurance inventory checklist

Why it has to be local

Every photo from a phone carries EXIF metadata, and that routinely includes the exact coordinates where it was taken. People post pictures of a new bike, a child's first day, a house for sale, and publish their home address alongside it without knowing. Online strippers require you to upload the very file whose location you were trying to protect, which is a strange bargain. Canvas does all of this in the tab.

Where the real work is

Real image work: canvas-based resampling with correct aspect handling, format conversion including WebP and AVIF, quality-targeted compression that reports the actual saving, and EXIF parsing that shows you what is in the file before offering to remove it. Seeing the GPS coordinates is what makes anyone care.

What it does

• Resize by dimension, percentage or target file size
• Convert between JPEG, PNG, WebP and AVIF
• EXIF inspector showing camera, timestamp and GPS before you strip it
• One-click strip of all metadata, or selective removal
• Batch mode across a folder of images, with a before-and-after size total
• Everything downloads back out; nothing is kept

What it must not do

• No uploads, no cloud conversion, no 'optimise with AI' that means send it somewhere
• The EXIF view must show what is actually there rather than a reassuring summary
• Stripping must be genuine — re-encoding through canvas drops metadata, and the app should verify rather than assume

Shape of the data

• LoadedImage — name, dimensions, byte size, parsed EXIF, bytes in memory only
• Preset — a named set of resize and format options for repeat work
• No persistence of image data, ever — only presets are remembered

Honest difficulty

Format support varies by browser: AVIF encoding is not universal and HEIC decoding mostly is not available at all. The honest move is to detect and say so rather than fail quietly on someone's holiday photos.

What people search for

resize image without uploadingremove exif data from photoconvert heic to jpg offlinecompress image privately

Why it has to be local

Sleep tracking is dominated by wearables that infer stages from a wrist and present it with unearned confidence. The diary used in cognitive behavioural therapy for insomnia is a paper form, and it works: what time you went to bed, when you think you fell asleep, how long you were awake in the night, when you got up. It is deeply personal data about a bad time in someone's life, and it belongs on their own device.

Where the real work is

Sleep efficiency — time asleep divided by time in bed — which is the number CBT-I is built around and almost no consumer app shows. Plus rolling two-week averages, sleep-onset latency, wake-after-sleep-onset, and the correlation between the things you logged and the nights that went badly.

What it does

• Morning entry in under a minute: to bed, asleep, awakenings, up, quality
• Sleep efficiency per night and averaged across the rolling fortnight
• Optional factors — caffeine, alcohol, exercise, screens — logged and correlated
• A printable two-week diary in the format a sleep clinic expects
• No wearable, no inference, no sleep-stage theatre

What it must not do

• Not a diagnosis and not a treatment. CBT-I is delivered by a clinician; this is the diary that supports it
• No sleep staging, because a phone by the bed cannot know and pretending is the whole problem with this category
• No streaks and no scores — telling an insomniac they have failed a target is actively harmful

Shape of the data

• Night — date, bedtime, estimated sleep onset, awakenings and their duration, rise time, quality rating
• Factor — the optional daily inputs being tracked
• Derived — efficiency, latency, total sleep time, all computed rather than stored

Honest difficulty

Low technically. The discipline is in refusing the features people expect: the absence of a sleep score is the point, and it needs explaining on the page rather than defending later.

What people search for

sleep diary template pdfsleep efficiency calculatorcbt-i sleep log apptwo week sleep diary for doctor

Why it has to be local

The incumbent wants everyone in the group to make an account, and then advertises at them. The maths does not need a server or a signup: one person keeps the ledger, and the result is a short list of payments that anybody can check. Sharing happens by sending the summary, not by recruiting five friends to a platform.

Where the real work is

Debt simplification, which is the genuinely interesting part: naively, eight people who each paid for something owe up to fifty-six transfers between them. Netting every balance and then greedily matching the largest creditor to the largest debtor collapses that to at most seven. Plus unequal shares, so the couple sharing a room pays two parts and the person who skipped dinner pays none.

What it does

• People, expenses, and who each expense was for
• Unequal shares — by parts, by percentage, or exact amounts
• Settlement plan reduced to the fewest transfers, with the arithmetic shown
• Multiple currencies with a rate you set, since the app does not phone a rate service
• Shareable plain-text or CSV summary, so nobody has to install anything
• Separate ledgers per trip or per household, archived when settled

What it must not do

• No accounts for participants — one keeper, a shared summary
• No payment integration. Telling you who to pay is useful; moving money is a different product with a different risk profile
• Exchange rates are entered by the user and stamped with the date they used

Shape of the data

• Ledger — name, currency, participants
• Person — name, share weight
• Expense — payer, amount, description, date, who it covers and in what proportion
• Settlement — computed, never stored, so it cannot drift from the expenses

Honest difficulty

The settlement algorithm is easy to get subtly wrong with rounding — pennies must land somewhere deliberate rather than evaporating. Worth a test suite, which would make it the second app in the catalog to ship one.

What people search for

split expenses group tripwho owes who calculatorsplitwise alternative no accountshared house bills calculator

Why it has to be local

Claiming mileage requires a contemporaneous record — date, route, purpose, distance — and the tools are either an app that tracks your location continuously or a notebook in the glovebox. Continuous location tracking to claim forty pence a mile is a poor trade, and the notebook never gets typed up.

Where the real work is

Rate-band arithmetic that the flat calculators miss: most tax authorities pay a higher rate for the first tranche of business miles each year and a lower one after, so the claim is not distance times a single number. Running totals against the band threshold, split by vehicle, with the year-to-date claim always visible.

What it does

• Log a journey in seconds: date, from, to, purpose, miles
• Round trips, and repeat-last-journey for the commute you make weekly
• Business and personal split per vehicle, with the personal ones excluded from the claim
• Rate bands applied automatically, with the threshold crossing shown
• Year-to-date claim and a printable log formatted for a return
• CSV export for an accountant

What it must not do

• No GPS and no background tracking. The record is what you enter, which is also what the tax authority asks for
• Rates are user-editable data, not hardcoded — they change annually and vary by country, and a stale hardcoded rate is a wrong claim
• Not tax advice, and it must not imply the claim will be accepted

Shape of the data

• Vehicle — name, registration, rate scheme
• Journey — date, from, to, purpose, miles, business or personal
• RateScheme — bands, thresholds, effective dates, editable because rates change

Honest difficulty

The rate schemes are the maintenance burden. Shipping them as editable seed data rather than logic is what stops the app going quietly out of date.

What people search for

mileage log template for taxeshmrc mileage claim calculatorirs mileage log appbusiness mileage tracker no gps

Why it has to be local

Every revision timetable app asks you to build the timetable, which is the hard part and the reason people put it off. Working backwards from a fixed date across the days actually available, spreading topics so each is seen more than once, is arithmetic — and it is arithmetic nobody does at eleven at night three weeks before an exam.

Where the real work is

Backward scheduling with spaced repetition built in: topics distributed across available sessions so each gets an initial pass and at least two revisits at widening intervals, weighted by how confident you say you are. Blackout dates respected. If the plan does not fit, it says which topics are at risk rather than silently compressing everything.

What it does

• Exam dates, subjects, topics, and a confidence rating per topic
• Available study slots per weekday, with blackout dates for the week you are away
• Generated plan spreading topics with revisits at widening intervals
• Honest infeasibility: when there is not enough time, it names what will not get covered
• Tick off sessions and watch the plan re-balance around what you actually did
• Printable week view, because the plan ends up on a wall

What it must not do

• It must re-plan around missed sessions rather than accumulating guilt-inducing overdue items
• No account, no leaderboard, no study-streak pressure aimed at teenagers
• The plan is a suggestion and editable by hand — an algorithm that cannot be overruled will be abandoned

Shape of the data

• Exam — subject, date
• Topic — subject, name, confidence, estimated sessions needed
• Availability — weekday, slots, blackout dates
• Session — date, topic, whether it is a first pass or a revisit, completed

Honest difficulty

The scheduling is the build. Keep it a deterministic pass rather than an optimiser, and make manual overrides first-class so the plan survives real life.

What people search for

revision timetable makerstudy schedule generator exam datespaced repetition revision plangcse revision planner free

Why it has to be local

Every projection tool belongs to someone who wants to manage your money, and each one hides its assumptions behind a friendly slider. The interesting question is not the headline number but which assumption it is resting on — and a tool that shows the working, in real terms, with no lead capture, is a different object entirely.

Where the real work is

Accumulation and drawdown in one model: contributions compounding to a retirement date, then withdrawals against a declining balance, all expressed in today's money so inflation is not quietly flattering the result. Sequence-of-returns sensitivity — the same average return arriving in a different order — which is the risk most calculators omit entirely and the one that actually ruins retirements.

What it does

• Current pot, monthly contribution, expected return, inflation, target retirement age
• Projection in today's money, with the nominal figure shown alongside so the difference is obvious
• Drawdown phase: what a given annual income does to the balance, and the year it runs out
• Sensitivity table — a point of return either way, two years of retiring later, higher inflation
• Bad-sequence scenario: identical average return, poor years first
• Every assumption on screen, editable, and shown on the printed summary

What it must not do

• A modelling tool, not advice. It cannot know about tax wrappers, state pension, guarantees, or anyone's circumstances, and must say so plainly rather than in small print
• No lead capture, no adviser referral, no product comparison
• It must never present a single number as a prediction — the range and the assumptions are the output

Shape of the data

• Plan — current balance, contribution, growth rate, inflation rate, current and retirement age
• Drawdown — annual income required, whether it rises with inflation
• Scenario — a named set of overrides for comparison

Honest difficulty

The framing carries the most weight of anything on this list. Done well it is the most useful calculator here; done carelessly it reads as advice, which it must never be.

What people search for

how much do i need to retire calculatorfire calculator ukpension drawdown projectionretirement calculator no email

Why it has to be local

Every café, takeaway, nursery kitchen and village hall is legally required to record fridge and freezer temperatures, cleaning schedules and delivery checks, and to produce them when an inspector walks in. The tools are a paper diary that gets coffee spilled on it or a subscription at thirty pounds a month. This is a compulsory audience rather than an interested one, which almost nothing else in the catalog can say.

Where the real work is

Which checks are overdue right now, computed from each schedule's own cadence rather than a single daily reminder. Out-of-range temperatures flagged with how long they stayed out, because duration is what determines whether food was at risk. And an allergen matrix derived per dish from its ingredients, so changing one recipe updates every dish it appears in — the thing that goes stale first when the matrix is typed by hand.

What it does

• Scheduled checks — fridges, freezers, hot holding, probe calibration, opening and closing
• Overdue view that leads with what is late rather than what is done
• Out-of-range readings flagged with duration and a corrective-action note
• Cleaning schedule by area and frequency, signed off per completion
• Delivery checks: supplier, temperature on arrival, accepted or rejected
• Allergen matrix built from ingredients, so one recipe change updates every dish
• Printable records for any date range, formatted for an inspection

What it must not do

• It is a record, not a certification. It cannot tell anyone their kitchen is compliant, only what was recorded and when
• No cloud sync by default: this is a business's own legal record, and losing it to an expired subscription is the failure mode it exists to avoid
• Never auto-fill a missed check. A record invented after the fact is worse than a gap, and an inspector treats it as worse
• Allergen data is user-entered and must never be inferred from an ingredient name

Shape of the data

• CheckType — name, cadence, acceptable range, who it applies to
• Reading — check type, timestamp, value, staff initials, corrective action
• CleaningTask — area, frequency, last completed, by whom
• Dish — name, ingredients; Ingredient — name, allergens present
• Delivery — supplier, date, temperature, accepted, notes

Honest difficulty

The temptation is to encode a specific jurisdiction's rules — HACCP, Natasha's Law, local authority variants — and be wrong somewhere. Ship the structure with editable schedules and ranges instead, and let the operator match it to whatever their own regime demands.

What people search for

food safety temperature log templatehaccp record sheet freefridge temperature log appallergen matrix template restaurant

Why it has to be local

Most employers are legally required to keep an accident book, and its entries contain injuries, medical detail and named individuals — often children, in a school or nursery. Handing that to a vendor with a retention policy nobody read is the wrong instinct, and in several jurisdictions the record must be kept for years and produced on request. Local, exportable, and outlasting any subscription is the correct architecture, not a compromise.

Where the real work is

Retention deadlines computed per entry from its own date, so the book knows what it must still hold and what may be destroyed. A separation between the full record and the anonymised summary that may be shared or posted. Pattern surfacing across entries — same location, same task, same time of day — because three similar entries is the signal an accident book exists to produce.

What it does

• Guided entry: who, when, where, what happened, what was done, who was told
• Injured person's details held separately from the shared summary, per data-protection practice
• Retention clock per entry, with what is due for destruction
• Patterns view: repeated locations, tasks or times across entries
• Printable individual reports and a redacted register
• Follow-up actions with owners and a closed date

What it must not do

• It must never assert that an incident is or is not officially reportable. It can flag that one may meet a threshold and point at the criteria; the judgement is a human's
• Personal details are excluded from any export unless explicitly included, and the app should say so at the moment of export rather than in a settings page
• No analytics, no cloud, no aggregate telemetry — an injury record is not product data
• Entries are append-only with corrections recorded as corrections; a record that can be quietly rewritten is not a record

Shape of the data

• Entry — date, time, location, description, immediate action, reporter
• Person — name, role, contact, held apart from the narrative and excluded from exports by default
• FollowUp — action, owner, due, completed
• RetentionRule — years to hold, editable per jurisdiction

Honest difficulty

Jurisdictional variation is the trap, exactly as with the food safety log. Encode the structure and the retention arithmetic; leave thresholds and categories as editable data.

What people search for

accident book template freeworkplace incident report formriddor record keepingschool accident record app

Why it has to be local

This one is not about privacy at all. There is no network on a building site — not in the basement, not in the stairwell, not on the fourth floor before the glazing goes in. A server-backed app is simply broken there, which is why site inspections still happen on printed sheets and get typed up in the evening. Local-first is the only architecture that works, and the incumbents charge per seat per month for something that fails at the exact moment it is needed.

Where the real work is

Grouping that produces the two documents the job actually needs: outstanding by trade, which is what gets handed to each contractor, and outstanding by unit, which is what gets handed to the client. Plus ageing — how long each defect has been open — because the argument at handover is always about what has been outstanding since when.

What it does

• Defects by unit and room, with photos taken on the spot
• Trade, priority, status, and who it was assigned to
• Works with no connection — everything is local until you export
• Reports by trade and by unit, dated and ready to send
• Ageing view: what has been open longest
• Sign-off per defect with a photo of the remedy

What it must not do

• Photos stay on the device until exported. A site photo can show a person, a plate, or a client's home
• No enforced sync, no seat licensing, no cloud requirement — the app must be fully useful for one person on one phone
• Exports must be self-contained documents, since the recipient is a contractor with an email address, not a user account

Shape of the data

• Project — name, units, rooms
• Defect — unit, room, description, trade, priority, status, raised date, photos
• Remedy — completed date, photo, signed off by
• Contractor — name, trade, contact

Honest difficulty

Photo storage is the real constraint: a hundred defects with three photos each will exhaust browser storage. Downscale on capture and say what the limit is rather than failing at defect ninety.

What people search for

snagging list templateconstruction defect tracking app offlinepunch list app freesite inspection report template

Why it has to be local

Everyone building with a language model does this in a spreadsheet, loses the spreadsheet, and ships the regression. The tools that exist are platform-shaped: an account, a hosted store, your prompts and your test data on someone else's infrastructure. The work is small and local — cases, versions, outputs, scores — and the only reason it usually is not is that nobody has made a decent local one. Notably, this is also the app the catalog's own audience would point at the catalog's own packages.

Where the real work is

The regression diff, which is the whole product: pin a prompt version as the baseline, run another, and see per-case which improved, which degraded and which are unchanged. Score aggregation across cases, and a pass rate that moves as versions change. Nothing clever, but nothing anybody keeps track of by hand either.

What it does

• Test cases: input, notes, and an expected shape or rubric
• Prompt versions with a note on what changed
• Paste-in mode with no key at all, or bring your own key to run cases directly
• Per-case scoring, manual or rubric-based, recorded against the version
• Regression view: improved, degraded, unchanged, since the pinned baseline
• Export the whole suite as JSON so it can live in a repository beside the code

What it must not do

• Works fully with no API key. Paste-in must be a first-class path, not a degraded one, or the demo cannot exist on this catalog at all
• No model provider is privileged and none is bundled — the key is the user's and the call goes from their machine
• It does not grade for you. An automatic scorer that nobody inspects is how a suite quietly stops meaning anything

Shape of the data

• Suite — name, description
• Case — input, notes, rubric or expected shape
• PromptVersion — body, created, change note
• Run — version, case, output, score, scored by, timestamp

Honest difficulty

The temptation is to become a platform: hosted runs, shared suites, a dashboard. Every one of those needs a server. Keeping it to a local file that exports as JSON is what makes it shippable here.

What people search for

prompt evaluation tool open sourcellm regression testing localprompt versioning and testingcompare prompt versions side by side

Why it has to be local

Postmortems decay into a paragraph of prose and a list of nobody's action items. The structure is what does the work — a timeline with timestamps, contributing factors separated from the trigger, and actions with an owner and a date — in the same way the CBT thought record's structure does. Incident records also contain candid internal detail, which is a reason to keep them where you control them rather than in whichever wiki the company is migrating away from this year.

Where the real work is

Time-to-detect and time-to-resolve derived from the timeline rather than typed, so they cannot flatter. Action items aggregated across incidents, which is where the pattern lives: the same contributing factor appearing in four postmortems is the finding, and nobody sees it from inside one document.

What it does

• Timeline entries with timestamps, building the narrative as you go
• Detection, mitigation and resolution marked on the timeline, with the durations computed
• Contributing factors kept separate from the trigger, because they are not the same thing
• Action items with owner, due date and status, tracked across incidents
• Recurring-factor view over the whole set
• A published summary distinct from the internal record

What it must not do

• No individual is a field. The format is blameless and the data model should make blame awkward to record rather than merely discouraged in the guidance
• Durations are computed from the timeline and not editable directly — a time-to-detect someone typed is a number with no evidence behind it
• The published summary excludes internal candour by default, and the app should show what is being dropped

Shape of the data

• Incident — title, severity, started, detected, mitigated, resolved
• TimelineEntry — timestamp, what happened, who observed it
• Factor — description, category, whether it was the trigger
• Action — description, owner, due, status, incident it came from

Honest difficulty

Low technically, and the value is entirely in the format. The design risk is adding severity scoring and SLA dashboards until it becomes the incident-management product it should not be.

What people search for

blameless postmortem templateincident report template engineeringroot cause analysis formatpostmortem action item tracker

Why it has to be local

Rotation is the oldest constraint problem in growing food: brassicas must not return to a bed within about four years or clubroot builds up, and the same holds for potatoes and blight, and alliums and white rot. Doing it by hand across six beds and four years is exactly the sort of bookkeeping people abandon by year two, which is when it starts mattering.

Where the real work is

Constraint checking across a grid of beds and years: no plant family within its own return interval, with a warning rather than a refusal when the plan breaks the rule, because a real garden has reasons. Suggests valid placements for a crop by finding beds whose history allows it, and shows each bed's family history at a glance.

What it does

• Beds by year, filled with plant families rather than individual varieties
• Return-interval warnings per family, with the interval editable
• Valid-placement suggestions for a crop you want to add
• Bed history at a glance — what grew there each year
• Green manure and fallow marked as legitimate occupants
• Printable plan for the shed wall

What it must not do

• Warns, never refuses. A gardener with a reason to break rotation should be able to record what they actually did
• No plant database fetched from anywhere — families and intervals ship as editable seed data
• Rotation only. Companion planting, spacing and yield estimates are a different, much larger app

Shape of the data

• Bed — name, size, notes
• PlantFamily — name, return interval in years, member crops
• Planting — bed, year, family, crop, notes
• Rule — family, minimum years before return, editable

Honest difficulty

Narrow audience, and the honest framing is that it pairs with the Planting Calendar rather than standing alone. Small build, satisfying maths, modest reach.

What people search for

crop rotation planner four yearvegetable bed rotation chartallotment planning tool freecompanion planting bed planner

Why it has to be local

Every child working towards a graded music exam carries a practice booklet that a parent signs and a teacher reads. It gets lost, and the apps that replace it are engagement products aimed at children, with accounts and streaks and notifications. A practice diary is a small, private thing between a pupil, a parent and a teacher.

Where the real work is

Distribution across pieces, which is the number a teacher actually wants: not total minutes, but whether the hard piece got any of them. Weeks to exam counted down against pieces not yet secure, and time split between scales, pieces and technical work.

What it does

• Log a session in seconds: piece, minutes, and how it went
• Distribution by piece, so avoidance is visible
• Teacher notes per lesson, carried into the next week's focus
• Exam countdown with pieces marked secure or not
• Scales and technical work tracked separately from repertoire
• Printable term summary for the teacher

What it must not do

• No streaks, no badges, no notifications. This is used by children and the app should not be trying to manufacture compulsion in one
• No account for the pupil, the parent or the teacher — sharing is a printed or exported summary
• Minutes are self-reported and the app should not pretend to verify them

Shape of the data

• Piece — title, composer, status, exam or repertoire
• Session — date, piece, minutes, how it went, notes
• Lesson — date, teacher notes, focus for the week
• Exam — grade, date, pieces required

Honest difficulty

Small in scope and small in reach, but it replaces a physical object that hundreds of thousands of children are handed every year, and the alternatives are worse than paper.

What people search for

music practice log templatepractice diary app for kidsabrsm practice chartpiano practice tracker printable

Why it has to be local

Divers keep a log because certification and some sites require it, and because it is the record of where they have been. They also spend their days on boats and shorelines with no connection, which makes a server-backed app useless at exactly the moment of entry. The paper logbook persists for good reasons; a local app that prints to the same format is the honest replacement.

Where the real work is

Surface interval between consecutive dives, computed from the times entered, and running totals that certifications ask for — dives logged, hours under, deepest, by site and by year. Kit configuration carried forward from the last dive, since it rarely changes and re-entering it is why logs go unfilled.

What it does

• Dive entry: site, date, in and out times, max depth, conditions, buddy
• Surface interval computed between consecutive dives
• Kit and weighting carried forward from the previous dive
• Totals by year, site and depth for certification requirements
• Notes and sightings per dive
• Printable pages matching the traditional logbook layout, with space for a signature

What it must not do

• A log, never a planner. It records what happened and must never compute no-decompression limits, ascent rates or repetitive dive groups — that is a dive computer's job and getting it wrong hurts someone
• Surface interval is arithmetic on entered times and is presented as exactly that, not as a safety clearance
• No cloud, and no requirement for one; the boat has no signal and the app must be complete without it

Shape of the data

• Dive — site, date, times, depths, conditions, buddy, notes
• Site — name, location, typical conditions
• Kit — cylinder, suit, weight, carried forward
• Certification — level, date, agency

Honest difficulty

The safety boundary is the whole design constraint, and it must be stated on the page rather than buried. An agent asked to 'add dive planning' should find that refusal written down in the agent instructions.

What people search for

dive log book app offlinescuba dive log templatepadi logbook replacementdive log with signature