What stays private, stated plainly.
You're being asked to put your practice's specifications into software built by a landscape architect who works in your profession. It's fair to want this in writing.
Private to your practice. Always.
- Specifications and master spec history
- Field notes and the reasons behind changes
- Project records, drawings and documents
- Clients, their comments and their approvals
- Pricing, suppliers and hours
- Photographs and uploaded images
No other practice can see any of it. Access is scoped to your practice at the database row level rather than checked in application code — so an ordinary mistake in a page or an API route returns nothing rather than somebody else's records.
That is a meaningfully stronger position than application-level checks. It is not a guarantee, and I won't describe it as one: a mistake written into a policy itself, or a leaked administrative key, would still be a mistake. What I can tell you is that the wall is in the database, that it is tested adversarially on every change, and that I will tell you plainly if it ever fails.
Never sold, at any price.
Nothing identified to your practice is ever provided to a manufacturer. No manufacturer will ever be told which practice specified which product.
Search results and library ordering are never purchasable. A verification badge means a manufacturer maintains its own data; it never affects position in a list. That door is closed, and it is a one-way door — reopening it would make every recommendation in the library worthless, including the honest ones.
Shared only when you raise it.
Flags travel — and only flags, and only when you choose to raise one. A lead time that slipped, a plant that failed in clay. Other practices see it, confirm it, or contest it, which is what makes it worth more than a note to yourself. You can keep a flag private to your practice instead, and it still works on your own records.
Counts like specified on 89 projects are aggregate across the whole platform, never traceable to a practice, and computed from a product and a number — never from a note, a reason or a project name. Founding practices are opt-in, not opt-out.
Who I can see.
I hold production credentials. Every software vendor does — you cannot back up or support a system you cannot reach, and anyone claiming otherwise is describing something that doesn't work.
What constrains it: a written commitment not to access practice content except at your request, to investigate a fault you have reported, or where compelled by law. Support access is logged with a reason, and you can ask for that log. Usage analytics record events, never content.
What I don't have and won't claim: a SOC 2 report of my own, an independent penetration test, or round-the-clock monitoring. Those are on the list, not in the past.
Where it lives.
Folii runs on Supabase, which is SOC 2 Type 2 compliant and ISO 27001 certified. Data is encrypted at rest with AES-256 and in transit over TLS, hosted in verify · region, backed up daily.
Sub-processors: Supabase (database, authentication, storage) · verify · host · Stripe (payments — billing data only) · verify · email provider. This list is published, and current practices are told before it changes.
You can leave with everything.
Full export, any time, yourself — library records, specs and version history, notes and flags, palettes, project records, documents. Open formats. Not a support request; a button.
You own what you put in. Folii claims no ownership and no licence beyond running the service for you. After cancellation your data stays exportable for verify · 90 days. If Folii is ever acquired or ceases to operate, you get no less than verify · 90 days notice and a working export first.
The argument for staying should be that it's useful. Not that leaving is hard.
Something wrong?
verify · security@folii.com — reported in good faith, answered within a business day, and no researcher pursued for telling me.
Not for publication until reviewed
This page makes commitments about access, retention, notice on acquisition and sub-processor disclosure. Those are contractual undertakings, not marketing copy, and they need a lawyer's eye before they go live — particularly the acquisition and retention clauses, which are the ones a customer would later hold you to. Every amber marker above is a fact only you can confirm.