I was Foursquare user number 14,488. I signed up on June 2, 2009, and for the next ten years I “checked in” almost everywhere I went. Not for points or mayorships, but for the location history that synced to my calendar. The big moments were there: my wedding in Palm Springs, my son’s birth at Sint Lucas Andreas in Amsterdam. But the real value was the small ones. A restaurant I’d forgotten about. A bar that closed years ago. A random Tuesday afternoon in a neighborhood I hadn’t been back to since. The record became more useful the longer I kept it.
Then Foursquare killed the calendar feed.
They’d warned it could happen. The feeds page had carried that disclaimer for years. But I’d been logging so consistently, for so long, that the data felt like mine.
The calendar feed still depended on them.
One day, they decided it wasn’t worth maintaining. My personal history became a feature they no longer wanted to support.
So I built my own.
Where/When is an iOS app that does one thing: saves your current location as a calendar event with GPS coordinates and a reverse-geocoded place name. All on-device. No account. No server. No data shared with anyone, ever. It’s been in the App Store for years now, and the thing I value most about it isn’t the design or the features. It’s that my location history no longer depends on Foursquare maintaining a feed.
A platform can help people find your work without being responsible for keeping the only copy.
A dozen websites
I have a dozen websites. Not for clients. For me.
A film collection tracker for my film collection, now 3,200+ titles across digital and physical discs. A vinyl collection app that tracks value via Discogs. A comic book tracker. A movie poster database with 70,000 pages. A blog. A portfolio. A meeting cost calculator. A margin calculator. A photography portfolio. A bookshelf. A LEGO instruction browser that freed up so much space in my son’s closet. An interactive archive of VFX shot cards from a film I worked on in 2002.
Every one runs on Cloudflare. Every one is backed by git. Every one is something I can move, modify, or shut down without asking anyone’s permission. The data lives in databases and repositories I control. The domains point where I tell them to point.
This sounds like overkill. It probably is. But I didn’t build them all at once, and I didn’t build them to prove a point. Each one started because I wanted a tool that worked the way I wanted it to work, displayed the data the way I wanted to see it, and didn’t depend on a company’s roadmap, business model, or continued existence.
That is what I mean by your own land: control of your domain, source files, archive, backups, and exportable content. You can use commercial services while keeping enough of the work to move elsewhere when necessary.
Publish on your domain first
The conventional wisdom is that you should go where the audience is. Post on Instagram. Publish on Substack. Put the reel on TikTok. Upload to YouTube. Sell through Shopify. Keep a LinkedIn page alive because some clients still live there. And there’s truth in that. Distribution matters. Discovery matters. Conversation matters. A site you control still needs ways for people to find it.
But there is a difference between using a platform and depending on one.
It is easy to neglect your own archive. You publish the important thing on a platform you do not control, then maybe link back to a neglected site. A photographer posts the work to Instagram and leaves the portfolio out of date. A small production company puts every update on LinkedIn and treats its own site like a PDF brochure from 2017. A writer sends the real essay to a newsletter platform, then keeps a thin archive somewhere else if they remember. A filmmaker uploads years of work to a channel and assumes the channel is the archive.
It should be the other way around.
Publish the canonical version on your own domain. Then syndicate outward. Put the clip on the platforms. Post the thread. Send the newsletter. Share the carousel. Join the conversation. Link back to the complete version on your site.
I publish a newsletter on Substack. I’m not naive about the tradeoff. Substack gives me distribution, a subscriber list, a reading experience I didn’t have to design, and a place where people already understand the behavior. I also depend on their decisions. If Substack changes its economics, export rules, politics, search visibility, or product direction, I have to deal with it.
The difference is that everything I write also exists in a markdown file in a git repository on my machine. The subscriber list is exportable. The words are mine. If Substack disappears tomorrow, the writing survives. Substack helps distribute it; the repository preserves my copy.
What platforms are for
A site you control and a platform with an existing audience serve different purposes.
Platforms are good for:
- distribution
- discovery
- conversation
- testing ideas
- lightweight posting
- social proof
- networking
- finding collaborators
- sending people back to the canonical version
- promotion
That is real value. A producer can find a director on Instagram. A VFX supervisor can discover an artist on Vimeo. A writer can test an idea on LinkedIn. A tiny tool can find its first users through a short post that happens to travel. A production company can remind clients that it exists without launching a whole campaign.
Those are good reasons to use platforms.
But platforms are bad as the only home for:
- your archive
- your identity
- your business
- your client-facing proof
- your long-term work
- your audience relationship
Keep independent copies of material you need to retain.
What breaks
Routine product changes can disrupt an archive.
An account gets suspended. An API shuts down. Search gets worse. A platform pivots. A company gets acquired. A product gets sunset. A feed changes. A paywall moves. Exports become incomplete. Old posts become impossible to find. Media gets recompressed, locked down, or detached from its context. You may be unable to contact your followers outside the platform. Someone else controls the canonical URL, so when the platform changes, the citation breaks with it.
None of this requires a villain.
Twitter becoming X is the obvious example: API access changed, and years of assumptions around search, embeds, verification, and third-party workflows suddenly felt less stable. Reddit’s API changes wiped out major third-party clients and reminded everyone that “community” still sits behind a business decision. Myspace is a particularly severe example: years of uploaded music disappeared after a server migration, and independent copies became essential.
Most failures are less dramatic than that. Instagram does not need to delete your work to make it hard to search, sort, cite, or revisit. A newsletter platform does not need to trap you forever to make leaving annoying enough that you postpone it. A streaming catalog does not need to lose a film permanently to make a version vanish from the place everyone assumed it lived. A social page does not need to crash to make a business harder to find, quote, trust, or archive.
A platform’s priorities may differ from your need to preserve the work.
What you should own
If your work has long-term value, you should control the files and services needed to preserve and publish it.
You should own:
- your domain
- your website
- your canonical post and page URLs
- your source files
- your images, video, and audio masters where possible
- your email list or RSS feed
- your customer or contact list where appropriate
- your backups
- your redirects
- your analytics and export history
- your project archive
You can use a hosting provider and still retain the ability to move. A domain can point somewhere else. A static site can be rebuilt. Markdown can be converted. Images can be re-exported. A mailing list can move providers. A redirect can preserve a link. A backup can become the starting point when a service fails.
Control of those files and addresses gives you practical options when a provider changes its service.
The ownership test
Check what you could recover or move:
- If this platform disappeared tomorrow, what would I lose?
- Can I export the work?
- Can I export the audience or contact list?
- Do I control the canonical URL?
- Can someone cite this five years from now?
- Can I redirect old links?
- Do I have the original files?
- Is the public version backed up somewhere I control?
- Can search engines find it outside the platform?
- Does this platform own the relationship, or do I?
Apply those questions to the work and records you need to retain, including material held in services you rarely check.
Start with the material you could not currently recover.
A practical setup
The minimum viable version is not complicated.
Buy a domain. Publish canonical posts and pages on your own site. Keep the source files somewhere backed up. Syndicate to social platforms after publishing, not instead of publishing. Maintain RSS, email capture, or both. Keep a media and archive folder. Back up images and source assets. Use redirects when URLs change. Periodically export platform data. Do not rely on DMs and comments as your only record of important relationships.
That is most of it.
You can make it fancier if the work justifies it. A static site in git. A private archive in cloud storage. A local backup. A searchable notes system. A small database. A media library with real filenames instead of whatever the platform gave you. A habit of saving the original file before posting the compressed version. A quarterly reminder to export data from the places where the export button still exists.
For producers, creative directors, small production companies, freelancers, artists, writers, and archive builders, this is not abstract. Your archive shows prospective clients what you have done. Your future opportunities often come from someone finding, sharing, remembering, or citing something you made years ago.
Work stored only in a platform’s feed may be difficult to find or retrieve later.
Keeping control of AI workflows
The next version of this problem is already here, and it is bigger than social platforms.
Most people building with AI are doing it through cloud APIs. OpenAI, Anthropic, Google, whoever has the best model this month. You send your data up, you get your answers back, and your workflow depends on a company’s pricing, rate limits, moderation rules, retention policies, uptime, and continued willingness to serve you.
I use cloud AI because the models are useful. I still need access to my files if I change providers.
If AI becomes part of how you search a production archive, summarize a meeting, organize a media library, compare treatments, build a lookbook, query old notes, or remember what happened on a job three years ago, then the archive matters even more. The model is only as useful as the material it can reach. If the material is scattered across dead links, closed accounts, platform inboxes, compressed uploads, and half-remembered threads, the model cannot reliably retrieve the records you need.
Local models are already good enough for useful private work: search, summarization, classification, transcription cleanup, light coding, file organization, and asking questions of your own notes. They do not replace every cloud model. They do not need to. The point is that more of the workflow can live closer to the files, closer to the archive, and closer to your control.
The same principle applies: use the cloud for what it is good at, but keep your records in a form you can use with another service.
Your archive is infrastructure
Production records are easy to neglect until someone needs a specific file: an approved bid, a location photograph, a client note, or a final master.
The same is true for public work.
Your website can preserve a record of your work. Your domain can remain the same when you change tools or providers, and stable URLs let other people cite and revisit individual projects.
That matters for a freelancer trying to show a client what they have done. It matters for a small studio whose best case study is five years old but still relevant. It matters for an artist whose old experiments explain the new work. It matters for a writer whose ideas compound across posts. It matters for anyone building tools, collections, libraries, projects, or proof over time.
Keeping an accessible archive takes deliberate maintenance.
Keep the option to move
I built these sites because I wanted tools I could modify and records I could keep. Each reduces my dependence on a service whose priorities may change.
You do not need a dozen websites or a local language model. Start with the material you would be most upset to lose. Save the originals, back them up, and make sure you can publish or use them elsewhere. Then use platforms to help people find the work.