Privacy Policy

The short version

Sub40 is a sublease noticeboard for UT Austin students, run by two people in the United States. Here is the whole policy in six lines, each of which is expanded on below.

• We collect what you type in (your UT email, your profile, your listings, and your messages) and not much else.
• There is no advertising, and we do not sell your data. Product analytics (PostHog) runs only when we have turned it on for a deployment; it is off when those keys are unset.
• Your exact street address is not public. Signed-out visitors see a deliberately fuzzed pin and a building name.
• Your messages are readable only by you and the person you are talking to.
• Listing photos are the exception, and it is an important one: they sit in public storage, so anyone with the direct link can open one. Your profile photo does not. Read section 6.
• You can see, correct, or delete your data. Ask us through the contact form.

1. Who this policy is from

Sub40 is a student-to-student sublease marketplace built for UT Austin, and only for UT Austin. It is a two-person project, not a company with a privacy department, and it has not launched yet.

The legal entity responsible for your data under this policy is Sub40 LLC, a Texas domestic limited liability company (SOS file 806723546, effective July 30, 2026). Formal legal notices to Sub40 go by mail to the registered office at 10601 Clarence Dr, Suite 250, Frisco, TX 75033 (United States Corporation Agents, Inc.), or by email to support@thesub40.com.

Sub40 is operated from the United States and its data is stored in the United States. It is built for students at one campus in Texas, and it is not aimed at people outside the US. If you use it from somewhere else, your information is handled here, under US law.

2. What we collect, and why

Almost everything here is something you typed. We do not buy data about you, and we do not build a profile of you from anywhere other than what you enter and what you do on the site.

Your account

• Your UT email address. It is required, and it is the whole basis of the "verified student" idea: signup is checked on the server against a list of UT domains (utexas.edu, my.utexas.edu, and eid.utexas.edu), and an account with an address outside that list does not get created.
• A password, or nothing at all if you sign in with a link emailed to you. We never see your password in readable form; our authentication provider stores a hash of it, not the password itself.
• Your name, and optionally a bio, a phone number, a graduation year, and a profile photo. Only the email is required. Everything else is there so another student can tell who they are talking to, and you can leave it blank.
• Three notification preferences, which is simply a record of which emails you asked us to send.
• Which school your account belongs to (currently there is only one).

Your listings

• The title, price, unit type, lease start and end dates, description, amenities, and photos you enter.
• The street address you enter, plus the latitude and longitude derived from it, plus a normalised version of the address and, where we have it, the building name. Section 5 explains exactly which parts of this a stranger can see, because the answer is not all of them.
• The listing’s status (whether it is awaiting review, live, rejected, or leased) and, if it was rejected, the reason.

What you do on the site

• Listings you bookmark, and any note you attach to a bookmark.
• Messages you send, including the text, who they were between, which listing they are about, and when they were read. Messages are capped at 4,000 characters.
• Reports you file about a listing: the reason, any detail you write, and the outcome once we have looked at it.
• A small amount of bookkeeping about whether a notification email has already been sent to you, so we do not send it twice.

When you write to us

• What you type into the contact form: your name, an email address, which subject you picked, and the message itself, which is capped at 4,000 characters. The form works signed out and does not require a UT address, so the email you give may be the only way we have of answering you.
• A link to your account, if you happened to be signed in when you sent it, so we can see who wrote in without having to ask.
• A salted hash of the IP address the message came from. We store the hash and never the address itself, and it is used for exactly one thing: rate-limiting the form so that one person cannot flood it. It is not shown to whoever reads your message.

When you and another student paper a sublease

• Everything typed into a sublease agreement: both parties’ legal names and contact email, the full street address of the place, the term, the rent, the deposit, who pays which utilities, and any house rules written in. This is the one part of Sub40 that deliberately holds the exact address rather than the fuzzed one: an agreement with an approximate address in it would be useless to the two people relying on it.
• The generated PDF, in private storage. Unlike listing photos, which sit in a public bucket, this one has no public link and no direct access of any kind. Only the two parties can open it, and only through a link that expires in five minutes.
• When each of you clicked Acknowledge, and (this is the exception to everything above) the IP address and browser that did it, kept in full rather than hashed. An acknowledgement with no provenance is not a record of anything, which is the whole reason that step exists. It is used for nothing else: not analytics, not rate limiting, not linking you across the site.

Technical information

Our hosting and database providers keep server logs in the ordinary course of running a website, which typically include IP addresses and browser information. We do not use those logs to build a profile of you. Separately, when PostHog is enabled for a deployment, the browser sends page-view and product-usage events (pageviews plus autocapture) to PostHog; when it is not enabled, that path does not run. The exact retention of ordinary provider logs is set by the providers, not by us.

3. What we do with it

• Run the service: show listings, run search, deliver your messages, keep you signed in.
• Keep the UT-only gate honest, which is the entire point of collecting a school email.
• Review listings before they go live, and act on reports, which sometimes means reading a specific listing or a specific conversation.
• Send you the emails you asked for: message notifications, and the authentication emails you need to sign in at all.
• Read and answer what you send through the contact form, including access and deletion requests.
• Generate a sublease agreement when two of you ask for one, and keep the record of who acknowledged it and when.
• Fix things when they break, and keep the site secure.

We do not sell your personal information, and we do not share it for advertising. There is no advertising on Sub40.

We do not use your messages or your listings to train machine-learning models.

4. The emails we send

Two kinds. Authentication emails (confirming your address, sign-in links, password resets), which you cannot turn off, because without them you cannot get into your account. And notification emails when someone messages you, which you can turn off in your settings.

Notification emails are written to give away as little as possible, on purpose. They contain no message text at all (not even a preview), and they use the sender’s first name only, never a full name, and never the listing’s address. Email gets forwarded, synced to phones, and sits in inboxes for years, so a conversation about where a student lives does not get copied out of the app into it. The message body is not even loaded from the database when the email is built.

5. What other people can see

This is the section worth reading properly. Listing pages are public and are indexed by search engines, which is how students find a sublease at all, but what a stranger sees is deliberately narrower than what a signed-in student sees.

A signed-out visitor, or a search engine, sees

• The listing itself: title, price, unit type, lease dates, description, amenities, and photos.
• The building name and the city, not the street address.
• A map pin that is deliberately wrong. The published coordinate is offset from the real one by up to about 200 metres, so the pin shows the neighbourhood without showing the door.
• That the host is a verified UT student. Not their name, not their email, not their photo, not their year.

The last point is enforced in the database rather than in the interface: a signed-out visitor has no read access to the profiles table at all, so a request for the host’s name is refused rather than quietly answered. The same is true of the exact address: the precise coordinates and the street address are simply not among the columns an anonymous visitor is allowed to read.

A signed-in UT student additionally sees

• The exact street address and the true map location.
• The host’s name, and whatever else they chose to put on their profile: bio, graduation year, phone number, photo.

So: anything you put on your profile is visible to any signed-in UT student who opens one of your listings. If you would rather not share your phone number with everyone who clicks, leave the field empty.

Nobody else sees

• Your messages. Only the two people in a conversation can read them.
• Your bookmarks. Only you.
• That you reported a listing. The report is not shown to the listing’s owner and they are not told who filed it. On one campus, a reporting system that exposes the reporter is a reporting system nobody uses.

One honest limitation on all of the above: this is our own data sitting in our own database, so we can technically reach it, and we may read a specific conversation to investigate a report or because the law requires it. We do not read messages routinely.

6. Listing photos are public: please read this one

The rest of the site restricts things carefully, so it would be easy to assume listing photos are restricted too. They are not, and telling you that plainly is more useful than a policy that implies otherwise. Practically:

• Do not upload a photo showing something you would not want a stranger to see: mail with your name on it, a visible unit number, documents, other people who did not agree to be photographed.
• A photo link keeps working while the file exists, even after the listing comes down. Deleting the listing does not by itself guarantee the file is gone.
• If you have already uploaded something you regret, ask us and we will delete the underlying file, not just the listing.

This one is a deliberate trade-off rather than an oversight. A listing page is public and is indexed by search engines, so its photos are already visible to anyone who opens the page; putting them behind expiring links would hide nothing and would break the preview image that appears when someone shares a listing in a group chat.

7. The companies that help us run this

Sub40 does not run its own servers. The list below is every outside service that touches your data, what it gets, and why. It is exhaustive as of the date at the top of this page.

Supabase: authentication, database, and file storage

Effectively everything: your account, your profile, your listings, your bookmarks, your messages, your reports, and your uploaded photos are stored with Supabase. If you want a single answer to "where does my data live", this is it.

Vercel: hosting

Serves the site. Requests to Sub40 pass through Vercel, which keeps the ordinary server logs any web host keeps.

Resend: email delivery

Sends the authentication emails, the message notifications, and the alert to our support inbox when someone writes in through the contact form, so it necessarily receives your email address and the contents of those emails. As section 4 says, the notification contents are deliberately thin. A contact message is not: what you type into that form is what we need to read in order to answer it.

OpenStreetMap Nominatim: turning an address into a map point

This one deserves to be spelled out. When you create a listing, the street address you type is sent to Nominatim, a service run by the OpenStreetMap Foundation, to convert it into coordinates and a tidied-up address label. That means the exact address leaves our systems at the moment you post, even though it is never published to signed-out visitors afterwards.

The same service is used when you type a destination into the commute tool on a listing page (for example your workplace or your lab), so that address is sent to Nominatim too.

OSRM and OpenFreeMap: routing and map tiles

The commute times and the route line on a listing page are calculated by OSRM at router.project-osrm.org, which receives the listing’s coordinates and your destination’s coordinates. The map imagery itself comes from OpenFreeMap, which receives the coordinates of the area you are looking at, in the normal way any online map works.

PostHog: product analytics, only when enabled

When NEXT_PUBLIC_POSTHOG_KEY and NEXT_PUBLIC_POSTHOG_HOST are both set on a deployment, the browser loads PostHog and sends page views plus autocaptured product usage (clicks and form submits). We do not turn on session recording in our client config, and we use PostHog's cookieless mode so it does not set analytics cookies. When either key is missing, PostHog is not initialized and nothing is sent. PostHog is a third party; what it stores is also governed by its own policy.

Stripe: not in use

Payments are not live on Sub40. No card details are collected anywhere on the site today and no payment processor holds anything about you. If paid listing promotion launches, this policy will be updated before it does.

Each of these companies has its own privacy policy governing what it does with what it receives. We chose them, so this list is our responsibility, and it changes only when the code does.

8. How long we keep things

The honest answer today is that no retention schedule has been set, and inventing one here would be worse than admitting it. What is true is that data you delete yourself (a listing, a bookmark, your account) is deleted from the live database, and that deleting an account cascades: the profile, its listings, its bookmarks, and its messages go with it.

Backups are the caveat that applies to any database. A copy of deleted data can persist in routine backups for a period after deletion, and that period is set by our database provider’s backup configuration rather than by us.

The specifics need deciding before launch, and they are separate decisions rather than one. [1] TO CONFIRM: how long is an account kept once it is inactive, and is it ever deleted automatically? [2] TO CONFIRM: how long are expired or leased listings kept after their lease end date? [3] TO CONFIRM: how long are messages kept: indefinitely, or deleted some period after a conversation goes quiet? [4] TO CONFIRM: how long are listing reports and their outcomes kept after they are resolved? These are records about another student, so keeping them forever is a choice worth making on purpose. [5] TO CONFIRM: what is the backup retention window at the database provider, so this page can state a real number for how long deleted data can survive in backups?

9. Your data, and how to get at it

Some of this you can do yourself, right now, without asking anyone.

• Correct your profile, or empty out any field you would rather not share, in your account settings.
• Edit or delete any listing you posted, from My Listings.
• Turn notification emails off in settings.
• Delete your bookmarks.

For the rest (a copy of everything we hold about you, deletion of your account and its contents, deletion of a photo file from public storage, or a question about how any of this works), ask us and we will do it. There is no bureaucracy to get through and nothing unreasonable to prove; we will just want to be confident you are the person whose account it is, which normally means the request coming from the UT email on the account.

The route is the contact form at /contact. Pick "Privacy or data request" from the subject list. That option exists so a deletion request arrives recognisable as a request with a clock on it, rather than sitting in the same pile as a suggestion about the search filters. What you send is recorded before any email is attempted, so your request does not depend on our outbound mail working, and it lands in a queue a person works through. The reply comes by email to the address you put in the form.

The form deliberately does not require you to be signed in or to use a UT address, because a student who has lost access to their utexas.edu inbox still needs a way to ask us to delete their account. If you write in from some other address, expect us to ask a question or two before we delete anything, for the reason in the paragraph above.

The published support mailbox alongside the /contact form is support@thesub40.com, the same address named in section 1 for formal notice. One timing question about this route is still open. [6] TO CONFIRM: how quickly do you commit to answering an access or deletion request? Pick a window you can actually hit with two people, and note that some state privacy laws impose their own deadline once they apply to you.

Texas has its own data privacy law, and whether it applies to a project this size depends on thresholds and on what the business ends up doing. That is a question for the review rather than something to assert here. [7] TO CONFIRM: does the Texas Data Privacy and Security Act apply to Sub40, and does the answer change once paid promotion launches? If it applies, this page needs a specific rights-and-appeals section rather than the general commitment above.

10. Your match profile

There is an optional quiz at /match. Answering it ranks the live listings for you and turns on a "For you" row on Explore. Optional means what it says: skip it and the site behaves exactly as it did before, and nothing gates on having answered it.

What the quiz stores

• A monthly budget range, as two numbers.
• Which term you need a place for: fall, spring, summer, or a full year.
• The longest walk to campus you would accept, in minutes.
• Up to three amenities in the order you ranked them, picked from the same list a host chooses from when they post a listing.
• Your greek chapter and any other organisations you typed, and where you put yourself on a five-point scale from quiet nights to people over. All of that is what you said about yourself; none of it is checked against anyone or anything else.
• An Instagram handle, if you chose to give one. This one is worth stating precisely: it is stored as the text you typed and nothing more. Sub40 does not open it, does not fetch anything from Instagram, and is not connected to Instagram in any way.

Hosts do not see them either. When a listing scores well for you, the score and the reasons for it are worked out for your screen and shown to you; nothing is sent to the person who posted the listing, and nothing about you is added to it. There is a column in the table for a future "share this with hosts" setting. It defaults to off, and in this version nothing anywhere in the product reads it.

Your answers never appear in a web address. The ranking is built from your row after you are signed in, so nothing about your budget or your chapter can be read out of a link you paste into a group chat, and none of it reaches the preview image a link unfurls into, which is fetched by crawlers holding no session.

The match notes you read are written by the site itself, out of the numbers it just worked out from your answers. There is an optional layer that would have an AI service phrase those notes instead, and it is switched off; turning it on would mean another company receiving your answers, so it means adding that company to section 7 and this page changing first.

Deleting it

There is a Delete button on /match, and it has been there since the day the feature shipped. It asks you to confirm once, and then the row is gone: all of it, immediately, with no request to send us and nothing kept behind the scenes. Every match surface goes back to how it looked before you answered anything, and you are free to answer again later.

11. Security, described accurately

What is actually in place: access to every table is restricted at the database level rather than only in the interface, so a request for data you should not see is refused by the database itself. Traffic to the site is encrypted. Passwords are stored hashed, by our authentication provider, and are never visible to us. The specific privacy behaviours described in section 5 (the host’s name, the exact address, message contents, reporter identity) are enforced there too, not merely hidden in the UI.

What is not in place, and should not be implied: Sub40 has no security certification and has never been through a SOC 2 or any other audit. We follow practices modelled on that standard, which is a deliberate choice and is not the same thing as having been audited. Our providers hold their own certifications; we do not inherit them.

No system is perfectly secure, and this one is built by two people. If the worst happens we will tell affected users, but this draft does not name a deadline for that, because a number nobody has committed to is not a commitment. [8] TO CONFIRM: how quickly does Sub40 commit to notifying affected users after discovering a data breach? Note that Texas breach-notification law sets its own deadline regardless of what this page says, so check that first and do not promise something slower.

12. Younger users

Sub40 is for university students and is not directed at children. Because an account requires a UT email address, in practice accounts belong to people connected to the university.

Some entering students are 17, which is why the age question is a real one rather than boilerplate. [9] TO CONFIRM: the minimum age for a Sub40 account. 18 is the usual answer in Texas because that is when someone can be held to a contract, but some first-year students are 17, so decide whether they are excluded, and say so consistently on the signup page.

If we learn we have collected information from someone below whatever minimum is set, we will delete it.

13. Changes to this policy

This policy describes the code as it exists on the date at the top of the page. It will change, and this draft is expected to change substantially before launch.

The rule we intend to hold ourselves to is simple: if a change to the product changes what happens to your data, this page changes at the same time, not later. Changing what PostHog captures, moving photos out of public storage, turning on payments, or adding any new company to the list in section 7 all count.

When something material changes, we will update the date at the top and give notice. [10] TO CONFIRM: how are users notified of material changes to these terms (an email to every account, a banner in the app on next sign-in, or notice on this page only), and how much warning do they get before the change takes effect?