GraceSoftGraceSoft

Privacy & Security

Private by design. Secure by default.

Privacy and security aren't features we add at the end. They're architectural decisions we make before the first line of code — in every GraceSoft product, to the very best of our ability.

The principles we build by

Each principle below comes with real examples from the products we're building — Concierge, Desk, QTap, Skylight and Light CMS.

Battle-tested foundations, never home-made

Writing your own framework, login system or encryption is one of the fastest ways to ship a vulnerability. We build on mature, widely audited tools like Laravel, and choose established hosting and payment providers, so the hardest security problems are handled by code that millions of people already rely on.

  • Desk, QTap, SkylightBuilt on Laravel, with its own Fortify and Sanctum packages for sign-in and API tokens rather than custom auth.
  • ConciergeCustomer details are encrypted with AES-256-GCM, an industry-standard cipher — no homemade cryptography.
  • SkylightPayments go through Stripe's hosted Checkout, so card numbers never reach our servers.

No tracking of customer behaviour

As far as possible, our products ship with no tracking scripts at all. If we ever need one, it exists so GraceSoft can see how its own software is performing — not to follow customers around our products, build profiles or sell attention.

  • gracesoft.devAnalytics are self-hosted, load only after you opt in, and are never shared with advertising networks.
  • SkylightError tracking reports crashes so we can fix them — and does nothing at all unless it's configured.
  • QTapFully self-hosted: the kiosk talks only to its own server, and respondents stay anonymous unless they choose to leave an email.

Users and admins kept apart

When a product needs people to monitor or manage it, we keep those admin accounts in separate tables from the people who use it. A mistake or flaw on the customer side can't quietly grant someone admin powers, and each side gets only the access it needs.

  • QTapAdmin accounts can only be created from the server's command line — there's no public sign-up to abuse.
  • ConciergeOwners, front-desk staff and customers each see a different app. Front-desk staff can't look up identities or read the audit log.
  • SkylightOwner, admin, member and viewer roles are enforced on the server, so viewers really are read-only.

No guessable IDs in your address bar

Inside the database we use simple numeric IDs. Anything that appears in a public URL uses a UUID instead, so nobody can guess the next record by changing a number. Human-readable slugs appear only where they genuinely help, such as page addresses in a CMS.

  • DeskEvery record is addressed by its UUID. Asking for a numeric ID returns a 404.
  • QTapEach survey's public link is a UUID that can be regenerated at any time, instantly killing the old link.
  • Light CMSPages get readable slugs, because that's where visitors and search engines genuinely need them.

Collect less, and keep it apart

The safest personal data is data we never collect. Where we do need it, we split it away from the records staff work with every day, so a shared screen, a calendar or an export doesn't leak who someone is.

  • ConciergeBookings and the shared calendar hold only a token, a service and a time. Names and phone numbers live in a separate, encrypted store — and the calendar can't accept a name, even by mistake.
  • QTapSurveys are anonymous by default. Email is optional, and consent is asked for only when someone gives one.
  • Concierge demoNothing typed into the public demo leaves the browser — it fetches open time slots and nothing else.

Encrypted where it matters

Sensitive fields are encrypted in the database, and secrets we only need to check — like share-link tokens — are stored as one-way hashes, so even a leaked database copy gives away as little as possible.

  • ConciergeEach business has its own encryption key. One business's key can't read another business's customers.
  • QTap, DeskRespondent emails, two-factor secrets, OAuth tokens, webhook secrets and API keys are all encrypted at rest.
  • SkylightShare links and invites are stored only as hashes, and IP addresses in the activity log are hashed too.

Every sensitive action leaves a trail

Seeing someone's personal details should be a deliberate act, not a side effect of opening a screen. Our products record who did what and when — without copying the sensitive data into the log.

  • ConciergeRevealing who is behind a booking needs a signed-in owner and a written reason, and is logged before the details appear. Only owners can read the log.
  • QTapPublishing, exporting and clearing responses are logged with only the action, user and time — no survey or personal data.
  • Desk, Light CMSChanges to financial records are logged with old and new values; Light CMS keeps an append-only activity log.

Strong sign-in, by default

Most breaches start with a stolen or guessed password. We make the second factor available everywhere, require it where the stakes are highest, and slow down anyone trying to guess their way in.

  • DeskThe admin must change their temporary password and set up two-factor authentication before any screen opens — and an automated test checks every route enforces it.
  • SkylightTwo-factor sign-in with recovery codes, emails for new-IP and suspicious logins, and a password check before sensitive actions.
  • QTap, SkylightLogin and two-factor attempts are limited to five a minute.

AI with guardrails

AI can be genuinely useful, but it shouldn't quietly ship your data to someone else. Where our products use AI, it's off until you turn it on, it sees as little as possible, and you can see a record of every request.

  • DeskAI is off by default. It never sees code diffs or author details, redacts emails and secrets before sending, and logs only a hash of each request.
  • DeskAny project can be excluded from AI entirely, and a local, self-hosted model can be used instead of a cloud provider.
  • ConciergeBusiness setup still works without an AI key, falling back to a simple keyword extractor.

Data that doesn't outstay its welcome

Data kept forever is data waiting to leak. Our products delete what they no longer need on a schedule, and give people a real way to take their data with them or leave for good.

  • ConciergeCustomer identities are deleted after a year without bookings (with a 7-day grace period); audit entries after two years.
  • SkylightExport everything you own as JSON and CSV, or delete your account with a 7-day change-of-heart window.
  • QTapA kiosk left idle for 30 seconds wipes any half-finished answers, so the next person never sees them.

Links that expire and can be revoked

A link that works forever is a liability. Downloads, previews and shared views use signed, short-lived or revocable links, so access ends when it should.

  • DeskInvoice PDFs and documents are served only through short-lived signed links.
  • SkylightClient share links can expire, be revoked instantly, are hidden from search engines, and attachments use five-minute URLs.
  • DeskIncoming Git webhooks are verified with each provider's signature before anything is accepted.

Hardened by default

Secure settings shouldn't depend on someone remembering to flip a switch. Our products launch with protective defaults already in place.

  • QTapA content security policy, clickjacking protection, strict referrer policy and HSTS on every response.
  • Light CMSA locked-down content security policy, sanitised rich text and private file storage — all on by default.
  • DeskMoney is stored as exact decimals, never floating point, and issued invoices can't be edited.

Careful about who we trust, too

We hold the services we depend on to the same standard. Our subprocessor list names every third party that may handle your data, what they do, and why we chose them.

View our subprocessors

What we're honest about

GraceSoft is a small, independent studio, and most of these products are still in development. We haven't been independently audited or certified yet — so we won't claim to be. What we can promise is that every decision on this page was made on purpose, and that we'll tell you plainly what is and isn't finished.

As GraceSoft grows, we plan to put our products through rigorous third-party testing and earn formal security certification.

  1. 01 · Today

    Every product is built to the principles on this page, reviewed by the developer who wrote it, and — wherever we can — backed by automated tests that check its security rules.

  2. 02 · Next

    Independent penetration testing of our products by a qualified third party, with findings fixed before general release.

  3. 03 · Later

    Formal security certification, so you can rely on an outside auditor's word — not just ours.

Found a problem, or have a question?

If you think you've found a security issue in a GraceSoft product, or want to know more about how we handle your data, we'd genuinely like to hear from you.