Privacy policy

The short version

Vyntic is a two-person software studio in Ontario, Canada, run by Hussein and Ali. This page describes what happens to information about you when you use vyntic.co. We collect what you type into our forms (your name, your email address, and what you tell us about the project) so a person can read it and write back to you. It is stored in one database, hosted in Canada. We store a one-way hash of your IP address to stop the forms being flooded; we do not store the address itself. We do not sell anything about you, we run no advertising, and we do not track you across other websites. If you would rather we did not hold it, email ali@vyntic.co and we delete what we can. The deletion section below says exactly what that covers and what we have to keep.

Who is responsible

Vyntic is two people: Hussein and Ali. Ali is accountable for your information, and Ali answers privacy requests.

We do not publish a postal address or a phone number. Email is how to reach us. General questions go to hello@vyntic.co. Privacy requests go to ali@vyntic.co, which reaches Ali directly.

What we collect, and when

Nothing about you enters our database until you type something into a form or sign in. We keep no log of what you read. Our host does, and that is described below.

When you send us a project request

The request form requires five things: what kind of build it is and how far along the idea is, both picked from a fixed list, then your name, your email address, and a description of what you want built. Your company name, a budget and a deadline are optional free text.

We also record which language the page was in, so we reply in that language, and a hash of your IP address.

There is no phone field on this form and no address field.

What you send becomes one record in our database. It is not copied into a CRM, a mailing tool or a marketing list. None of those exists here.

The form carries a hidden field that people never see and automated scripts fill in. If it arrives filled, the submission is discarded immediately. Nothing is stored, and no email is sent.

When you join the Vyntic Sites waitlist

The waitlist asks for your name, your email address and your industry, all three required, plus a three-way answer about whether you have a site today, which is always sent. A business name and a note are optional.

It is a different form, but not a different list. Your answers are combined into the message field of the same kind of record as a project request. There is no separate mailing-list database.

When you ask about a Vyntic Sites template

This form asks for your name and email address, and optionally a business name, a phone number, and a note.

This is the only form on the site that asks for a phone number, and it is optional. Because the record has no phone column, the number you give is stored as a line inside the message text.

When you use the site configurator

If you build a draft site with the configurator, you type real details about your business: business name, city, tagline, phone number, email address, street address, opening hours, your services or dishes and their prices, and short text about the business. This is the most detailed information the site collects from anyone who does not have an account.

Your answers reach us only when you act: once when the draft is created, and again each time you ask for a preview. Nothing is sent while you type.

The draft is stored with the template you chose, the language, and an IP hash. If you then send us a request about that template, we attach the draft to it, so we do not ask you for the same details twice.

When you create an account

An account needs a name, an email address, and a password of at least eight characters. Your email must be confirmed before the account works.

The password goes from your browser to Supabase Auth, our authentication provider. It never reaches our own systems. There is no password column in our database and no code of ours that receives one.

Your account record holds your name, your company, your language, an avatar image address, and your role. Once you are invoiced, it also holds a Stripe customer reference.

If you sign up with the same email address you used earlier on a form, those earlier submissions are automatically attached to your account and become visible to you in the portal. The match is on the email address alone.

A request sent from inside your account is stored in the same way as one sent from the public site.

When you open a support ticket

Support tickets require an account. You cannot file one as an anonymous visitor.

A ticket stores a subject, an urgency, a category, an optional project, and your message. The subject and the message are stored as separate records, and every message is attributed to the account that wrote it.

You may attach one file up to 4 MB, in PNG, JPEG, WebP or PDF format. Attachments go to private storage. Only you and the studio can get at them: each view generates a link that works for ten minutes and then stops.

When you reply to a ticket, the system sends us an email about it. It carries the ticket subject, not the text of your message. Like every other email described here, none is delivered until our email provider is switched on.

Your IP address

We do not store your IP address.

When you submit the request form, or create a configurator draft, we read the address from the request headers, add a salt, hash it with SHA-256, and store only the resulting hash. The address itself exists in memory for the length of the request. We never store it and never log it.

On the request form the hash has one use: counting. The form allows at most three submissions from one email address and eight from one IP hash in any ten-minute window. A configurator draft stores the same kind of hash so we can stop that form being flooded if we need to, but nothing counts against it today. The hash is not used for location, profiling, advertising or identification, and we record nothing else about your connection ourselves.

Two caveats. The headers do not always yield an address; when they do not, no hash is stored and the count is skipped. And the salt is a value in our code rather than a secret held elsewhere, so we will not claim the hash can never be reversed. We do not store the address, and we use the hash for nothing but rate limiting.

Why we collect it

• To read your request and write back to you.
• To scope, quote, and deliver work you ask us to do.
• To run a project you have engaged us for: updates, invoices, support tickets, meetings.
• To reply in the language you were reading in.
• To stop the forms being flooded.

That is the whole list. We do not build profiles of visitors. The forms say your answers are used to answer your request and nothing else. That is the limit, and this page does not widen it.

There is one list on the site: the Vyntic Sites waitlist. It exists to send one message, when setting up a site yourself becomes available. Email us and we take you off it.

Who else sees it

Inside Vyntic

Two people: Hussein and Ali. Nobody else works here.

We can export the enquiry list as a spreadsheet (name, email, company, request type, status, date) to read and keep track of the requests we have received. Every export is written to an internal log.

Supabase: the one service that holds your data today

Supabase provides our database, our sign-in system and our file storage. Everything described above is stored there. The project is in the ca-central-1 region, which is in Canada.

Account emails (confirming your address, resetting your password) are sent by Supabase's own email service.

Vercel: hosting

The site is served by Vercel. It receives your IP address, your browser's user-agent and the address of the page you asked for. A page cannot be delivered without them. What it keeps, and for how long, is set by Vercel and described in Vercel's own privacy policy, not ours. We are not going to state a retention period we have not verified.

If we move hosting, we will update this page.

Services that are built in but not switched on

The site is wired to five other services. None of them is configured on the live site today. That means none of them is receiving anything from the live site. We list them because they are part of the system and because we will turn some of them on.

• Resend: sends email on our behalf. When it is on, it receives the address a message is going to, the first name in it, and the text of the message we send you. Our emails are plain text, so there are no tracking pixels in them. Until it is on, the confirmation email the forms describe is not delivered. Your submission is still stored, and still read by a person.
• Stripe: issues and collects invoices when a client is invoiced. Stripe receives your email address, your name, and an internal reference linking you to your Vyntic account. Card details are entered on Stripe's own hosted page and never reach us; we hold no card number and no payment method. We store the invoice amount, currency, status, due date and the links to it. Stripe keeps its own record of the transaction, which our deletion does not reach.
• PostHog: product analytics, hosted in the EU. It is not configured and has never captured an event. If it is enabled, it would record page views (including the full address of the page you are on, with any query string) and a fixed list of named interaction events such as opening the request form or moving to the next step. Our own analytics events carry no form contents: your name, email, phone and message go to our database and are deliberately kept out of every event we send. It would set a cookie lasting about a year plus matching browser storage. After you sign in, earlier activity on that device would be linked to your account through an internal account identifier, not your email address. Whether session recording is switched on is a setting inside a PostHog account rather than something our code decides, so we will not promise you it is off.
• Sentry: error monitoring. It is disabled without configuration. If it is enabled, it would receive technical details of errors. Session replay is set to zero in our code, and we attach no name, email or account identifier to error reports.
• Cal.com: meeting booking, shown inside the client portal when configured. It is embedded, which means your browser connects to Cal.com directly and Cal.com sees your IP address and browser independently of us. If you book, it passes us the attendee's email address and the meeting time, and the booking details are emailed to the studio.

All five of these would process data outside Canada. PostHog is in the European Union; the others are hosted elsewhere and we will name the country for each one here before we switch it on. Our database is in Canada. That is not the same as all your data staying in Canada.

No AI model receives what you type

The configurator has a feature that would generate written copy for a draft site. The code that would send anything to a model provider is not written, and no provider is configured. Nothing you type is sent to an AI model. If we ever add that, this page changes before it is switched on.

What your browser loads

As the site runs today, the public pages load no third-party scripts, fonts, images or embeds. Fonts are served from our own domain. Maps appear as links you can choose to follow, not as embeds. Demo photography is hosted by us. There are no advertising scripts and no social widgets.

Cookies and browser storage

There is no cookie banner on this site, because there is nothing on it to consent to yet. Everything the site stores in your browser is either required to do something you asked for, or a preference you set yourself. If analytics is ever turned on, that stops being true, and this page will change before it does.

Cookies

• vy_sd: set only if you use the site configurator. It holds an opaque identifier for the draft you are building, and nothing else. It lasts 30 days, is not readable by scripts, and is marked secure on the live site. It is also the only thing that proves the draft is yours: the preview page and the update endpoint both check it, and the request form reads it to attach your draft to your enquiry. Clearing it makes the draft unreachable from that browser, but the draft itself is still stored until we delete it. Anyone holding that cookie can see the draft; there is no account behind it.
• sb-…-auth-token, plus numbered continuations of it: set when you sign in. It holds the sign-in session itself, not just an identifier. It is written by your browser when you sign in and refreshed by our server on later visits, and can last up to 400 days.
• sb-…-auth-token-code-verifier: a short-lived cookie used while confirming your email address or completing a sign-in. It is removed when the exchange completes. Sign-in cannot work without it.
• NEXT_LOCALE: the language you are reading in. It is written only when your language differs from the page you asked for, or when you switch language, and it lasts for the browser session. If your browser is set to English and you land on an English page, you do not get one.

If you never sign in, you never receive a sign-in cookie, and the site does no sign-in work for your visit at all.

Those are the only cookies the site's own code and libraries set. A site you follow a link to (Stripe's payment page, for example) may set its own; that is that site's doing, not ours, and it happens after you leave.

Storage on your device

These are not cookies and are never sent to us. They stay in your browser and clearing your site data removes them.

• vy-theme: your light or dark choice, if you press the toggle.
• tpl-scheme: the same choice for template demos and previews, kept separately.
• vy-intro-seen: so the opening animation plays once per browser session. Cleared when you close the tab.
• vy-standby-sprite-failed: remembers that an image failed to load, so the fallback holds for the session.
• vy-immersive: written only if you visit using a special address containing an immersive parameter. Cleared when you close the tab.

The site uses no service worker, no offline database and no offline cache.

How long we keep it

Almost nothing is deleted automatically, and we are not going to publish a retention schedule we have not built.

Requests, waitlist entries, template enquiries, configurator drafts, accounts, tickets, ticket messages, invoices, meeting records and our internal action log are kept indefinitely. Nothing expires them and nothing deletes them on a schedule. If you want yours gone, ask and we delete it.

The only automatic deletion anywhere in our system removes website uptime-check results older than 90 days. Those are technical records about client websites, not about people.

A configurator draft has no expiry either. The cookie that reaches it expires after 30 days, which is a different thing: after that the draft is unreachable from your browser, but the stored answers remain until deleted by hand.

If we introduce real retention periods, we will publish them here.

How it is protected

• Form submissions are written by our server, not by your browser. The browser is never given a key that can read or write stored requests, and anonymous access to those tables is refused by the database itself.
• Every table holding personal data has row-level security enabled. A signed-in client can read only their own requests, projects, invoices, tickets and meetings. That is enforced by the database, not by the screens we draw.
• Configurator drafts are readable by no browser at all, signed in or not. Only our server can read them, and the preview page returns a not-found response to anyone whose cookie does not match.
• Passwords never reach us. They are handled entirely by Supabase Auth.
• Support attachments are stored privately and served through links that expire after ten minutes, generated per view.
• IP addresses are salted and hashed, as described above, and used only for rate limiting.
• Connections use HTTPS. We send strict transport security, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and a referrer policy that gives a site you click through to only our domain, not the page you were reading.
• We also run a content security policy in report-only mode. It records what would have been blocked, and blocks nothing. It does not protect you yet, so we do not count it as protection.
• Actions taken on client records inside the platform are written to an internal log that cannot be edited or deleted through the application.

We make no claim about encryption at rest, because that is a property of our database provider that we have not verified ourselves. We hold no security certification.

The software restricts access by role. Vyntic is two people and both hold the owner role, so today that separates nothing. Hussein and Ali can each see every client account detail the platform holds.

Your rights, and how to use them

Under Canada's Personal Information Protection and Electronic Documents Act (PIPEDA) you can ask us for a copy of what we hold about you, ask us to correct it, withdraw your consent, and ask us to explain what we do with it. PIPEDA does not give a general right to erasure, but we delete what we can when you ask. The deletion section below sets out what that covers.

The mechanism is one thing: email ali@vyntic.co. There is no privacy control inside the product. The client portal has no account settings page and no delete button, and signing out ends your session without deleting anything. Every access, correction and deletion request is handled by a person, by hand.

The one thing you can do yourself is reset your password from the sign-in page.

We reply within 30 days of receiving your request, which is the period PIPEDA sets for access requests.

To protect the records, we may ask you to confirm that you control the email address they contain. We will not tell anyone else whether a given address has an account with us.

Access

We compile it by hand and send it to you. The portal is not a complete answer: it lists your requests by type, status and date, not the text you wrote, and internal notes on a project are deliberately not shown to clients.

Correction

Tell us what is wrong and we change it. There is no self-service editing of your details today, even though the account holds them.

Deletion: exactly what it does and does not remove

• We delete the records you point us at, directly, by hand.
• Deleting an account removes your support tickets and every message in them.
• Deleting an account does not by itself remove the enquiry you first sent. That is a separate record holding your name, email, company and description, and we delete it separately when you ask.
• Files you attached to a support ticket are removed separately, by hand. They do not disappear with the ticket.
• Project, invoice and meeting records are kept, detached from your account, because we need a record of work done and money invoiced.
• Our internal log of actions taken on records holds before-and-after copies of what changed, and it is not deleted.
• If you have been invoiced, Stripe holds its own record as the payment processor, and our deletion does not reach it.

Withdrawing consent

Email us and we stop. For the Vyntic Sites waitlist there is no unsubscribe link, because there is no mailing list. Your entry is a stored request like any other, and removing you means deleting that record.

Children

This site is for businesses. Nothing here is aimed at children, and we never ask anyone for a child's details. If you believe a child has sent us something through this site, email ali@vyntic.co and we will delete it.

Changes to this policy

A published version of this policy cannot be edited. Changing it means publishing a new version with a new date, and the version number and date appear at the bottom of this page. The text you are reading is the text that was published on that date.

If we turn on anything that changes what is collected or who receives it (analytics, error monitoring, email sending, booking), we update this page first, not afterwards.

How to complain

Email ali@vyntic.co and say what is wrong. We answer within 30 days.

If you are not satisfied with our answer, the Office of the Privacy Commissioner of Canada oversees PIPEDA and accepts complaints: priv.gc.ca. You do not need our permission to complain, though the Commissioner may ask you to raise the matter with us first.

If you are in Quebec, Alberta or British Columbia, your province has its own private-sector privacy law and its own regulator, and you can complain there instead.