Hardpark

Privacy Policy

Last updated 12 August 2026

Hardpark has no account, no sign-in, no email address and no password. You never tell us your name. To render your car, your photo does have to leave your device and reach an image model — so this policy is mostly about that one journey: what is stripped out of the photo before it goes, who touches it, how long anything survives, and what we keep afterwards. For most of what we keep, that is numbers rather than pictures — the one exception is a rendered image itself, briefly, and it is explained in its own section below.

The photo, step by step

This is the part that matters, so it is written out in order rather than summarised.

On your device, before anything is sent. The photo you capture or pick is resized down to roughly one megapixel and re-encoded as a new JPEG. That re-encode is also what removes the metadata: EXIF, camera information, timestamps, and — the one that actually matters — GPS coordinates. A photo of a car is usually a photo taken on a driveway, and the location tag is the most sensitive thing in the file. It is removed before the photo leaves your phone, not after it arrives somewhere.

That resized copy is also the one the app keeps, so your car — or cars, if you've added more than one to your garage — is still there the next time you open Hardpark. Each car gets one file, in Hardpark's own storage on your phone; retaking a car's photo overwrites that car's file, there is never a history of them, and each is independent of the others. Every one of them is marked so that iCloud and iTunes/Finder backups skip it, which means none of them travel to Apple or onto a new phone, and all of them are deleted along with the app. You can remove any of them whenever you like, from the app's Settings: with one car, Forget my car deletes it from the phone immediately; with more than one, Manage your cars lets you remove, rename or switch any of them individually. Choosing a different photo for a car also overwrites that car's file, and deleting Hardpark takes all of them with everything else the app stores. The photo you picked is never itself copied out of your photo library — what is kept is only this shrunken, location-stripped version of it.
In transit. The resized, stripped photo is sent over an encrypted connection to Hardpark's server, which runs on Cloudflare Workers.
On our server. The photo is held in memory for the length of a single request and forwarded to the image provider. It is never written to any storage we operate. There is no bucket, no database column, and no log line containing your photo — we did not build one, so there is no copy of your original photograph anywhere on our side to leak, retain, or fail to delete.
At the image provider. The photo is sent to fal.ai, the service that runs the model doing the actual render. It is sent inside the request itself rather than uploaded as a file, and every request carries a header that switches off fal's default behaviour of retaining request payloads for 30 days. We verified that both of those things do what they say before shipping.

The result of all of this is the strongest claim in this policy and the one we are most confident in: no copy of your original photograph is ever stored off your device. Not on our server, not at the image provider, and not in any backup of your phone. The one copy that does persist is the resized, location-stripped one described in the first step above, it lives on your phone only, and it is there so the app remembers your car. The finished render — the picture Hardpark generates — is a separate thing, described next, and it does leave your device for a while.

The render, and how long it lasts

What happens to the finished render — your car with the mods applied — depends on which quality tier made it. Both are described here rather than smoothed into one sentence, because they behave differently.

Standard-tier renders are held on fal's content network, locked so anonymous requests cannot read them, for 24 hours, then permanently deleted. We ask for that lifetime explicitly on every single request; it is not a default we are hoping holds. Our own server never stores a copy of a standard-tier render — it fetches the locked image from fal each time you view or share one, and passes the bytes straight through without keeping them.

Premium-tier renders work differently. The image model Hardpark uses for premium hands the finished image's bytes back to us directly, rather than hosting them at an address the way the standard model does. That means our own server briefly holds a copy of the rendered image itself — the same database row that tracks the render holds the picture, not just a pointer to one. An automatic cleanup job clears it out on a nightly schedule: in practice that is usually close to 24 hours after the render was made, and it is never later than 48 hours from when the render was created, which is the outside bound the once-a-day schedule sets.

Either way, the app never receives an address it could leak: images are fetched or read through Hardpark's own server, which checks that the render belongs to the device asking for it. When you share a render, the app hands over the image itself rather than a link, so nobody ends up passing around a live URL that points at a picture of your house.

The lifetime above is how long the render survives off your device — on fal's servers, or briefly on ours. It is a deliberate balance, not a technical maximum: long enough that a phone which died overnight can still collect the render in the morning, and short enough that the window in which anything can go wrong is a day or two rather than forever. Once it expires there, it is gone from both places and we cannot bring it back. It is a separate question from whether a copy already made it onto your own phone — the next section covers that.

Your build gallery

Every render you complete is also added to a build gallery inside the app — a history of your past builds, separate from the render's own temporary lifetime described above. The gallery lives only on your phone. It is a folder in Hardpark's own storage (Application Support/Hardpark/Gallery/), never uploaded anywhere and never read by our server or anyone else. Each entry records which mods you picked, which car and category it was for, and — for as long as the render itself hasn't expired and you had it open — the image. Like the car photos described above, the gallery folder is marked so that iCloud and iTunes/Finder backups skip it, and on iOS its files are encrypted at rest by the device the same way the car photo is.

The gallery has no expiry of its own — entries stay until you remove them. You can clear the whole thing at once from Settings: Clear build history deletes every entry from the phone immediately. It is a separate control from Forget my car and Delete my data, deliberately: your build history, your car photos and your server record are three different things, and clearing one does not touch the other two. Uninstalling Hardpark removes the gallery along with everything else the app stores.

What we actually keep

Mostly numbers, tied to a device rather than a person — with one exception, described in the render section above: a premium-tier render's own image bytes sit in our database temporarily, until the nightly cleanup clears them. Everything else below is exactly that — numbers:

A pseudonymous identifier. When the app first contacts our server it presents an identifier that Apple's App Attest generates on your device. We store that identifier, a random id of our own, and the date the record was created — not your Apple ID, not your name, not your email, not your phone number, and nothing you could be looked up by.
Details of each generation: which mods you picked, which quality tier and model ran, image sizes, what it cost us, timestamps, its status, and — while the render exists — either the address it can be fetched from (standard tier) or the render itself (premium tier, see above).
A credit ledger: credits added and spent, and what each entry was for. This is a financial record.

Outside of a premium render's temporary window, none of these hold, or can be turned back into, a picture of your car.

Rate-limit counters, and IP addresses

Requests are counted so that no single source can exhaust the service for everyone else. A counter is one row: a subject, which request it counts, a time window, and a number.

There are two kinds of subject, because a request may arrive before there is any identity to attach it to. Before that point — when the app first asks our server for a session — the counter is keyed on the network address the request came from, shortened to its network prefix if it is IPv6. Afterwards it is keyed on the pseudonymous identifier described in the section above, not on the address. Both kinds are deleted automatically by a scheduled job, within about 25 hours.

We do not use IP addresses to build a profile, we do not link them to renders, and we do not look up where they are.

Purchases

Browsing Hardpark costs nothing. Categories, subcategories, your car garage and your build gallery are all free to look at, with no subscription and no account. A paywall is shown once, right after onboarding, and you can close it and go straight to the app. What actually costs money is generating a render: that always spends a credit, and reaching zero credits is what brings a paywall or a purchase screen back, honestly, at the moment you try to spend one you don't have.

Two different things can be bought, and they are not the same purchase:

A subscription — Weekly, Monthly or Yearly — each granting a recurring allowance of render credits for as long as it stays active. This is what the paywall sells, and it is what someone who has never subscribed is offered when they try to generate with no credits.
A one-time credit top-up — 100, 350 or 1,000 credits for a flat price, no renewal, no expiry. This is offered instead, on a separate screen, to someone who already holds a subscription and has simply run out of the allowance it grants before the next renewal.

Prices and renewal terms for both are shown on their own screens, pulled live from the App Store for your country, never hardcoded here.

Anything you buy in Hardpark is sold and billed by Apple through the App Store. We never see your payment details — not your card number, not your billing address, not your name. Apple processes the transaction and tells the app only what was bought and whether it is still valid. Subscriptions renew automatically until cancelled; manage or cancel yours any time in Settings → [your name] → Subscriptions on your iPhone. A Restore Purchases button on the paywall recovers an active subscription on a new device or after a reinstall.

Hardpark uses RevenueCat to check and record subscription status. RevenueCat receives the same anonymous, App-Attest-derived identifier described above — not your Apple ID, name or email — plus your purchase information: which product, whether it renewed, whether it lapsed. It does not receive your photos or your renders; those never touch the billing path. See Apple's privacy policy and RevenueCat's privacy policy for how each of them handles what they receive.

Tracking, analytics and advertising

Hardpark contains no analytics SDK, no attribution or advertising library, and no crash reporter. It does not use the advertising identifier, and it will never show you the App Tracking Transparency prompt, because it has nothing to ask permission to track. How often you open the app, how long you spend in it, and what you tap are not recorded or sent anywhere. The one third-party SDK the app ships is RevenueCat, described in "Purchases" above — it exists solely to verify subscription purchases, and does not do analytics, advertising or tracking on Hardpark's behalf.

Who else is involved

Cloudflare — runs Hardpark's server and database.
fal.ai — runs the image model and receives the stripped photo for every render. For standard-tier renders it also hosts the finished image, locked, for 24 hours. For premium-tier renders it does not host the image at all — it hands the finished bytes back to us directly, and our own server is what holds them temporarily; see "The render, and how long it lasts" above.
Apple — the App Store, App Attest (which generates the device identifier described above), and all billing.
RevenueCat — verifies and records subscription status; see "Purchases" above for exactly what it receives.

That is the complete list. There are no advertising networks and no data brokers.

Deleting things — stated honestly

Some of this is bounded by a third party, and we would rather say so than promise erasure we cannot perform. Both controls live in the app's Settings — Forget my car for the photo on your phone, Delete my data for everything on our server — and the email address at the bottom of this page does the same job if you would rather write to us.

Deleting a render makes it unreachable immediately either way: the app stops being able to fetch it that instant, and our server never requests or serves it again. What happens to the underlying bytes differs by tier. Standard tier: the bytes leave fal when the 24-hour lifetime expires; we do not hold a credential that can delete them from fal's side sooner, and we chose not to hold one — it would mean carrying a much broader key permanently in order to speed up a deletion that happens within a day regardless. So: removed from the app at once, deleted by our provider within 24 hours. Premium tier: the bytes are already on our own server, not a provider's, so nothing stops us from erasing them the moment you delete a render — today, that erasure instead happens on the same nightly schedule described above, tied to when the render was created rather than to when you asked us to delete it, so the outside bound is 48 hours from creation rather than immediate. Not "deleted instantly" in either case, because that would not be true.
Deleting your data removes your device's record, its pseudonymous identifier, its balance and its generation history.
Your credit ledger and top-up purchase history are anonymised rather than deleted — the link to your device is removed and the financial entries remain. A payments record has to survive so that money paid and credits granted, whether from a subscription or a one-time top-up pack, can still be reconciled afterwards.
One rate-limit counter outlives the record by design. The counter that limits how often deletion itself can be requested is keyed on the very identifier being deleted, so removing it in the same breath would reset the limit on every deletion. It is kept — a bucket name, a time window and a number, on an identifier that no longer resolves to anything — and the scheduled job clears it within about 25 hours, like every other counter.
The copy of your photo on your phone is a separate control, on purpose. Forget my car (or, with more than one car, per-car removal in Manage your cars) deletes it from the phone immediately; choosing a different photo overwrites it, and deleting Hardpark takes it too. It is deliberately not folded into Delete my data, so that clearing your server record does not silently throw away the photo you set the app up with. Nothing has to be deleted anywhere else, because no copy of your photograph was stored anywhere else — not on our server, not at the provider, not in a backup.
Your build gallery is a third, separate control. Clear build history in Settings removes every entry from the phone immediately. It is local-only and touches neither your car photos nor your server record.

Children

Hardpark is not directed at children and is not intended for anyone under 13. We do not knowingly collect information from children.

Your rights

Under the GDPR, the UK GDPR and the CCPA you have rights to access, correct, export and erase personal data held about you. Hardpark holds no name, email address or account, so the data associated with your device is what is described above, and the deletion section says exactly what can and cannot be removed. We have never sold or shared personal information, and we do not sell or share it now.

Changes

If this policy changes, the date at the top changes with it and the previous version is superseded. A change that introduces a new recipient of your data — an analytics provider, a new model vendor, a billing service — will be published here before it ships, not after.

Contact

Questions about this policy, or a request about your data: gokhan.tosun1995@gmail.com.