VaultBook vs Bear for Tax Preparers: A Private Client Vault for Tax Season

Every tax practice has two archives, whether it admits it or not. The first is the official one: filed returns, signed engagement letters, the documents the firm can produce on demand. The second is the working archive, and it is where the season is actually won or lost. It holds the per-client checklist with three items still missing, the note that a spouse answers email from a different address, the portal login that only one person in the office knows, the photograph of a paper form a client sent sideways, and the reminder that one family’s return cannot be finished until a brokerage statement arrives in mid-March. That second archive is sensitive, deadline-driven, and scattered by default. The question this article answers is simple: which notes tool should hold it — Bear, the polished Markdown app for Mac, iPhone and iPad, or VaultBook, the single-file, offline, encrypted vault built for exactly this kind of high-stakes record keeping?

The short answer is that these two products are not really rivals for the same job, and pretending otherwise would be unfair to both. Bear is one of the best writing environments ever made for Apple hardware. If your notes are your own thinking — drafts, journals, research, meeting notes for one person — Bear is hard to beat and this article will say so plainly, more than once. But a tax preparer’s working archive is not personal thinking. It is other people’s most sensitive financial information, attached to hard statutory deadlines, spread across PDFs, photographs, spreadsheets and portal credentials, and it has to be findable in seconds while a client is on the phone. Judged on that job, the comparison is not close, and the reasons are structural rather than cosmetic: platform reach, where the data lives, what happens to files that are not text, and whether the tool itself knows what a deadline is.

This comparison is grounded in two kinds of evidence. The first is the products themselves: every claim about Bear in this article was checked against Bear’s own site and Pro page on the day of writing, and every VaultBook feature named here comes from the product’s documented feature set. The second is what practitioners actually talk about. Discussions among Bear users in the app’s own community, and among tax professionals in theirs, return to the same themes again and again: Apple-only access becoming a problem the day work introduces a Windows machine, iCloud-only sync failing at the worst moment, nested tags collapsing under their own weight at scale, documents arriving from clients in the wrong year, the wrong format, or as a crooked phone photo, and the endless, season-defining labour of chasing the one missing form. Those themes shape the scenario that runs through this article, because a comparison that ignores how the work actually feels is just a feature table with better manners.

The Scenario: A Solo Preparer, Three Hundred Clients, One Working Archive

Consider a composite preparer — call her Mara — assembled from the situations tax professionals describe most often in their own forums. She runs a small practice: herself, one part-time administrator during the season, roughly three hundred returning clients, a mix of wage earners, landlords, gig workers, and a few dozen small businesses whose bookkeeping ranges from tidy to shoebox. She is good at tax. What consumes her February is not tax. It is custody: knowing, for every client, exactly what has been requested, what has arrived, what has been reviewed, and what is still missing — and being able to prove it without digging through four inboxes, a paper notebook, and her own memory.

Mara’s tools grew the way most small practices grow, by accretion. Client notes live partly in her tax software’s comment fields, partly in a Word template rolled forward from last year, partly in email threads, and partly in a notebook app she loves — Bear — because writing in it is genuinely pleasant. Permanent facts about a client, the kind that must survive from year to year, sit in the same places as this year’s working notes, with nothing to separate them except her discipline. A client’s date of birth might be in a three-year-old email. A bank login for a client’s accounting portal might be in a note she encrypted on her phone and cannot open on the Windows machine the office uses for e-file review, because Bear does not run on Windows at all.

Nothing about this is carelessness. It is the normal result of tools that were each chosen for a local reason and never designed to be a system of record for other people’s secrets. The breaking point, in the stories preparers tell, is rarely dramatic. It is a Tuesday in March when a client calls and asks what is still outstanding, and answering takes eleven minutes of searching; or the afternoon a sync conflict leaves the newest version of a checklist on a phone that is in another building; or the discovery, during a security review for her written information security plan, that client identity documents have been travelling through ordinary email because there was never a better place to put the notes attached to them. Mara does not need a prettier editor. She needs a vault: one place, structured per client, that treats documents, deadlines, credentials and notes as one record — and that never sends any of it to a server she does not control.

That is the job description this article tests both apps against. Bear gets tested fairly, on its real strengths. VaultBook gets tested on whether its very different architecture — one HTML file, no account, no network requests, per-entry encryption, and a set of built-in document tools most notes apps do not attempt — actually maps onto the daily reality of a tax practice, workflow by workflow, edge case by edge case.

What Bear Does Well, Said Plainly

Any honest comparison has to start here, because Bear’s strengths are real and they explain why so many professionals reach for it in the first place. Bear is a Markdown notes app for Mac, iPhone and iPad, and within that world it is superb. The editor is fast, calm and beautifully typeset. Markdown formatting appears as you type and then gets out of the way. Nested tags give notes a flexible structure without folder rigidity: a note can live under a client tag, a year tag and a status tag at once, which is genuinely elegant for personal knowledge. Backlinks and wiki-style links connect notes into a small private wiki. Sketches, photos, tables and to-do lists can live inside a note. For a writer, a researcher, or any professional organising their own thinking on Apple devices, Bear sets a standard most competitors still chase.

Bear’s privacy posture, for a cloud-synced app, is also better than most. Its makers state that your notes are between you and iCloud and that they cannot see them, and the app supports Apple’s Advanced Data Protection. Individual notes can be encrypted with a password, and Bear itself can be locked behind Face ID or Touch ID. Search is quick, and for Pro subscribers it extends inside photos and PDFs. Export is broad: Markdown and plain text on the free tier, with PDF, HTML, DOCX and JPG among the formats a subscription adds. If the whole of your working life happens on Apple hardware, and your notes are yours alone, there is a reason Bear inspires loyalty that borders on affection.

The pricing is modest, too, and this article will not pretend otherwise. Bear is free to write in on a single device. Bear Pro, checked on Bear’s own Pro page on the day this article was written, costs $2.99 a month or $29.99 a year, with a seven-day free trial, and one subscription covers every device signed into the same Apple ID. What Pro unlocks matters for this comparison, so it is worth listing exactly: iCloud sync across devices, the ability to encrypt individual notes and lock the app, the advanced export formats, OCR search inside PDFs and images, and the full set of themes. In other words, the capabilities a professional most needs — sync, encryption, export, search inside documents — are precisely the ones behind the subscription. That is a legitimate business model and $29.99 a year is not extortionate. But it establishes the shape of the tool: Bear is a personal writing app whose professional features are rented extras, inside one company’s ecosystem, synced through one company’s cloud. Everything that follows flows from that shape.

Where Bear Stops Scaling for Client Work

The limits that matter for a tax practice are not bugs. They are consequences of Bear’s design choices, and Bear’s own community discusses them openly and repeatedly. Four of them decide this comparison on their own.

The first is platform reach. Bear runs on Mac, iPhone and iPad — and nowhere else. There is no Windows app, no Android app, and no web version. For an individual who is all-Apple by choice, that is a preference. For a practice, it is a structural risk. The moment a second machine enters the workflow — the Windows PC that runs a particular e-file or bookkeeping package, a seasonal hire’s laptop, a client’s machine during an on-site visit, an employer’s managed device — the working archive simply is not there. Community discussions about leaving Bear return to this trigger constantly: a job change to a Windows environment, a phone switch to Android, an IT policy that will not allow personal iCloud tooling on a managed network, or the plain need to open a note in a browser. A system of record that vanishes on the wrong operating system is not a system of record.

The second limit is that sync means iCloud, only iCloud, and only with Pro. There is no alternative sync provider, no self-hosted option, and no local-network fallback. Users in Bear’s community describe the familiar symptoms: notes stuck updating between Mac and phone, sync stalled on corporate or otherwise managed networks where iCloud is blocked or throttled, and dependence on an iCloud storage plan as the archive grows. For personal notes, a sync delay is an annoyance. For a checklist that two people update during filing season, it is how a client gets told the wrong thing. And because the notes live in iCloud, the practice’s most sensitive working records inherit the security posture of a personal Apple account — its password habits, its recovery settings, its exposure — rather than living under the firm’s own control, on the firm’s own media, under the firm’s own written security plan.

The third limit is organisation at scale. Bear’s nested tags are delightful at fifty notes and genuinely clever at five hundred. At the scale of a practice — three hundred clients, each with permanent records, several years of working notes, checklists, correspondence summaries and document logs — tag discipline becomes the system, and discipline is exactly what filing season erodes. Bear users themselves describe the pattern: hierarchies that start tidy and become overgrown, new notes that never get the second tag the scheme requires, pinned items that are hard to surface within one tag, sidebars that turn into scrolls, and reorganisations that are painful to perform from a phone. The recurring wish in those threads is telling: folders for the durable structure, with tags as a cross-cutting layer on top — which is, in effect, a request for the page-and-label architecture VaultBook starts from.

The fourth limit is the one preparers feel daily: Bear has no native concept of a deadline attached to a note, and its document handling is that of a writing app, not a document system. There are no due dates, no expiring items, no sidebar that answers the question “what needs attention this week” — users describe bolting a separate to-do app onto Bear and manually keeping the two in sync. Attachments exist, but importing, combining, splitting and cleaning up PDFs — the daily bread of client document work — is not Bear’s job; a crooked phone photo of a form is a picture in a note, not a searchable, indexed document. None of this makes Bear bad. It makes Bear a writing tool being asked to be a vault, a document manager and a deadline system at once. The rest of this article shows what happens when the tool was designed for those jobs from the start.

What a Client Vault Actually Has to Do

Before comparing workflows, it is worth writing down the job properly, because most notes-app comparisons fail by testing the wrong job. A tax practice’s working archive has to satisfy requirements that rarely appear in app reviews, and each one maps to a concrete failure that preparers describe in their own forums.

First, it must separate the permanent from the seasonal. Every client has a layer of facts that should never have to be re-collected and never casually edited: names and name changes, dates of birth, identity document references, dependents and how they change, bank details for refunds, entity structures, prior preparers, and the standing instructions a client gave once and expects to be remembered. Underneath that sits the current year’s working layer: the checklist, the open questions, the quirks of this year’s return. When the two layers share one undifferentiated pile of notes, rolling a client forward to a new year means copying a template and hoping nothing permanent was accidentally edited along the way — a pattern preparers describe doing in Word and Excel files year after year, with the errors compounding quietly.

Second, it must track items, not just store text. The unit of tax season is not the note; it is the outstanding item. For each client the practice needs to know, at item level, what was requested, what has been received, what has been reviewed, and what is still missing — the exact form, for the exact account, identified precisely enough that a follow-up message can name it. Preparers in professional forums describe building per-client checklists that identify a needed statement by partial account number precisely because a vague request produces the wrong document, last year’s document, or everything the client owns resent in one unsorted dump.

Third, it must absorb documents as they actually arrive. Clients send prior-year forms, wrong forms, screenshots, enormous mixed bundles of personal paperwork, and phone photographs of paper — sideways, cropped, shadowed. A vault that only handles tidy text forces a second, shadow workflow for documents, and the shadow workflow is where things get lost. The vault has to take the PDF, the photo and the spreadsheet in, make their contents searchable, and let the preparer merge, split and compress files without handing client documents to a random web service to do it.

Fourth, it must know time. Statutory deadlines, internal cutoff dates, extension decisions, expiring authorisations and review cycles are not calendar decorations; they are the practice’s risk surface. The tool has to surface what is due and what is expiring without being asked, offline, on a Monday morning in March.

Fifth, it must protect the crown jewels disproportionately. Portal credentials, identity numbers and bank details deserve stronger protection than a note about a client’s new dog — per-entry protection, not one posture for everything. And sixth, underlying all of it, the archive must remain under the practice’s physical control: no account whose suspension, price change, sync outage or security incident can take the working archive with it in the middle of the season. Hold those six requirements in mind. They are the test.

The Week the Cloud Held Everyone’s Secrets: What Northflank Means for a Small Practice

On 30 October 2026, the cloud application platform Northflank disclosed a security incident and told its customers to assume that every environment variable stored on the platform had been decrypted, and to disable and rotate all of their keys. Environment variables are where applications keep their secrets — database passwords, cloud credentials, authentication tokens and API keys. Northflank later confirmed that multiple customers had reported unauthorised use of AI API keys they had stored on the platform, and it advised anyone who had not yet rotated their stored secrets to do so immediately. The incident, reported by BleepingComputer on 31 October 2026, began with a threat alert from the security firm Wiz at 11:43 UTC on 30 October; Wiz’s wider reporting described a month in which at least nine AI developer platforms disclosed incidents, several involving attackers hunting precisely for stored credentials.

Northflank is a developer platform, not a tax tool, and this article is not going to pretend a tax preparer was its victim. The lesson transfers because the architecture transfers. A cloud service that stores many customers’ secrets in one place creates a single point of failure whose blast radius is everyone on the platform: one intrusion, and thousands of people who did nothing wrong spend their week rotating credentials and auditing bills. Every notes service that syncs through a provider’s servers shares a version of that shape. The provider may be careful, well-funded and honest — Northflank responded within minutes and communicated clearly — and the shape remains: your secrets are somewhere you cannot see, protected by decisions you did not make, reachable through accounts and infrastructure you do not control.

Now translate that to Mara’s practice. Her equivalent of environment variables is the encrypted note with client portal logins, the identity numbers on a permanent client page, the bank details on file for refunds. In a synced notes app, those items exist on a provider’s infrastructure in some form, under the protection of her personal account credentials. In VaultBook, they exist nowhere else at all. There is no VaultBook server. The application makes zero network requests; there is no account to breach, no control plane holding the secrets of every VaultBook user in one place, because no such place exists. A per-entry-encrypted client record on Mara’s own drive, protected by AES-256-GCM encryption derived from a password she controls, cannot be decrypted in bulk by an incident at a company — there is no bulk, and there is no company in the loop. That is not a claim that local files cannot be lost or stolen; laptops are stolen, and this article addresses backup and device encryption honestly later. It is the narrower, decisive point that an entire class of incident — the platform breach that turns one company’s bad week into every customer’s emergency — is designed out, not merely defended against. In the same week that Northflank’s customers were rotating every key they owned, a VaultBook practice had nothing to rotate, because nothing it owned was ever in the building that was entered.

Intake: The First Thirty Days of a Client Relationship

Intake is where the permanent layer is built, and it is where a vault earns or loses the next decade. Walk through Mara’s new-client intake in VaultBook, step by step, and notice how each step answers one of the requirements above.

A new client gets a page. In VaultBook’s terms, entries live inside a structured hierarchy — pages that act as durable containers, labels that cut across them, and sections inside each entry that separate kinds of content. Mara’s client page holds sections with jobs to do: Identity, with names, dates of birth and identity document references; Household, with dependents and their changes over time; Entities, for businesses, rentals and trusts; Standing Instructions, for the things the client said once — always claim the credit, never call before ten, the spouse handles documents — and Access, an encrypted section for portal credentials. Because the page is the container, the permanent layer has a home that is visibly separate from any single year’s work. Next year’s working entry links to the client page rather than copying it, so permanent facts are edited in exactly one place. The rolled-forward Word template, with its annual risk of editing last year’s copy of a fact instead of the fact itself, disappears.

Identity documents themselves are attached to the entry, not left in email. A driver’s licence scan, a prior-year return the client brought to the first meeting, the signed engagement letter: each is an attachment, indexed locally so its text is searchable later, including text inside scanned images and PDFs through built-in OCR. When a client emails a document anyway — they will — Mara saves it into the vault the same day and the email stops being the archive. The distinction preparers draw in their forums, between the governed record and the temporary material used to create it, becomes a habit the tool supports instead of a policy the tool undermines.

The Access section deserves its own paragraph, because it is where intake most often goes wrong in ordinary notes apps. Clients arrive with a tangle of logins: the payroll portal, the accounting package, the bank, the state tax account, the prior bookkeeper’s file share. In Bear, the sensible move is an encrypted note — available, but only with a Pro subscription, and protected note-by-note with friction each time it is opened on the go. In VaultBook, per-entry encryption is a core feature rather than a rented one: the Access entry is encrypted with AES-256-GCM, with the key derived from Mara’s password through PBKDF2 and the work done locally by the browser’s Web Crypto implementation. Nothing about that entry leaves the machine, in any form, ever. New credentials are generated with the built-in password generator rather than invented at the keyboard or reused from another client — a small feature that quietly removes one of the most common real-world weaknesses in small practices, the shared, memorable, reused password. And because VaultBook runs from a single HTML file in a browser, the same vault opens on the office Windows machine and on Mara’s Mac at home. Intake does not pause because the wrong laptop came home in the bag.

Finally, intake sets the year’s clock. The engagement’s key dates — the document cutoff in the engagement letter, the internal review date, the filing deadline, the date an authorisation expires — go onto the built-in calendar and onto entries as due and expiry dates from day one. Nothing here requires a second app, a sync account, or a subscription tier. The vault knows the client’s dates because the vault is where the client’s record lives.

The Checklist Is the Practice: Requested, Received, Reviewed, Missing

If intake builds the vault, the checklist runs the season. The single most consistent theme in tax professionals’ discussions of their workflow is the chase: the follow-ups, the drip-feed of documents arriving one at a time over weeks, the client who swears everything has been sent while one brokerage statement is still outstanding, the deadline that turns an incomplete file into an extension decision. Tools fail this work in a specific way — they store the checklist as prose, and prose cannot answer a question. Mara’s VaultBook checklist is built to be interrogated.

Each client’s year entry carries a checklist section in which every requested item is its own line with a state: requested, received, reviewed, or missing. The item names the document precisely — the form, the institution, and where it helps, a partial account identifier — because preparers have learned, and say so in their forums, that precision at request time is what prevents the wrong-year, wrong-account resubmission that wastes a week in March. When a client calls, the answer to “what do you still need from me?” is read off one section in seconds, not reconstructed from email searches. When the part-time administrator works a morning alone, the same section tells her exactly which follow-ups to send, in the client’s standing-instruction order, without asking Mara anything.

Kanban, which VaultBook includes as a built-in view, gives the practice its second lens. Individual client work moves across a board — awaiting documents, in preparation, in review, awaiting signature, filed, extended — and the board is not a separate project app with its own account and its own copy of client names; it is a view onto the same vault. The preparer who described wanting one checklist per client, one place for documents, and shared item-level status instead of email threads was describing, almost feature for feature, the combination of a checklist section, attachment indexing and a board over one local store. In Bear, the equivalent board does not exist; the checklist is a note with checkboxes, the status of the practice is a feeling, and the feeling, in mid-March, is unreliable.

Due dates turn the checklist from a record into an engine. Each open item can carry a due date, and VaultBook’s Recent, Due and Expiring sidebar — the left-hand control panel that surfaces what was touched lately, what is coming due, and what is about to expire — puts the practice’s week on one screen every time the vault opens. There is no separate reminder app to keep in agreement with the notes, which is the workaround Bear users describe and resent: two tools, two truths, and the manual labour of reconciling them. Here the reminder is the record. An item that is missing and due is visible because it is missing and due, in the same object, in the same file, offline, at 7 a.m. on a deadline Monday with the office internet down. That last condition matters more than app comparisons usually admit: filing season does not pause for outages, and a vault that makes zero network requests does not notice them.

Documents Arrive Wrong: Photos, Bundles and the Wrong Year

Ask preparers what actually lands in their inbox during the season and the answers, across many discussions, form a litany: the prior year’s form sent with total confidence; a bundle of forty unsorted pages mixing school forms, receipts and one crucial statement; a screenshot of a document instead of the document; and above all, the phone photograph — sideways, cropped, shadowed, taken on a kitchen table — of a paper form the client no longer has because it is now in a drawer under other paper. A notes app that treats these as pictures in a note leaves the preparer to be the indexing engine. VaultBook was built on the opposite assumption: that the vault’s job is to make whatever arrives findable, legible and combinable, locally.

Start with the photograph. Dropped into the client entry, it becomes an attachment, and VaultBook’s local OCR — running on the device, using Tesseract — extracts its text into the index. The sideways wage statement is now searchable by employer name and by the figures the OCR could read, months later, when the client insists it was never sent and Mara needs to find it while they are both on the phone. The Photo and Video Explorer, with its access to file metadata including EXIF data, gives the media pile a working view: what arrived, when the photo claims it was taken, and where it sits in the client’s record. None of this requires uploading a client’s identity-bearing documents to a transcription or OCR web service — an act that, in many small practices, happens casually today because the tools make it the path of least resistance, and that sits very uneasily beside the practice’s obligation to safeguard exactly this material.

The bundle problem is a PDF problem, and VaultBook answers it with a built-in PDF suite: merge, split and compress, inside the vault. The forty-page dump splits into its constituent documents, each filed to the right section of the client’s record; the three statements that belong together for a lender letter merge into one file; the enormous scan compresses before it is sent onward. The significance is not convenience alone. The consumer alternative — a free online PDF tool — asks the preparer to upload client financial documents to an unknown server, under unknown retention, for the privilege of splitting a file. Bear does not attempt this work at all; a Bear note can hold a PDF, and with Pro the text inside it becomes searchable, but the document itself cannot be taken apart or reassembled there. In a practice, document surgery is not an occasional edge case. It is Tuesday.

Then there is finding things, which is where the season’s minutes actually go. VaultBook’s search runs across titles, entry text, labels and attachments together, with attachment indexing reaching inside PDFs, documents, spreadsheets and images, and with a semantic question-and-answer layer that lets Mara ask the vault a question in plain language and be taken to the entries that answer it. The practical difference shows in the small moments: the client who mentions a charitable donation on the phone, the figure that must match a form received six weeks ago, the prior-year treatment of an unusual item that this year’s return must stay consistent with. In Bear, search is fast and, with Pro, reaches inside photos and PDFs too — credit where due — but it searches a library of notes organised by tags, in an app that exists only on the Apple devices in the room. In VaultBook, search is the front door to a structured client record, and it works on whichever machine is in front of her, with no network, no account, and no subscription deciding whether document search is switched on this month.

Deadlines Are the Risk Surface: Calendar, Due and Expiring

Every practice runs on two calendars: the statutory one, which is public and unforgiving, and the internal one — cutoff dates in engagement letters, review queues, extension decisions, expiring authorisations, the follow-up rhythm for slow clients — which is where the statutory calendar is actually survived. Bear has no native place for either. Its users, by their own account, pair it with a separate task or reminder app and accept the seam. VaultBook builds the seam away: a built-in calendar, due dates on entries, expiry dates on entries, and the sidebar that keeps all three in peripheral vision.

Watch how the season changes shape when the deadlines live inside the records they govern. In January, each client year’s entry carries its document cutoff as a due date. The Due view becomes the follow-up list, ordered by reality rather than by whose email happens to be open. Clients approaching cutoff with items still missing are not a discovery made on the cutoff date; they are a list Mara has watched for two weeks, with an extension conversation already drafted in the entry. Expiring items get their own discipline: the authorisation that lapses, the engagement that must be renewed, the record whose retention period ends and which should be reviewed for disposal rather than kept forever by inertia. Data minimisation — keeping sensitive material only as long as there is a need — stops being a paragraph in a policy document and becomes a queue the vault maintains by itself.

Extensions, which preparers describe as the pressure valve of the season, become a workflow rather than a scramble. A client whose brokerage statement will not exist until after the deadline moves, on the Kanban board, from awaiting documents to extended, with the reason and the client’s agreement recorded in the entry itself. The note, the checklist, the deadline and the status are one object. When the client phones in September, slightly hurt that their return was extended, the record of why is not in a departed administrator’s sent folder. It is in the vault, attached to the checklist that shows the item arriving three weeks after the internal cutoff, exactly as the engagement letter provided.

There is an honesty point to make here about what VaultBook’s calendar is not. It is not a shared, multi-user scheduling platform, and a practice that needs its appointments visible to a whole front office in real time will keep a practice calendar elsewhere. What VaultBook replaces is the private, record-bound layer — the deadlines that are really properties of client files — and for that layer, being inside the vault, offline, attached to the entry, beats being in a synced consumer app precisely because there is no sync to fail and no second source of truth to drift. Bear’s answer to the same layer is a to-do list inside a note, which is to say, prose again: visible, pleasant, and incapable of raising its hand when its date arrives.

Protecting the Crown Jewels: Per-Entry Encryption, Done Locally

Not everything in a client record deserves the same protection, and a tool that forces one posture on everything gets the trade-off wrong in both directions. Encrypt everything with heavy friction and the preparer stops encrypting; encrypt nothing but the app and one borrowed laptop becomes a practice-ending event. VaultBook’s model is per-entry encryption: the record that needs it gets it, at the strength the material warrants, while the grocery-list end of the vault stays quick to open.

The mechanics matter, and they are documented rather than mystical. An encrypted entry is protected with AES-256-GCM, an authenticated encryption standard, with the key derived from the entry’s password using PBKDF2, and the cryptographic work performed by the Web Crypto API in the browser, on the device. There are zero network requests: no key server, no account recovery flow at a provider, no telemetry. The password is Mara’s problem and Mara’s power — a provider cannot reset it for an attacker who talks a good game to a support desk, because there is no provider and no desk. Compare the Bear model fairly: Bear also offers per-note encryption, and it is a genuinely good feature — gated, however, behind the Pro subscription, and sitting inside an app whose library otherwise syncs to iCloud, where the protection of everything unencrypted depends on the Apple account’s posture and on whether Advanced Data Protection is enabled. VaultBook’s encryption is not a tier. It is the architecture.

Two companion features turn encryption from a lock into a system. Version history means that the permanent client page — the one object in the vault Mara most fears corrupting — carries its own past: a mistaken edit to a dependent’s details in March can be seen and undone in October, and the question of what the record said when a return was filed has an answer stronger than memory. And the private analytics sidebar gives the vault a quiet self-awareness — activity and patterns visible to Mara alone, on the device alone — that helps a solo practitioner notice the shape of her own season: which clients consume the follow-ups, where the hours pool, which part of the process is actually slow. Neither feature sounds like a headline. Both are the difference between a pile of protected notes and a managed record.

A word about the threat model, because vault marketing usually skips it. Per-entry encryption on a local file protects against platform breaches entirely, against casual access to a borrowed or stolen machine substantially, and against a determined attacker with the unlocked, running machine very little — no notes app changes that, and this article will not claim otherwise. The local model also makes Mara responsible for backups, which the migration section addresses directly. What the model removes is the entire category of risk that arrives by subscription: the provider incident, the account takeover at the provider, the sync of client secrets to a personal cloud under consumer terms, and the lapsed subscription quietly standing between a preparer and her own encrypted notes at the worst moment of the year. Preparers discussing subscriptions in their forums are rarely complaining about the money. They are complaining about dependence. A vault you own, in a file you hold, answers the dependence complaint at the root.

Working Across Machines Without Asking a Cloud for Permission

A practice’s hardware is never the tidy set an app vendor imagines. There is the good Mac on the preparer’s desk, the Windows machine that runs the e-file review package and an elderly printer, the laptop that goes to client sites, and — during the season — whatever machine a temporary administrator brings. Bear serves exactly one slice of that set. VaultBook, being a single HTML file that runs in a browser with data held in local files alongside it, serves all of it, identically, with no installation, no licence server and no account sign-in standing between the preparer and the record.

The mechanics deserve a plain explanation, because “single-file app” can sound like a toy until you watch it work. The entire application — entries, labels, wiki links and notes, search and OCR, the PDF tools, the calendar, the board, the encryption — is one self-contained HTML file of about one and a half megabytes. Open it in a browser and you are in the vault. There is nothing to install, which means there is nothing for a locked-down office machine to refuse, no administrator password to beg, and no version mismatch between the desk machine and the laptop: it is the same file. Your data lives in files you can see, copy and back up with ordinary tools, on media you own. Moving the vault is moving a folder. Handing it to your future self, your successor, or your executor is handing over a folder — a property whose value becomes vivid the first time a professional contemplates what happens to a synced consumer account, with its recovery emails and its terms of service, when its owner is hit by the proverbial bus.

This is also where VaultBook’s relationship with sync needs stating precisely, because it is the point critics of local-first tools press hardest. VaultBook does not sync, because sync is a network behaviour and VaultBook’s defining commitment is zero network requests. If Mara wants the vault on two machines, she copies the vault folder — on a schedule, to an encrypted drive, by whatever boring, auditable method her security plan already blesses for backups. That is less magical than iCloud’s invisible continuity, and this article will not pretend the magic has no value; Bear users who move between a Mac and an iPhone fifty times a day genuinely feel it. But notice what the magic costs in a practice context: the working archive exists wherever Apple’s sync has reached, under a personal account, including devices the firm’s plan may not know about, and its arrival on any machine waits on a network, a provider, and a subscription being in good standing. The folder copy is dumber and, for a system of record, better: its location is a fact Mara chose, can state in her security plan, and can verify by looking at the drive in her hand.

There is one more working-across-machines scenario that decides real seasons: the client-site visit. The landlord client with a filing cabinet and no scanner, the small business whose books live on a back-office PC, the elderly client whose documents are paper and whose kitchen table is the meeting room. A vault that opens from a file — on the client’s machine in a browser, or on Mara’s laptop with no connectivity in a building with none — keeps the record present where the work is. Photographs taken at the table go into the entry the same evening and are OCR-indexed by morning. A Bear library, by contrast, is present exactly where an Apple device with the right account happens to be, and absent — completely, not degraded — everywhere else.

Head to Head: The Two Tools Against the Six Requirements

Return now to the six requirements from earlier — permanent versus seasonal separation, item-level tracking, absorbing documents as they arrive, knowing time, disproportionate protection for the most sensitive entries, and physical control — and walk the comparison dimension by dimension, including the dimensions Bear wins.

On writing experience, Bear wins outright. Its editor is more beautiful, its typography finer, its Markdown handling more graceful. If the vault’s main content were long-form prose written for pleasure, this would matter enormously. In a client record, content is mostly short, structured and factual — checklists, notes of calls, figures, instructions — and VaultBook’s rich entries with sections are more than sufficient; but the point is conceded without grudging: Bear is the better place to write an essay, and VaultBook does not try to be.

On platform reach, the comparison is binary. Bear: Mac, iPhone, iPad. VaultBook: any machine with a browser, which is to say every machine a practice will ever own, borrow or be handed. On where data lives, Bear’s model is iCloud, with the strengths of Apple’s infrastructure and the dependencies described throughout this article; VaultBook’s model is local files, zero network requests, no account, no server-side copy in existence. On organisation, Bear offers nested tags — elegant, fluid, and, at practice scale, discipline-dependent in exactly the way its own users describe; VaultBook offers the layered structure preparers end up wishing for: pages as durable containers, labels cutting across them, sections inside entries, wiki links between records, related notes surfaced automatically, and dynamic tabs for keeping several clients’ files open side by side during a review session without losing your place in any of them.

On documents, the gap is widest. Bear holds attachments and, with Pro, searches inside images and PDFs. VaultBook indexes attachments of many kinds — PDFs, office documents, spreadsheets, email files, images — searches their contents with OCR where needed, merges, splits and compresses PDFs in place, explores photo and video collections with their metadata, and analyses whole folders of files for the clean-up work described later. On time, Bear offers to-do checkboxes; VaultBook offers a calendar, due and expiry dates, and the Recent, Due and Expiring sidebar. On protection, both offer per-item encryption, but Bear’s is a Pro feature inside a synced library, while VaultBook’s AES-256-GCM per-entry encryption is the architecture itself, with version history protecting the record’s past. On retrieval, both search well within their models; VaultBook adds semantic question answering over the vault and search that treats the attachment pile as first-class content rather than as passengers in notes.

On cost, honesty requires care. Bear Pro’s price is public and modest — $2.99 a month or $29.99 a year at the time of writing — and the free tier is genuinely usable for single-device writing. What the subscription buys, though, is not a luxury tier; for professional use, sync, encryption and document search are the product, which means the professional price of Bear is the subscription, forever, plus an iCloud storage plan as the archive grows, plus — the cost nobody invoices — the second tools the gaps require: the reminder app, the PDF service, the password tool, each with its own account. VaultBook’s pricing is published on its own site and this article sends you there for current figures rather than printing numbers that could age; the structural point, which does not age, is what the money buys: a file you hold, whose core protections are not a tier, and which cannot be switched off by a lapsed card in the first week of February. Preparers’ forums are full of a specific resentment — desktop tools they owned pushed into subscriptions they rent, prices rising, add-ons expiring mid-season. Whatever tool a practice chooses, it should choose with that resentment in mind, because the working archive is the last system a firm can afford to renegotiate under deadline pressure.

Migration: Moving a Bear Library into VaultBook in One Afternoon

Switching the working archive sounds like a project. In practice, done in the right order, it is an afternoon — and the order matters more than the effort. What follows is the sequence that works, written for Mara’s situation: a Bear library of client notes, a folder sprawl of documents, and a season that will not wait. VaultBook also ships an Obsidian import, and while Bear is not Obsidian, the principle generalises: get text out in an open format, get files into the vault as attachments, rebuild structure deliberately rather than importing chaos faithfully.

Step one is export, while Bear is still the live system. Bear exports notes to Markdown and plain text without a subscription, and to PDF, HTML, DOCX and JPG with Pro. For migration, Markdown is the right choice: it is the durable, tool-independent form of your own words. Export the client-related notes — and only those; a migration is the one legitimate chance to leave personal journals and reading notes in the personal app where they belong, which is itself an argument for this move: the client archive becomes a professional system, and Bear gets to go back to being a lovely place to think.

Step two is structure before content. Create the client pages first — one per active client, with the standard sections: Identity, Household, Entities, Standing Instructions, Access. Lay down the label scheme while the vault is empty and the decisions are cheap: a label per tax year, per service line, per status theme that genuinely cuts across clients. Resist importing Bear’s tag tree wholesale. Tag trees grown organically over years encode last year’s confusions as faithfully as last year’s insights, and the community wisdom from Bear’s own users is that large reorganisations are exactly the work that never gets done inside a living library. A migration is the reorganisation, done once, on purpose.

Step three is the permanent layer, client by client, and it is deliberately manual. For each client, read the old notes, and write the permanent facts into the client page in their proper sections — checking them as you go, because migration is also audit: the dependent who aged out, the bank that changed, the entity that dissolved. Attach the identity documents and the current engagement letter. Create the encrypted Access entry and, as each portal credential is moved, replace it with a generated password where the portal allows, retiring the reused passwords the old system quietly accumulated. Three hundred clients is a season of evenings if done comprehensively; done for the fifty most active clients first, it is a weekend, and the long tail can migrate as each client’s year begins — a rolling migration that touches every record exactly when it is about to matter.

Step four is the current year. Each active client’s year entry is created fresh in the vault, with its checklist section built from what is actually outstanding — not copied from a note that claims completeness — and its documents attached and indexed. Anything still living in email that belongs to the record is saved into the vault now; the email thread keeps existing, but it stops being the archive. Step five is the parallel week: run both systems for five working days, with VaultBook as the record you update and Bear as read-only reference, and note every time you reach for the old tool. Most reaches will be habit. The genuine gaps — there may be one or two — get a label, a section, or a calendar entry, because in a vault this configurable the answer to a gap is usually structure, not software. Step six is closing the loop: the Bear client tags are archived, the vault folder enters the practice’s backup routine that same day, and the security plan is updated to say, in one sentence, where the working archive lives. That sentence — impossible to write truthfully about a personal iCloud account — is the migration’s real deliverable.

Edge Cases: The Season’s Small Disasters, Handled

A vault proves itself not on the tidy path but on the dozen small disasters that make up a real season. Take them one at a time.

The spouse replies from another address. Email-thread filing breaks here, as preparers note in their forums: the document arrives in a thread the practice does not associate with the client, from a name that is not in the system. In the vault, the document’s home was never the thread; it is the client entry. Whoever sent it, it is filed once, indexed once, and the standing instruction — documents may come from either spouse — sits in the client page where a seasonal administrator will actually see it. The thread can be chaos. The record is not.

The client resends everything instead of the one missing item. A thirty-page bundle lands, containing, somewhere, the single corrected form. Split the PDF in the vault, keep the needed document, and let the checklist state — not a reply-all email — record what changed. Because attachments are indexed, the corrected form is findable by its contents next year when the question becomes what was actually filed from.

The client is a voice, not a typist. Some clients will only ever deal by phone. With consent, a recorded call can be attached to the entry and transcribed locally — VaultBook’s transcription runs on the device using Whisper, with an MP3 cutter and joiner for trimming the recording to the part that matters — so the substance of the conversation becomes searchable text in the record, and no client conversation is ever uploaded to a cloud transcription service to get there. The client who cannot use a portal, cannot scan, and cannot email a straight photograph is not an exception the system tolerates; with paper photographed at the kitchen-table visit and OCR doing the indexing, they are a workflow the system was built around.

The notice arrives in July. Season thinking says the vault matters from January to April; practice reality includes the summer letter from the tax authority about a return filed in March. The record that answers it — what was received, when, what the checklist showed, what the client confirmed — is the same vault, and version history plus the filed-year entry turns a stomach-drop moment into a retrieval exercise. Preparers keep records for years for exactly this reason; a vault whose whole design is durable, local and searchable is simply a better shape for a duty that long.

The laptop dies, or worse. Local-first means the practice owns its backup problem, and this article stated that debt openly rather than hiding it. The repayment schedule is boring by design: the vault folder copied to an encrypted external drive on a rhythm, a second copy off-site, and the whole arrangement written into the security plan and tested — actually tested, by opening the backup copy, before the season. Mara’s arrangement survives the death of any single machine, the failure of any single drive, and the disappearance of any single vendor, which is more than can be said for an archive whose existence depends on an account password, a provider’s uptime, and a subscription’s good standing simultaneously. Device encryption on the machines themselves, with the vault’s per-entry encryption protecting the most sensitive records even if a device is taken while locked, completes a posture a solo practitioner can genuinely maintain — which is the only kind of security posture that exists in the real world.

The seasonal hire leaves. Access in a vault model is physical and simple: the hire worked on the office machine, in the office vault; when the engagement ends, there is no shared account to offboard, no synced copy quietly living on a personal phone under a personal Apple ID, no subscription seat to revoke. The records the hire touched are in the vault’s history. For a small practice, offboarding that consists of a person walking out of a building — and the data staying in it — is not a minor convenience. It is the difference between a procedure and a hope.

Beyond April: The Vault at Work All Year

A tool justified only by filing season will be neglected by May, and a neglected archive is next January’s archaeology project. VaultBook earns its keep across the calendar, and the year-round uses are worth mapping because they are what keep the permanent layer alive and accurate.

Bookkeeping and payroll clients generate the steady drip: monthly documents, quarterly filings, the year-end bundle. The same per-client structure holds them, with due dates driving the rhythm and the board showing the month’s work at a glance. Estimated-tax clients get their payment dates and amounts in their entries, with due views surfacing each instalment before it is due rather than after a penalty letter. The File and Folder Analyzer — a built-in tool most notes apps would never think to include — comes into its own during the quiet months: point it at the accumulated sprawl of client folders on the office drive, the years of downloads and duplicates and mysteriously suffixed final versions, and audit what is actually there before deciding what migrates, what archives, and what should have been disposed of under the retention schedule long ago.

The Reader and the data-visualisation tools serve the advisory side of the practice. A client’s multi-year picture — income patterns, withholding drift, the rental property’s real story once repairs are separated from improvements — can be assembled from the vault’s own records, read in a clean reading view, and explored as data rather than as a pile of annual snapshots. When a client asks the genuinely valuable question — not “what do I owe” but “what should I do differently” — the preparer who can reach across years of structured, searchable record in one local system answers from evidence. The preparer whose archive is a tag tree in a personal app, interleaved with journals and reading notes, answers from impression. Clients can tell the difference, and they pay accordingly.

There is also the practice’s own knowledge to house: the position taken on an unusual issue and why, the state’s quirks learned the hard way, the checklist improvements each season teaches. In VaultBook this becomes a small private wiki — linked entries, related notes surfaced automatically, search that finds the reasoning when the issue recurs three years later for a different client. Institutional memory is the asset a solo practice is most at risk of losing, because it lives in one head and evaporates under exactly the time pressure when it is most needed. A vault that is open all year, for everything, is where that memory can actually accumulate.

Setting Up the Taxonomy: Pages, Labels and Sections That Survive Growth

Structure advice is cheap; structure that survives three hundred clients and five seasons is not. The taxonomy below is drawn from the failure modes preparers and heavy notes users describe — tag trees that metastasised, templates rolled forward until they lied, permanent facts buried in seasonal notes — and from the shape VaultBook’s pages, labels and sections naturally support.

Pages are the durable skeleton. One page per client, never per year; one page for the practice’s own procedures; one for reference material by topic. A page answers the question “whose record is this, permanently?” and the answer never changes, which is precisely why pages do not collapse under growth the way tag hierarchies do: adding client three hundred and one does not reorganise anything. Labels are the cross-cutting layer, kept deliberately few and deliberately boring: tax years, service lines, and a small set of status themes — needs documents, extended, notice received — that genuinely span clients. The rule that keeps labels healthy is that a label must change what you would do when you filter by it; a label that merely describes is decoration, and decoration at scale becomes the cluttered sidebar Bear users describe fighting. Sections live inside entries and carry the internal order: a year entry’s Checklist, Correspondence, Documents Received and Notes sections mean that anyone opening the record — Mara in March, an administrator in February, Mara again in a July notice response — finds the same anatomy in the same place, every time. Consistency of anatomy is what makes a record usable by more than one person and across more than one year; it is also what makes the vault’s search and question-answering sharper, because the system can find not just the client but the section where that kind of fact lives.

Two disciplines protect the taxonomy over time. The first is the annual roll-forward ritual: when a client’s new year entry is created, the permanent page is reviewed — not copied, reviewed — and updated in place, with version history quietly preserving what changed. The second is the disposal habit the Expiring view supports: records and attachments whose retention has ended are reviewed and removed on schedule, so the vault does not become the thing it replaced — an ever-growing pile in which the sensitive material from a decade ago sits unexamined. A smaller, current, well-anatomised vault is not just tidier. It is safer, faster to search, and cheaper to protect, and it is the version of the archive a successor could actually take over.

A Week in the Vault: Mid-March, Day by Day

Abstractions persuade; weeks convince. Here is one ordinary week in the heart of the season, run twice in the imagination — once in the old arrangement of Bear, email and memory, and once in the vault — compressed into the moments where the tools actually differ.

Monday begins with the question every Monday asks: what is outstanding, and for whom? In the vault, the answer is the opening screen’s work — the Due view listing the week’s items across all clients, the board showing eleven returns awaiting documents, four in review, three awaiting signature. The follow-up messages for the week are written from the checklists themselves, each naming the exact missing item. In the old arrangement, the same list is assembled — it always was assembled, Mara is competent — from Friday’s memory, two inboxes and a paper list, in about forty minutes, with one client missed until Wednesday. By nine o’clock the vault week is already ahead by the length of a meeting, and the missed client does not exist.

Tuesday is documents. A landlord client delivers the classic bundle: forty-one pages, one PDF, everything he owns. In the vault it is split before lunch — statements to their sections, the insurance declaration to the permanent page, the duplicated prior-year form recognised and discarded — and every page is indexed, so Thursday’s question about a repairs invoice is a search, not a dig. The old way, the bundle would live whole in a downloads folder under a name like scan_final2, its contents known only to whoever last scrolled it. On Tuesday afternoon a new client phones from a Windows laptop at his bookkeeper’s office, wanting to review what he sent last week. In the vault week, the record opens on that machine, in a browser, in front of him. In the Bear week, the answer is a promise to check at the office — a small sentence that costs a small amount of trust every time it is said.

Wednesday brings the season’s signature event: the client who calls, certain everything has been sent, while the brokerage statement — the one that delays a fifth of all returns — is still outstanding. The checklist section settles it in one screen, politely and completely: requested on this date, follow-up on this date, received items listed, the statement named as the single gap, with its partial account identifier matching the client’s own paperwork. The conversation that in the old arrangement took eleven minutes of searching and a callback now takes ninety seconds, and ends with the client apologising to the document instead of doubting the preparer. Wednesday evening, the extension decisions are made from the board, in one pass, with reasons recorded in the entries — not reconstructed in April from the archaeology of sent mail.

Thursday is the office’s Windows day: e-file reviews, the printer that only that machine loves, the part-time administrator working the follow-up queue. In the vault week, the administrator works the same record Mara works, on the machine that is free, updating checklist states that Mara sees when she next opens the file — because there is one file, in one place, and both of them know where it lives. In the Bear week, the administrator’s updates live in a shared note-taking arrangement of emails and a spreadsheet, reconciled by hand on Friday, because the primary archive is on an operating system this office day does not include. Thursday is also when the internet falters for two hours, as office internet does. The vault, making no network requests, does not participate in the outage. Work continues at full speed, which in mid-March is worth more than any feature on either product’s list.

Friday is signatures, filings, and the week’s one scare: a client reports a changed bank account for a refund, by phone, with some urgency and a hint that the old details may have been compromised. In the vault, the permanent page is updated once, the old details are preserved in version history — visible, dated, and clearly superseded, which is exactly what a careful record should show — and the Access entry for the client’s bank portal gets a freshly generated password while Mara is already in the record. The old arrangement would have scattered that change across the rolled-forward template, an email to herself, and a sticky note with a half-life. Friday ends with the week’s filings reconciled against the board. Nothing in this week was heroic. That is the point: a vault does not win the season in a moment. It wins it in ninety-second increments, forty-minute mornings, and callbacks that never have to happen.

The Security Conversation: What a Written Plan Actually Needs

Tax professionals in many jurisdictions work under a formal expectation — in the United States, a written information security plan — that they safeguard client data deliberately: know where it is, control who can reach it, use safeguards proportionate to its sensitivity, and be able to say what happens when something goes wrong. Whatever the local rule’s name, its logic is universal, and it is worth testing both tools against that logic rather than against marketing adjectives.

Where is client data? For VaultBook, the answer is a sentence: in this folder, on these machines, with these backups. An auditor, an insurer, or the preparer’s own future self can verify it by inspection. For a synced notes library, the honest answer is longer: on these devices, and in this provider’s cloud, under this personal account, in whatever form the sync keeps it, plus the exports and the email attachments that were the real archive all along. Neither answer makes a practice virtuous by itself — a local folder on an unencrypted, unpatched machine is its own problem — but one of them can be written down, checked, and improved, and the other can only be asserted.

Who can reach it? The vault’s answer is physical: whoever can use these machines and knows these entry passwords. Bear’s answer adds account recovery flows, provider support processes, and every device ever signed into the Apple ID. What happens when something goes wrong? The Northflank week is the template for the cloud half of the answer: something goes wrong at a provider, on the provider’s schedule, and the customer’s job is to react — rotate, audit, hope. The local half of the answer is older and duller: something goes wrong with a machine, and the practice restores its own folder from its own backup, on its own schedule, without filing a ticket with anyone. Dull is a compliment in incident response.

None of this makes VaultBook a compliance product, and this article makes no such claim: no notes app confers compliance, which lives in the practice’s whole arrangement of devices, habits, contracts and training. What a vault does is make the arrangement describable. Safeguards a plan can name — local-only storage, per-entry AES-256-GCM encryption for the most sensitive records, generated passwords, version history, expiry-driven disposal, no third-party document services touching client files because OCR, transcription and PDF work all happen on the device — are safeguards that exist. A plan written around a consumer sync account and a scatter of email attachments mostly describes aspirations. Preparers feel this difference most sharply not during an audit but during the client conversation: “where do you keep my information?” is becoming a question clients actually ask, and the practice with the one-sentence answer sounds like what it is — the safer pair of hands.

Honest Limits: What VaultBook Is Not

A comparison that finds no fault in its subject is an advertisement, and VaultBook has real limits that a practice should weigh with open eyes.

It is not a collaboration platform. There is no real-time co-editing, no comment threads with @mentions, no client-facing portal. Clients do not upload into VaultBook; Mara receives documents through whatever channel the client manages — ideally a secure portal the practice chooses for that purpose — and files them into the vault herself. Practices whose model depends on clients self-serving inside the system of record need a practice-management platform for that layer, with the vault as the protected record behind it. It is not a tax preparation engine and integrates with none: figures still move into the tax software by the preparer’s hand or export habits, as they do from any notes system. Its calendar is a record-bound calendar, not the office’s shared appointment book. Its single-file design, for all its portability, means the practice must take backups seriously in a way that synced-app users have been trained to forget; the tool will not rescue a firm from its own neglected backup drive, and this article’s migration section put the backup step in the sequence for exactly that reason. And its writing experience, while perfectly capable, is not Bear’s: nobody will open VaultBook just for the pleasure of the editor, and the preparer who writes long advisory letters may well keep a beloved writing app for drafting — with the finished letter filed, of course, in the vault.

The deepest limit is philosophical, and it is shared by every local-first tool: VaultBook will not meet the user halfway on convenience. There is no “sign in anywhere and your notes appear,” because appearing anywhere requires being somewhere, and being somewhere is the risk the product exists to refuse. For a personal notebook, that refusal can be a deal-breaker, fairly. For a client archive, the refusal is the feature — but a practice should adopt it knowingly, as a posture, not discover it as a surprise in its first busy week.

Questions Tax Preparers Ask Before Moving a Client Archive

Do I have to move every client at once? No, and you should not. Migrate the permanent pages for your most active clients first, create current-year entries as each engagement begins, and let the long tail arrive on its natural schedule. Historical years can stay where they are until a notice, an amendment or a returning question makes one of them worth migrating; the vault grows by relevance rather than by excavation.

What happens to my Bear notes that are not client work? They stay in Bear, where they were always better placed. The migration is not an app funeral; it is a separation of the professional record from the personal notebook. Many preparers find the separation itself clarifying: the app they open for their own thinking stops containing three hundred families’ financial lives, and the vault they open for work contains nothing else.

Is my data trapped in a proprietary format if I ever leave VaultBook? The vault’s data lives in local files you hold, and the working habit that protects you with any tool applies here: keep your documents as documents — the PDFs, scans and spreadsheets in client records are ordinary files, attached and indexed, not transmuted into a vendor’s private substance. Your words were exported from Bear as Markdown once; a practice that keeps its records in open, file-based form keeps its exit permanently unlocked, which is the deepest structural difference from an account-based library, where leaving means negotiating with a sync service and a subscription clock.

What if I lose the password to an encrypted entry? Then that entry is lost, and the honesty of that answer is the security model working as intended: encryption that a provider can undo for you is encryption a provider can be made to undo for someone else. The practice-grade response is procedural, not technical — the master password lives in the firm’s own continuity arrangements, sealed and recorded the way the firm’s other critical credentials are, so that the vault survives its keeper. Treat the encrypted Access entries with the same seriousness as the safe combination, because that is what they are.

Can my administrator and I work in the vault at the same time? The vault is a local file, not a multi-user database; the small-practice pattern is one vault, worked in by whoever is at the machine, with the Kanban board and checklist states carrying the coordination. Two people editing the same file simultaneously from two machines is the one pattern to avoid, and the afternoon-sized practices this article addresses rarely need it: the queue is shared, the record is shared, the edits are sequential in the way office work on a file has always been. A firm that genuinely needs simultaneous multi-editor access to live client files has outgrown notes-class tools entirely and should be looking at practice-management platforms — with a vault, still, as the protected record of the most sensitive layer.

Does it work when the internet is down, or at a client site with no connection? Completely. Zero network requests is not a degraded mode; it is the only mode. Search, OCR, transcription, the PDF tools, the calendar — all of it runs on the device in front of you. Filing season’s worst infrastructure day is a normal day in the vault.

How is this different from just using encrypted folders on my drive? An encrypted folder protects files at rest and does nothing else: no structure across them, no search inside them, no checklist states, no due dates, no version history of the record, no links between a client and their reasoning. The folder is a locked drawer. The vault is the filing system, the index, the diary and the lock, in one object. Practices usually start with the drawer and discover, somewhere around client two hundred, that custody was never only about locking.

Who Should Stay on Bear — and Who Should Move

Stay on Bear if your notes are your own: writing, research, personal knowledge, professional thinking that implicates no one else’s sensitive data. Stay if you are all-Apple by settled preference, work alone, and find — as many of its users plainly do — that its editor’s pleasure keeps you writing, because a notes system you love using beats a theoretically superior one you avoid. Stay, in particular, if the word “client archive” does not describe anything you keep; Bear was built for you, and it shows.

Move the client archive to VaultBook when the notes stop being yours alone. The triggers Bear’s own community names for leaving — a Windows machine entering the workflow, an IT policy with opinions about iCloud, sync failing at a bad moment, tags buckling under scale, deadlines living in a second app — are, for a tax practice, not inconveniences but the early shape of record-keeping risk. Add the triggers from the preparers’ side: documents arriving as photographs and bundles that need surgery and indexing, credentials that deserve generated passwords and per-entry encryption with no cloud in the loop, a security plan that must be able to say where client data is in one sentence, and a season whose central activity — knowing what is outstanding, for whom, by when — is a query your tool should answer rather than a prose pile it should store. When several of those are true, the question is no longer whether Bear is a good app. It is whether a writing app, however good, is the right shape of container for other people’s financial lives. It is not, and the mismatch is not Bear’s failure. It is the category’s.

Anatomy of One Client Record, Field by Field

General claims about structure become convincing only when you watch one record carry a whole relationship. Take a single representative client — a married couple, one wage earner, one with a growing freelance income, two children, a rental property in its third year, and a brokerage account that generates the season’s most-delayed statement — and walk their VaultBook record from top to bottom.

The client page opens with Identity: both names, including the spouse’s former surname that still appears on one institution’s paperwork and causes a mismatch every single year until someone writes it down; dates of birth; identity document references held in an encrypted entry rather than typed in the clear; the address history that explains why a state notice went to a previous home two years ago. Household follows: the children with their ages and the year each one’s status changes, the year the older child’s income crossed the threshold that mattered, the note — dated, because undated notes lie by omission — recording when the family said a parent might move in, which will matter to a deduction conversation in about eighteen months. Entities carries the rental: purchase date, the repairs-versus-improvements reasoning from the year of the roof, the depreciation schedule’s location, and the standing instruction that the tenants’ documents come through the spouse. The freelance business gets its own section: the bookkeeping rhythm, the quarterly estimates and what each was based on, the home-office facts as the client stated them, and the flagged uncertainty about one category of expenses that Mara resolved in the client’s favour with a documented reasoning note — the note that, if the return is ever questioned, is worth more than the return itself.

Standing Instructions is the section clients never know exists and always benefit from: documents may come from either spouse and from two specific addresses; call the husband’s mobile, never the house line, before ten; the wife wants the plain-language summary, the husband wants the figures; they always ask about the rental in the first five minutes, so have its page open. Access, encrypted, holds the portal credentials — each generated, none reused, each labelled with the service and the date it was last changed. Then the year entries hang off the page in sequence, each with its anatomy: Checklist, with the brokerage statement permanently marked as the long pole and its expected arrival window noted from three years of pattern; Correspondence, holding the substance of calls rather than their occurrence; Documents Received, each attachment dated and indexed; and the small, priceless section called Open Threads, where the unanswered question to the client, the pending confirmation from the bookkeeper, and the “check whether the credit still applies” thought are kept where the season will find them.

Now compare the same family’s Bear existence: a tag, a scattering of notes across three years sharing that tag with forty other families’ notes, the permanent facts interleaved with the seasonal ones, the credentials in an encrypted note that cannot be opened on the office’s Windows machine during review, and the standing instructions in Mara’s head, where they are safe exactly as long as she is never ill in March. Both archives contain, in some sense, the same information. Only one of them is a record. The difference is not effort — Mara worked hard in both worlds. The difference is that one tool’s structure assumes a reader who is not you, at a time that is not now, under pressure you cannot predict, and the other’s assumes a writer in a pleasant moment. Tax records are written for the first reader. They should be kept in a tool designed for them.

Checklists That Survive Contact with Clients

Because the checklist is the season’s engine, its craft deserves more than a paragraph. The discussions among preparers converge on a set of hard-won principles, and VaultBook’s structure supports each of them in a way a notes app’s checkbox list cannot.

Precision beats politeness. A request that says “your brokerage statement” produces last year’s statement, a summary page, or a screenshot of a balance. A request that names the institution, the form, the tax year, and where helpful the final digits of the account produces the document. In the vault, that precision is not retyped per client per year; it is the checklist line itself, carried in the entry, refined each season as the practice learns which phrasing worked. The checklist becomes an asset that appreciates: every wrong document received is a lesson permanently encoded in next year’s wording.

States beat checkmarks. A checkbox knows two things; a season needs four — requested, received, reviewed, missing — plus the awkward fifth state, not applicable this year, which clients themselves misapply when they self-report completeness. Mara’s checklist lines carry their state in words, and the difference between received and reviewed is where quality lives: the document that arrived is not the document that was checked, and conflating them is how a wrong-year form gets filed from in good faith. The board view then aggregates the states across the practice, so the Monday question — where does the season stand? — is answered by counting, not by vibes.

The cutoff is a design decision, not a hope. Practices that write an internal cutoff into the engagement letter, track against it in the tool, and treat the extension as the planned outcome for late files rather than as a failure — those practices describe calmer Marches, and the calm is mechanical: the Due view shows the cutoff approaching per client while there is still time to act, so the extension conversation happens in February’s courtesy instead of April’s panic. The checklist, the cutoff and the extension are one system; in a vault they are also one object, and the record of the client’s agreement sits in the entry it governs. A Bear checklist can hold the same words. It cannot raise its hand when the date arrives, cannot show the practice its own state on a board, and cannot stop the permanent facts and the seasonal states from blurring into one scroll of equally-weighted text. Craft needs a medium that respects it.

Season Two, Season Five: The Compounding Vault

The first season in a vault is about survival. The returns arrive later, and they compound. In season two, intake for returning clients shrinks to a review: the permanent page is checked, not rebuilt; the new year entry begins with last year’s checklist already knowing which document arrives late, which client needs the early call, which question was left open. The follow-up that a first-year practice sends three times, a second-year vault practice sends once, because the standing instructions remember what memory should not have to. By season five, the vault holds something no hire can be given and no competitor can copy: the practice’s entire operational memory, structured identically across hundreds of families, searchable in seconds, with its reasoning preserved in version history and its open threads carried faithfully across years.

Consider what that memory is worth at the three moments a practice is valued: when a client decides whether to stay, when a successor decides what the practice is worth, and when an authority asks the practice to explain itself. The client experiences it as being known — the preparer who remembers the roof year, the spouse’s preference, the document that always comes late, without being told twice. The successor experiences it as the difference between buying a client list and buying a practice: records that a competent stranger can pick up in January and run. The explanation moment experiences it as the difference between reconstruction and retrieval. None of these values appear in an app comparison table, and all of them are decided by the comparison anyway, because they are functions of structure, search, permanence and control — precisely the axes on which a single-file vault and a synced writing app diverge.

There is a quieter compounding, too: the preparer’s own expertise. Every position documented, every state quirk recorded, every checklist phrasing improved by a failure — indexed by the vault’s wiki links and related notes, and retrievable by its question-answering search at the moment a similar fact pattern walks in — turns a solo practitioner’s memory into an institution of one. Bear can hold expertise beautifully for its writer. A vault holds it accountably, in the record, next to the clients it was earned on, under encryption where it is sensitive and under version history where it is precious, on machines the practice actually owns. Expertise kept that way does not retire when its keeper does.

The Second Pair of Hands: The Administrator’s Morning

Most app comparisons are written for a user of one. Practices run on handoffs, and the handoff is where consumer tools quietly tax a firm. Spend a morning with the part-time administrator — the person who works the follow-up queue, files the arrivals, and fields the “did you get my documents?” calls — and the vault’s design choices stop being features and start being the job.

Her morning opens on the board and the Due view, not on an inbox. The queue is the practice’s, not Mara’s personal arrangement of it: these clients get follow-ups today, these documents arrived overnight and need filing to their entries, these three checklists changed state yesterday and their owners should be told. Dynamic tabs let her keep the day’s active clients open side by side — the caller on the phone, the bundle being split, the checklist being updated — without the tab-chaos of a browser full of web apps or the single-note tunnel of a phone-first editor. When a caller asks the season’s most common question — what do you still need from us? — she answers from the same checklist Mara would answer from, reading the same states, because there is one record and she is looking at it. In the Bear arrangement, she was answering from a shadow system of forwarded emails and a spreadsheet that Mara reconciled weekly; every answer carried a small probability of being last Tuesday’s truth, and both women knew it, and neither could fix it, because the archive itself lived in an app the administrator’s machine could not run.

Her filing work is the vault’s document machinery doing quiet labour: bundles split, photographs indexed by OCR and filed where the checklist expects them, the File and Folder Analyzer run over the downloads folder on Fridays to catch the arrivals that came through the browser and never got filed, each one matched to its client and absorbed. Her security posture is identical to Mara’s without a single extra step: she works in the same local file, on an office machine, and when her seasonal engagement ends, nothing leaves with her — no account, no synced copy, no seat to revoke. Onboarding her in January took an hour, most of it practice procedure rather than software, because a vault with a consistent anatomy teaches itself: every client record is shaped like every other, so learning one is learning all. Tools designed for a single beloved user rarely survive contact with a second pair of hands. The vault was designed for the record, and records are inherently multi-reader — across people, across years, across the author’s own future selves.

Why Notes Apps Became Clouds, and What It Cost the Records

It is worth stepping back, because the Bear-versus-vault question is one instance of a larger drift that professionals rarely chose on purpose. Notes software became cloud software for reasons that were mostly about vendors, not records: sync is a subscription’s justification, accounts are a company’s asset, and a library held on a server is a customer retained. Each step was individually convenient — your notes on every device, nothing to back up, nothing to think about — and the aggregate was a quiet transfer of custody over the most candid material professionals produce: the working notes, the drafts, the credentials-adjacent jottings, the records-in-progress that were never meant to be publications. The transfer went unnoticed because the material felt informal. But the working archive was never informal in consequence — only in appearance. It holds the identity documents, the reasoning, the open threads and the deadlines of a practice’s entire clientele, and it deserves the custody standards of the filed return it supports.

The incidents that punctuate the cloud era — and the Northflank disclosure of 30 October 2026 is simply this week’s, with its platform-wide instruction to assume every stored secret had been decrypted — are not indictments of any one company’s care. They are the arithmetic of concentration: gather enough valuable material in one place and the place becomes worth attacking with resources no individual practice could ever face, while the cost of failure is distributed to everyone who stored there. A local vault inverts the arithmetic. Mara’s archive is worth attacking only at Mara’s scale, sits behind her machines’ ordinary defences and her entries’ encryption, and — the decisive property — exists in exactly the places she put it. Local-first software is sometimes framed as nostalgia. For records work it is better understood as custody returning to its owner, with modern capabilities — full-text and semantic search, OCR, transcription, document tools — that no longer require a server to perform. The cloud was a means to those capabilities. VaultBook is evidence the means can be declined while the capabilities are kept.

When Clients Ask Where Their Data Lives

The last workflow is a conversation, and it is arriving in practices whether they prepare for it or not. Clients — prompted by breach headlines, by their own employers’ training, by the simple fact that they are handing over the documentary skeleton of their financial lives — increasingly ask where their information goes. The practice’s answer is a competitive asset or a liability, spoken in one breath, at the moment of maximum trust-sensitivity: the first meeting.

The vault answer is short enough to say without notes. Your records live in an encrypted vault on our own machines, in this office. Nothing is uploaded to a notes cloud, your documents are never sent to online services to be read or split or transcribed, the most sensitive items are encrypted individually, and the people who can reach your file are the people in this building whose names you know. Every clause of that is verifiable in the tool’s design — zero network requests is not a policy promise but an architectural fact — and every clause answers the fear behind the question, which is not really about geography. It is about whether the client’s life becomes inventory in someone else’s system, exposed to someone else’s incident, retained under someone else’s terms. The synced-app answer is not dishonest, but it is longer, more conditional, and depends on accounts and settings the client cannot see: a personal cloud here, a subscription there, an export somewhere else. In a profession whose entire product is trustworthiness with other people’s facts, the short answer wins clients the long answer worries. A vault, in the end, is not just where the records are kept. It is what the practice can truthfully say about them.

The Cost Ledger Nobody Shows You

App comparisons love a price line, and this one has already given Bear’s honestly: free to write on one device, $2.99 a month or $29.99 a year for the Pro tier that professional use requires. But the subscription line is the smallest cost in either system, and a practice choosing on it alone is reading the wrong ledger. The full ledger has four more columns, and they are worth pricing in hours, because hours are a tax practice’s actual currency.

The first column is retrieval time. Every “where is that?” moment — the eleven-minute search while a client waits, the callback that has to be made because the answer was on the wrong device, the administrator’s question that interrupts the preparer’s review — costs minutes at the season’s most expensive rate. A conservative practice of three hundred clients will spend hundreds of such minutes between January and April. A vault whose search reaches inside every attachment, whose permanent facts live in one place per client, and whose checklists answer the most common question instantly does not eliminate retrieval cost, but it collapses the worst of it: the multi-source dig. Bear’s search is fast within its library; the cost it cannot remove is the library’s absence — from the Windows machine, from the administrator’s desk, from the client site — and the parallel systems that absence forces into existence.

The second column is duplication labour: the work done twice because two tools each hold half a truth. The reminder app reconciled against the notes, the spreadsheet reconciled against the checklist, the rolled-forward template reconciled against what the client actually said last year. Duplication labour is invisible in budgets and enormous in aggregate, and it carries a second, hidden price — every duplicated fact is a future discrepancy, and every discrepancy surfaces at the worst available moment, usually with a client or an authority on the line. Single-source systems charge this column almost nothing. That is not a metaphor. It is the entire economic argument for a vault.

The third column is risk-adjusted incident cost. No practice can price a breach precisely, but it can price exposure classes: how much client material sits in how many places, under whose control, reachable by compromising what. A working archive concentrated in a personal cloud account, an email system, and a scatter of downloaded bundles is exposed along every one of those paths; the Northflank instruction — assume everything stored there was decrypted, rotate everything — is what that exposure feels like from inside when one path fails. A vault’s exposure is the office’s own devices plus its backups, an exposure the practice can enumerate, reduce with encryption and hygiene it controls, and insure against with open eyes. The expected cost difference over a decade of practice is not the price of either app. It dwarfs both.

The fourth column is exit cost — the price of changing your mind. Leaving a synced, account-based library means exporting under a subscription clock, rebuilding structure inside a tag system that does not map cleanly onto anything else, and discovering which attachments and encrypted notes travel badly. Leaving a file-based vault means copying files. Practices rarely price exit cost at adoption time, which is exactly why vendors can: lock-in is most profitable when it is least discussed. The cheapest time to buy an exit is before you need one, and the file you hold is the exit, pre-purchased. Set against these four columns, the honest summary is almost unfair to make: Bear is inexpensive software that can become an expensive system, because its gaps bill you in hours, duplication, exposure and dependence. VaultBook’s economics run the other way — the tool asks more of you at setup, in structure and backup discipline, and then stops billing. Choose with the full ledger open.

Same Twenty Notes, Two Organisations

Abstract claims about tags and pages deserve one concrete trial. Imagine twenty real items from one week of Mara’s practice, and organise them twice.

The items: a wage statement photo for the Alvarez family; the same family’s permanent identity entry; a rental repairs invoice for the Okafor household; a note of a call with a bank about a client’s missing statement; this year’s checklist for the Nguyen return; last year’s checklist for the same return, kept for the reasoning in it; a portal credential for a payroll service; a state notice about a 2023 return; the reasoning note for an unusual deduction position; a brokerage statement that arrived at last; a follow-up draft to a slow client; an engagement letter, signed; a photograph of a paper form taken at a kitchen table; the practice’s own procedure for extension requests; a bookkeeping client’s December bundle, split into nine documents; a dependent’s new identity document; a question-and-answer research note on a credit’s current rules; a voice memo, transcribed, from a client call; a lender letter assembled from three statements; and the note recording that one spouse answers from a different email address.

In Bear, every item is a note, and the organisation is tags: client tags, year tags, type tags, status tags. It works — until the questions arrive. Show me everything permanent about the Nguyens, separate from this year’s work: a tag intersection, if the discipline held. Show me every outstanding item across the practice: not a tag question at all, because outstanding lives in prose. Open the credential on the Windows review machine: impossible. Find the call note by what the bank said: searchable text, good — unless the note was the voice memo, which in Bear is an attachment to be played, not text to be found. Split the December bundle: not here. The system’s answers degrade exactly as the questions become operational, because tags classify notes; they do not constitute records.

In VaultBook, the same twenty items land in a structure that was designed for the questions. The permanent items live on client pages, in their sections; the year’s items live in year entries with checklist states; the credential is an encrypted entry with a generated password; the bundle is split and its nine documents indexed; the voice memo is transcribed locally into searchable text; the notice carries an expiry-tracked date; the follow-up draft is a due item, visible in the sidebar until it is done; the research note is wiki-linked to the return it will inform, and related notes surface it when that return is opened. Nothing here required more discipline than the tag scheme did — arguably less, because the structure is in the tool rather than in the user’s memory of the scheme. That is the whole argument, reduced to twenty items: classification is something you do to notes; a record is something a practice runs on.

Rehearsing Failure: Four Drills Every Practice Should Run

Security writing loves principles; practices need drills. These four take an afternoon a year in total, and the vault’s design is what makes each of them passable by a two-person firm.

Drill one: the dead laptop. On a chosen Friday in November, the main machine is declared dead. Work proceeds from the backup copy of the vault on the other machine. Pass condition: every client record from the current week is present, the encrypted entries open, and the checklist states are today’s — which is simply a test of whether the backup rhythm is real. A synced library passes this drill too, on a good day, through an account sign-in; the vault passes it through a folder, with no account, no network, and no provider’s status page involved, including on the day the provider is having the kind of week Northflank just had.

Drill two: the corrupted record. One client page is deliberately damaged in a copy of the vault — a section deleted, a figure changed — and the practice restores the truth from version history. Pass condition: the record’s prior state is viewable and recoverable, and the team learns, before it matters, exactly how the history reads. Prose in a notes app has a version of this in some tools and none in others; in a vault built for records, the past of the most important page in the practice is a feature, not a hope.

Drill three: the deadline-week outage. Internet down, phones on mobile data, a filing deadline at midnight. The vault’s pass condition is trivially met because nothing it does uses the network — search, documents, checklists, calendar all run — and the drill’s real subject is the rest of the firm: e-filing contingencies, the printer, the coffee. It is worth naming how a synced workflow experiences the same day: notes reachable only where they were last synced, the newest checklist state unknowable, the administrator and the preparer working from divergent copies that will reconcile painfully tomorrow. Outages choose deadline weeks with suspicious reliability, and a tool that cannot notice them is a form of insurance that pays out annually.

Drill four: the preparer is ill. The hardest drill, and the one that reveals what an archive is for. Mara is home with flu in the second week of March; the administrator and a colleague preparer must run the practice from the records alone. Pass condition: a competent stranger can open any client record and know — what is permanent, what is outstanding, what was promised, what the reasoning was, and what happens next — without phoning the sick preparer. Tag libraries fail this drill in the specific way their own users predict: the scheme was in the author’s head. A vault with fixed anatomy, standing instructions, open threads and checklist states is the drill’s passing shape. Run it once and the practice will never organise casually again, in any tool.

From Shoebox to System: The Paper Bridge

Every digital practice has an analogue shadow: the shoebox, the grocery bag of receipts, the envelope of paper forms that some clients will bring until the end of time. Tools that pretend paper away force the practice to maintain a parallel universe of unscanned, unindexed, unfindable originals. The vault’s bridge across is deliberately mundane, and mundane is what makes it get used.

Paper arrives and is photographed or scanned at intake — at the office desk or, for the kitchen-table clients, on the spot. Into the client entry it goes, where OCR indexing makes the photographed form’s text searchable, the Photo and Video Explorer keeps the image pile legible with its metadata, and the checklist line it satisfies changes state in the same motion. The original’s fate is recorded in the entry — returned to the client, filed in the office’s paper retention, or destroyed after scanning under the practice’s policy — so the question “do we still have the paper?” has an answer that does not depend on searching two buildings. Receipts and small documents, the shoebox’s contents, get the same treatment in aggregate: photographed in batches, attached to the period they belong to, and made findable by their extracted text rather than by a human’s memory of which box they were in. The File and Folder Analyzer closes the loop on the digital side of the shadow: the years of scanned-but-never-filed material sitting in drive folders can be audited in bulk — counted, sorted, matched against the vault’s records — and either absorbed or disposed of deliberately, instead of persisting as an unexamined second archive that contradicts the first.

The principle underneath the bridge is the one this whole comparison keeps returning to: there must be exactly one place that is the record, and everything — paper, photograph, bundle, voice memo, email attachment — must have a short, habitual path into it. Bear cannot be that place for documents, because documents are guests in it; email cannot be that place, because it is a transport pretending to be a store; a folder tree cannot be that place, because it cannot search, state, remind or explain itself. The vault can, because it was built as the place: attachments are citizens, paper becomes indexed images, and the record stays one. Practices do not usually fail at the sophisticated end of record keeping. They fail at the shoebox. A tool that takes the shoebox seriously has understood the job.

The First Ninety Days: A Setup Diary

Tools are adopted in calendars, not in comparisons, so here is the migration and first season as a dated diary — the honest version, including the parts that are tedious, because the tedious parts are where adoptions actually die.

Days one to seven are structure and nothing else. The client page template is settled — Identity, Household, Entities, Standing Instructions, Access — and argued about exactly once, because every later change costs more. The label scheme is fixed at its boring minimum. The backup rhythm is chosen, written into the security plan, and performed once by hand so that everyone has seen it work. No client data moves yet. This week feels unproductive and is the most important one: it is the week the practice decides what its records are, as opposed to where they happen to be stored.

Days eight to thirty are the permanent-layer build for the most active clients, done in the order the season will need them. Each page is an audit as much as a transfer: facts checked, documents attached, credentials replaced with generated ones inside their encrypted entries. The work is slower than a bulk import and better for the same reason — a bulk import would have preserved every error with perfect fidelity. By day thirty the practice can answer the client question — where is my information kept? — with the short answer, truthfully, for the clients who generate most of the work. Bear remains live for personal notes and as read-only reference for the unmigrated tail, and nobody is asked to change two habits at once.

Days thirty-one to sixty are the first live month of year entries. Checklists are built as states, not prose, and the first follow-up cycle runs off the Due view instead of off memory. This is the month of small discoveries: the checklist phrasing that still produces the wrong document gets fixed in the template, permanently; the standing instruction everyone knew and nobody wrote down gets written down, three times, for three clients, and then becomes a prompt in the intake routine. The administrator’s morning changes shape — board first, inbox second — and the weekly reconciliation meeting between the shadow spreadsheet and the real record quietly stops being scheduled, because there is no longer a shadow to reconcile.

Days sixty-one to ninety are where the vault stops being a project and becomes the office’s furniture. The December-bundle clients are absorbed through the paper bridge. The File and Folder Analyzer audit of the old drive folders happens on two quiet Fridays, and the second archive — the unexamined one — shrinks to a list of deliberate decisions. The first notice of the year arrives for a prior-season return and is answered from the record in an afternoon, which does more for the team’s faith in the system than any feature demonstration could have. Nothing in the ninety days required heroics, new hardware, or a consultant. It required treating the archive as infrastructure rather than as an app choice — which is, in one sentence, the difference between the two products this article has compared.

Bear on Its Best Day, VaultBook on Its Worst

A fair test inverts the usual comparison. Put each tool at its most flattering and least flattering, and see whether the verdict moves.

Bear on its best day is genuinely lovely: a quiet morning, one Apple machine, fast sync, a well-kept tag tree, an essay of a client memo drafted in an editor that makes writing feel like a craft again. Nothing in this article denies that day exists, or that for personal knowledge work it can be most days. Bear on its worst day is a deadline afternoon with a Windows-only review to perform, a sync conflict between the phone’s checklist and the desk’s, a seasonal hire who cannot be given the archive at all, and an encrypted note whose subscription lapsed at the start of the month. The worst day is not a malfunction; it is the design, encountered under load.

VaultBook on its best day is unglamorous to the point of invisibility: the record opens anywhere, the answer is found in seconds, the documents are where the checklist says they are, and nobody thinks about the tool at all — which, for infrastructure, is the highest praise available. VaultBook on its worst day is the day the backup discipline was neglected and a drive fails, or the morning a forgotten master password locks an encrypted entry for good. Those worst days are real, and this article has priced them in rather than waving at them: they are the cost of custody, and they are managed by procedure — tested backups, continuity arrangements for credentials — of exactly the kind a regulated practice is supposed to maintain anyway.

The inversion clarifies the choice because the two worst days differ in kind. Bear’s worst days are imposed from outside — by platform boundaries, by a provider’s week, by a subscription’s state — and arrive on the calendar’s worst dates without asking. VaultBook’s worst days are self-inflicted and schedulable: they happen when the practice skips its own procedures, and they are prevented by the practice’s own procedures, rehearsed in the drills described earlier. Professionals who carry other people’s risk for a living learn to prefer the second kind of bad day, every time, because it is the kind they can govern. That preference — not typography, not tags, not any single feature — is the real subject of this comparison, and it is why the verdict survives the inversion intact.

The Practice’s Own Pages: Procedures, Precedents and the Private Wiki

Half of a vault’s value never appears in a client file at all. It accumulates in the practice’s own pages: the procedures, precedents and hard lessons that turn one preparer’s experience into a firm’s method. This material has a natural home in VaultBook’s wiki structure, and its absence from consumer notes workflows is one of those quiet losses nobody itemises until the day it is needed.

Procedures first. The extension-request procedure, the notice-response procedure, the new-client intake sequence, the end-of-season archive routine: each becomes a page, written once at the quality the practice aspires to on its worst day, linked from every workflow it touches. When the administrator asks how extensions are handled here, the answer is a page that opens in the vault, not a retelling that varies with the teller’s memory and the week’s pressure. Procedures kept this way get improved in place — the sentence that confused a seasonal hire gets rewritten the day it confuses her, with version history preserving what the procedure used to say and when it changed, which matters more than it sounds when a question later arises about how a file was handled in a particular month.

Precedents next. Every unusual position the practice has researched and resolved — the treatment of a peculiar credit, the handling of a straddling income item, the state’s answer to a question that took three phone calls to settle — becomes a precedent page: the issue, the facts that mattered, the reasoning, the sources consulted, the conclusion, and the client anonymised to a pattern. Wiki links bind each precedent to the returns it informed; related-notes surfacing brings it forward when a similar record is opened; and the semantic search lets a preparer ask the vault a question in the shape of the problem in front of her — what have we done when a client sold a rental mid-year with a tenant in place? — and be taken to the practice’s own prior thinking, not just to documents that happen to share its keywords. This is the second-brain promise that personal-knowledge tools make to individuals, rebuilt for its professional form: not a garden of interesting clippings, but a body of accountable precedent, kept under the same roof and the same protections as the records it governs.

The compounding here is easy to miss and hard to overstate. A practice whose reasoning lives in its vault can be delegated, audited, taught and eventually sold. A practice whose reasoning lives in its preparer’s head and in the margins of a personal notes app — interleaved, in Bear’s case, with that preparer’s journals and reading, on devices the practice does not own, in an account the practice does not control — can be none of those things, however brilliant the reasoning is. The wiki pages are also where this article’s comparison stops being about the season at all: they are the difference between a job and an institution, kept in a file.

Objections, Answered in Full

I’ve heard the objections to moving a client archive, in one form or another, from every direction — and several of them are good. They deserve answers at full length rather than a dismissal, because a practice that moves for bad reasons will move back at the worst time.

“I like writing in Bear. My clients’ notes are half my thinking.” Then keep Bear for the thinking — genuinely; this article has recommended exactly that split more than once. The objection dissolves once the archive and the notebook are allowed to be different tools for different materials. What should move is the record: the permanent facts, the checklists, the documents, the credentials, the deadlines. Drafts, reflections and reading notes stay in the beautiful editor, and the finished thinking gets filed into the vault where it becomes part of the record it informs. The split feels artificial for about a week, and then it feels like the difference between a desk and a filing cabinet — obvious, and faintly embarrassing to have conflated.

“My clients already send documents through a portal.” Good — keep the portal for transport. A portal is a doorway, not a room; it moves documents from clients to the practice, usually under the portal vendor’s custody and the vendor’s retention, and it does not pretend to be the practice’s structured, permanent, searchable record. The vault is where documents come to rest after the doorway: filed to the client, indexed, attached to the checklist state they satisfy, protected under the practice’s own arrangements. Practices get into trouble when the doorway is mistaken for the archive and the record of a decade ends up scattered across a vendor’s idea of a folder tree.

“I’m too small for this. It’s just me.” Smallness is the condition the vault fits best. A solo preparer has no IT department, no compliance team, and no margin for a season lost to a custody failure; the entire apparatus of the vault — one file, one folder, a backup drive, a written plan — is sized for one person’s hands. The firms that can survive sloppy custody are the ones with departments. The solo practice is the one that cannot.

“We’re too big for a file-based tool.” Possibly — a firm with dozens of staff editing live records simultaneously needs practice-management infrastructure, and this article has said so plainly. But notice that even that firm’s most sensitive layer — the precedents, the credentials, the reasoning, the records behind the records — still needs a custody answer, and a vault beside the platform is a better answer than the platform’s notes field. Scale changes the vault’s job description. It does not retire it.

“What about my phone?” The vault opens in a browser, and a phone has a browser; the record is reachable on the device in your pocket without an account, a sync, or an app store’s permission. It will not feel like a lovingly native phone app, because it is not trying to be one. It is trying to be the record, present when needed, and for the kitchen-table photograph and the roadside question about a deadline, present is the whole requirement.

“Switching costs a week I don’t have.” Switching costs the ninety days described earlier, most of it at audit quality you would eventually want anyway, and it costs them once. Staying costs the duplication tax, the retrieval tax and the exposure — every season, at season prices, forever. The honest comparison is never between change and rest. It is between one deliberate migration, done in the quiet months on the practice’s own schedule, and an eventual forced migration — after a platform change, a sync failure, a lapsed account, a provider’s bad week — done in February, on someone else’s.

The Details That Decide It: Tabs, Links and Questions

Comparisons are usually settled by headline features, but seasons are settled by details — the small mechanics a preparer touches two hundred times a week. Three of VaultBook’s deserve a closer look, because each replaces a specific, recurring friction that Bear’s model either cannot address or addresses in a different app.

Dynamic tabs are the first. Review work is parallel work: this year’s entry open beside last year’s, the precedent page beside both, the checklist beside the document it governs. In a single-note editor, that parallelism is a juggling act of navigation — leave one note to check another, lose your scroll position, rebuild your context, repeat until the review’s thread frays. VaultBook’s dynamic tabs keep several entries genuinely open at once, each holding its place, so a cross-year consistency check is a glance sideways rather than a journey. Multiply a saved minute of context-rebuilding by the number of times a preparer does it in a season and the tab strip becomes one of the most valuable surfaces in the product — unglamorous, unmarketable, and used more than any headline feature in the building.

Related notes are the second. A record system earns its keep at the moment it volunteers what you forgot to ask for: open the client whose rental position changed this year, and the precedent page from two seasons ago is surfaced alongside; open the notice response, and the correspondence that led to it is one glance away. In a tag library, those connections exist only where the author remembered to build them, in the moment of writing, under no time pressure — which is to say they exist for the notes written in calm weeks and not for the ones written in March. Automatic relatedness is not a luxury in records work. It is how a system argues, quietly and at the right moment, that the past of this file is relevant to the decision in front of you.

The third is asking the vault a question. Keyword search finds documents that contain words; a season’s real questions are rarely made of the words the documents happen to use. What did we conclude about the home-office question for the freelance client whose spouse also works from that house? Which clients are still missing a document that historically arrives after the internal cutoff? What was the reasoning when we treated those repairs as current expenses? VaultBook’s semantic question-and-answer search takes the question in its natural shape and returns the entries that answer it, across notes and indexed attachments alike. The preparer is no longer required to remember her own filing vocabulary from three years ago — the single most unrealistic demand that ordinary search makes of a busy practice. Bear’s search, to give it its due once more, is quick and, for Pro subscribers, reaches inside images and PDFs; but it searches a personal library organised for its author’s memory, and it stops at the borders of Apple’s devices. The vault’s search assumes a reader who was not the author, at a date the author could not predict, asking a question in words the author never used. That assumption — unromantic, professional, correct — is the difference between a notebook and a record, stated one last time in its most practical form.

A Note on Method: How This Comparison Was Made

Comparisons should show their working, and this one’s is simple enough to state. Every claim about Bear — its platforms, its Pro price of $2.99 a month or $29.99 a year, the features that subscription unlocks, its iCloud-only sync, its support for Apple’s Advanced Data Protection — was checked against Bear’s own website and Pro page on the day this article was written, not copied from a review roundup. Products change; if a detail here ever disagrees with the maker’s own page, the maker’s page is right and this article is a snapshot. Every VaultBook capability named — per-entry AES-256-GCM encryption, local OCR and transcription, the PDF suite, attachment indexing and semantic search, the calendar and the Due and Expiring sidebar, the Kanban view, version history, the password generator — comes from the product’s documented feature set, and no capability has been rounded up, anticipated, or borrowed from a roadmap.

The human material came from practitioners’ own public discussions: Bear users in the app’s community forums, talking about platform lock-in, sync behaviour, subscriptions and organising at scale; and tax professionals in theirs, talking about document chasing, scattered records, sensitive-data custody and deadline work. Those discussions are used here the way a good interviewer uses them — for themes, situations and failure patterns, paraphrased in this article’s own words. The preparer called Mara is a composite built from those recurring situations, not a portrait of a real person, and no practitioner’s words are quoted, because the point was never any one voice. It was the chorus: hundreds of people, in two different communities, describing the same handful of walls from opposite sides — the notes tool that stops scaling, and the season that will not wait. Where this article has taken a side, it has tried to earn it workflow by workflow. Where the evidence ran the other way — Bear’s editor, its price, its genuine pleasures — the article has said so in the same tone. That is the only kind of comparison worth a professional’s reading time, and it is the standard this site intends to keep.

The Bottom Line

Bear and VaultBook begin from opposite convictions. Bear believes a notes app should be a beautiful, fluid place to think, held together by tags, synced invisibly through Apple’s cloud, on Apple’s devices — and within that conviction it is exemplary. VaultBook believes a knowledge system for sensitive work should be a single file you own, on any machine you own, that never asks a network for anything, encrypts what matters entry by entry, treats documents and deadlines as first-class citizens, and can be described to a client, an auditor or a successor in one honest sentence. A tax practice’s working archive — permanent facts and seasonal checklists, sideways photographs and portal passwords, cutoff dates and extension decisions — lives or dies by the second set of convictions.

That is why the comparison resolves the way it does, and it resolves the same way for any profession whose notes are really records: the lawyers with client files, the clinicians with session material, the advisers with household financial lives in their care. The personal notebook and the professional vault look like cousins and are, in truth, different species. Keep the notebook for your thinking. Put the records in the vault — structured per client, searchable to the last photographed form, encrypted where it counts, dated where it matters, and present on every machine the season touches, because it was never anywhere else but in your hands.

One final test settles any remaining doubt, and it needs no feature list at all. Imagine the working archive must be explained, under pressure, to three people in the same week: to a client asking where their financial life is kept, to a colleague covering the practice during an illness in March, and to a successor deciding what the practice is worth. The vault passes all three conversations in the same words — it is in this file, on these machines, structured like this, protected like this, backed up like this — because its design was a custody design before it was a feature list. The notebook passes none of them without qualifications, detours through accounts and settings, and a small apology for the parts that live in its author’s head. Tools reveal what they were built for at exactly these moments. Bear was built for the writer alone with their thoughts, and it is superb there. VaultBook was built for the professional answerable for other people’s records, and a tax season — with its photographs and bundles, its cutoffs and extensions, its sideways forms and its 7 a.m. questions — is simply what that answerability looks like, four months a year. Choose the tool that was built for the conversation you will actually have to pass.