Trust
Who can see your data
Silo is built by one person — me, Ben Colson. I spent the first six years of my career as a software developer, working mostly on competition draw systems and web applications in the financial services industry; though these days I spend most of my time as a photographer, DoP and DIT on commercials, operating as Colson Studio Ltd. The obvious question deserves a straight answer: what stops me reading your rates, your clients, your bookings?
Silo's encryption
Silo protects your sensitive data with account-based, end-to-end encryption.
When you log in with a username and password, your password is run through a key-derivation function together with a unique salt to produce your encryption key. That happens entirely in your web browser, and the key itself is never transmitted or stored anywhere. Your password does travel to my server when you log in — it has to, for Silo to know it's you — but only in transit, and it's kept solely as a one-way hash that can't be turned back into your password or your key. If you sign in with Apple or Google instead, Silo asks you to set a password as well, because without one there's nothing to derive your key from.
The encryption key doesn't encrypt your data directly. It unlocks a second, randomly generated key, and that's the one that encrypts your jobs, clients, expenses and invoices, using a modern, industry-standard cipher. Two keys instead of one means changing your password simply re-locks the same key, rather than re-encrypting everything you've ever entered. It also means Silo's servers only ever hold scrambled data. It's unscrambled on your device, and never visible to me or anybody else — even if the database were stolen.
Some things sit outside that, by necessity rather than by choice, and it's better you know which. Dates and statuses stay readable so the app can sort and group your jobs without your key. Anything written by calendar sync or by inbound call-sheet processing stays readable too: both run on the server at a moment when your key isn't there to use — the call-sheet one arrives by email when you're not even at your desk — so there's nothing to encrypt it with. Those are encrypted with a key I hold instead, which protects them if the database were ever stolen, but not from me. Quote records and your saved client names and billing addresses are in that same category today.
End-to-end encryption is also something you switch on rather than something I impose. If you haven't, your figures are still encrypted at rest under my key rather than sitting in the open — but the guarantees below about what I can't see are about accounts that have turned it on.
What doesn't live on Silo's servers
Your call sheets don't stay on Silo servers. Forward a call sheet to your Silo address and it's read, key information is extracted, it's matched to the job, and then stored in your own Google Drive, OneDrive or Dropbox. Dates, times and locations are recorded, but the document itself doesn't stay on my infrastructure. If you haven't connected a storage provider at all, the file is read and then discarded rather than kept. There's one exception, and Silo tells you when it happens: if the upload to your provider fails, the original is held on Silo's own disk and retried daily until it lands — the alternative would be losing a document you were relying on. The most client-dense thing you handle isn't mine to read, lose, or leak. The information that is retained in Silo's database is encrypted.
Your wider cloud storage. The Google Drive/OneDrive/Dropbox integration scopes Silo requests and will only touch files Silo itself saved or created. The application cannot see the rest of your drive, and that's enforced by Google, Dropbox and Microsoft.
What I can technically see
Not much, really. Some non-sensitive top-level job details, locations, and calendar dates and event names can be read by the application at any time. These are stored encrypted with a key known and used by the server and application.
Your numbers – day rates, kit rates, expense amounts, invoice and quote line prices, discounts – are encrypted end-to-end with a password-derived key once you've switched encryption on, and cannot be decrypted outside of your session. In the event of a data breach, all the raw data would reveal is ciphertext, not your numbers.
Client names, billing addresses and the totals on a saved quote are the honest exception: they're encrypted, but with my key rather than yours, because the server has to be able to read them — to match a calendar entry to the right client, and to re-draw a quote PDF you generated months ago. So they're safe from a stolen database, but not from me. I'd rather say that plainly than let "end-to-end" do work it isn't doing.
What limits access to that database? Three things:
1. There's no browse-your-data tool. My support tooling shows account status, connection health and error states — not job names, not clients, not rates. Reading your content would mean a deliberate, manual query against the production database and a manual decryption using the application's secret key – and even then, on an account with encryption on, what surfaces is who you're shooting for and when, not what you charged for it.
2. Every direct database access is logged. Production database sessions are audit-logged. Direct access to the production database would only ever happen as the result of a data repair or disaster recovery operation.
3. It's in the contract. The Data Processing Agreement commits me to the access rules above.
I never use platform data for my own freelance work, rate-setting, or client acquisition, and never produce cross-user analyses of rates, clients, or bookings. Your day rate is not my market research. Beyond the handful of suppliers listed below — who process data only to keep Silo running, never for their own ends — your data is never disclosed to anyone.
What I will never do
- Sell your data, or share it with advertisers
- Train AI models on your job data — mine or anyone else's
- Build "market rate insights" from what users charge – with encryption on, I couldn't read your rates even if I wanted to
- Look at your account detail unless under your express consent to resolve an issue
Third parties
The full list of companies that process data on Silo's behalf is short, and it's in the Privacy Policy: Hetzner (hosting, Germany), Google's Gemini API (used for call-sheet extraction, receipt and serial-photo reading, and the text-parsing helpers that categorise expenses, map imported CSVs and read calendar titles), Meta (WhatsApp Business Platform — receiving paperwork, job details and receipts sent to Silo's WhatsApp number, and delivering our replies), Resend (email), Sentry (error monitoring), Stripe (billing), Cloudflare (traffic security), and Apple, whose iCloud Mail hosts the mailbox behind [email protected] — so anything you email me sits there. That's it. Everything else — Drive, Dropbox, OneDrive, Xero, your calendars — is your own account, connected by you, revocable by you.
Found something?
If you find a security issue, email [email protected] and I'll take it seriously and reply like a human — because I'm the one reading that inbox. If Silo ever has a breach that affects you, you'll hear it from me directly, not from a news story.
Questions about any of this: [email protected]. The legal versions live in the Privacy Policy and DPA — this page is the plain-English one, but I hold myself to both.