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. Ten years of context, quietly compounding.
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.
It wasn’t. It was theirs.
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 nobody can turn it off but me.
That is the whole argument.
The mistake is not using platforms. The mistake is confusing distribution with ownership.
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.
Not a bunker. Not a purity test. Not a hand-coded shrine to the old web. Your own land is the boring layer underneath the work: the domain name, the website, the canonical URLs, the archive, the source files, the media masters, the mailing list or RSS feed, the backups, the redirects, the exportable content, the analytics you can keep, and a place where your work can still exist if a platform changes its rules.
Platforms can be roads. They can be billboards. They can be marketplaces, rooms, megaphones, and bars where interesting people are already talking.
They should not be the house.
Platforms vs. foundations
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. You can’t reach people from a server in your garage and a moral victory about open standards.
But there is a difference between using a platform and depending on one.
Most people treat the internet backward. They publish the important thing on a platform they do not control, then maybe link back to a neglected site. A photographer posts the work to Instagram and lets the portfolio rot. 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. Use every road that gets people to the work.
Just make sure the work has a home that is yours.
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. In return, I’m a tenant on someone else’s land. 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. The platform is the amplifier. The repository is the foundation.
That distinction matters more every year.
What platforms are for
Platforms are not the enemy. They are useful, and pretending otherwise is how you end up yelling into a beautifully controlled void.
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.
Use that. There is no prize for making the work harder to find.
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
That is the line. Use platforms for movement. Do not use them as the vault.
What breaks
The failure modes are not mysterious. They are ordinary. That is what makes them dangerous.
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. The audience graph stays behind because you never had the relationship, only rented access to it. 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 the extreme archive horror story: years of uploaded music disappeared after a server migration, and the cultural memory was mostly whatever happened to be saved elsewhere.
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.
The platform does what it was built to do. It optimizes for itself.
You should do the same.
What you should own
If your work has long-term value, you should own the boring parts around 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
This does not mean everything has to be self-hosted in the most annoying possible way. It means you should be able 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 the old tool goes sideways.
The important thing is not ideological purity. The important thing is leverage.
When you control the layer underneath the platform, you can negotiate with change. When you do not, you wait for a product manager’s decision to arrive in your inbox as weather.
The ownership test
You do not need a manifesto. You need a few uncomfortable questions.
- 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?
Ask those questions about your portfolio, your newsletter, your company site, your reel, your photo archive, your client case studies, your invoices, your production notes, your research, your pitch decks, your shot lists, your code, your collection database, your writing, and anything else you would be furious to lose.
If the answer makes you uncomfortable, good. That is the system telling you where the weak point is.
The boring setup that works
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 proof lives in the work. Your reputation lives in the trail of work. Your future opportunities often come from someone finding, sharing, remembering, or citing something you made years ago.
If that work lives only inside somebody else’s feed, it is not an archive. It is inventory in their attention machine.
AI on your own land
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.
Sound familiar?
I use cloud AI. Of course I do. The frontier models are useful. They are often the right tool. But the ownership question does not go away just because the tool is smarter. It gets sharper.
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 intelligence has nothing solid to stand on.
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 make sure the foundation does not depend on a subscription you cannot move.
Your archive is infrastructure
In production, everyone understands the value of a real archive once the job gets hard. Shot cards. Call sheets. Bids. Treatments. Boards. References. Vendor notes. Version history. Location photos. Client feedback. Legal approvals. Delivery specs. Final masters. The ugly connective tissue that nobody wants to organize until the exact missing thing becomes the most important file in the company.
The same is true for public work.
Your website is not just marketing. It is a memory system. Your archive is not nostalgia. It is infrastructure. Your domain is not vanity. It is an address that can survive tool churn. Your URLs are not details. They are handles other people can use to point at your work.
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.
The internet remembers badly unless you build a place for memory.
The hedge
I build on my own land because I’ve been doing this long enough to know that everything else is temporary. The tools change. The platforms change. The companies change. The incentives change. The only thing that persists is what you own, what you control, and what you’ve built on a foundation that doesn’t require someone else’s permission to exist.
My dozen websites aren’t a flex. They’re a hedge. Every one of them is a bet that the thing I care about will outlast the platform that could have hosted it.
I’m not saying everyone needs a dozen websites and a local language model. I’m saying that the things you care about most, your writing, your collections, your client-facing work, your data, your creative output, should live somewhere you control. Not exclusively. Use platforms for what they are good at. Let them send people to the work.
Just make sure the work can survive the platform.
Build roads to the platforms.
Do not build the house there.