Vulnerability Disclosure Policy

Effective October 20, 2026

Daywright is scheduling and operations software for inspection businesses, made by Fine Folk LLC (“Fine Folk,” “we,” “us”). We would much rather hear about a security problem from you than find out about it some other way. This page says how to reach us, what we will do with your report, and what research we authorize.

How to report

What to put in a report

• Where the problem is: the host, URL, or screen.
• What someone could do with it, and how you know that.
• Enough detail for us to reproduce it, including the accounts or requests you used.
• Anything we should be careful about while we look into it.

One finding per email, please. It keeps each one traceable.

What we will do

• Acknowledge your report within three business days.
• Tell you whether we could reproduce it, normally within ten business days.
• Keep you posted while we work on it, and let you know when the fix ships.
• Credit you by name once it is fixed, if you would like that.

We do not pay bounties. We are a small company, and we would rather be straight about that at the outset than leave you guessing.

What this policy covers

This policy covers the Daywright website at daywright.io, the Daywright application at app.daywright.io, the demo at demo.daywright.io, and the other services we run on daywright.io subdomains.

Parts of Daywright run on third-party providers: Stripe and Authorize.net for payments, Twilio for SMS, and Google for the optional calendar connection, among others. Those companies run their own disclosure programs, and a problem in their systems should go to them rather than to us.

Research we authorize

Our terms of service ask you not to probe or test the security of Daywright without our written permission. This page is that permission, for research that stays inside it. If you act in good faith and follow this policy, we will not bring a legal claim against you over it, we will not ask your hosting or network provider to act against you, and if someone else raises the question we will say plainly that your testing was authorized.

Staying inside it means:

• Use only accounts and data that belong to you, or test accounts we have given you.
• Stop as soon as you can demonstrate the problem. Do not read, change, keep, or pass on another company’s data, and tell us straight away if you reach it by accident.
• Do not degrade the service: no denial-of-service, no load or stress testing, and no automated scanning heavy enough to affect anyone else.
• Leave people out of it: no phishing or social engineering of our staff, our customers, or their clients, and nothing physical directed at our offices or hardware.
• Give us a fair chance to fix the problem before you discuss it publicly. Ninety days is our default. If you need to move sooner, tell us and we will work it out with you.

If you are not sure whether something is in bounds, ask us first at security@daywright.io. We would rather answer the question than have you guess.

Reports we usually close

Findings with no route to real impact tend to get closed: unverified output from an automated scanner, a missing header or cookie flag on its own, software-version banners, configuration findings on hosts that serve nothing, and issues that need a browser or device the attacker has already taken over. Send them anyway if you believe the impact is real. Just show us the impact along with the finding.

Changes to this policy

If we change this policy, we will update this page and the date above. The machine-readable version of our security contact details lives at /.well-known/security.txt, per RFC 9116.

Contact

Security reports: security@daywright.io. Anything else: hello@daywright.io.