Features
Platform timelines: steps, examples and decisions for 2027
A practical 2027 guide to platform timelines: steps, examples and decisions for 2027 with current definitions, decisions, checks, and review steps.
A timeline is the most confident-looking thing you can publish and one of the hardest to get right. It puts events on a line, in an order, with a spacing, and every one of those three decisions smuggles in a claim. Most published platform timelines are assembled by copying an earlier one, which is why they agree with each other and disagree with the record.
This page is about how to build one that holds up, and about the specific reasons this subject resists the format.
What to take away
- A timeline entry needs a date type, not just a date. When something was built, released, noticed and written about are four different moments.
- Most disagreement between timelines comes from copying, not from research. Agreement between sources is weak evidence when they share an ancestor.
- Nothing on this site asserts a company's dates, audience figures, ownership or feature list as fact, because those are exactly the entries that get repeated without checking.
Four dates, routinely collapsed into one
| Date type | What it records | Why it gets used wrongly |
|---|---|---|
| Built | When the thing existed and worked, often privately | Rarely documented, so it is quietly replaced by a later date |
| Released | When outsiders could use it, sometimes in stages by region or invitation | Staged releases have no single date, so one region's gets used for all |
| Noticed | When usage or attention reached a level someone remarked on | Frequently mistaken for release, and it is often much later |
| Reported | When a source described it | The easiest date to find, so it becomes the timeline entry by default |
The reported date is the one that travels, because it is the one attached to a citable document. That produces a systematic bias: timelines assembled from press coverage place everything later than it happened, and they place things that got early coverage earlier relative to things that did not.
Fixing this does not require better sources. It requires labelling. An entry that says which of the four it is remains useful even when it is the wrong one, because a reader can correct for it. An unlabelled date cannot be corrected by anybody.
Why sources agree without being independent
When five outlets carry the same date, the natural reading is confirmation. Usually it is repetition. One account is written, others summarise it, later writers cite the summaries, and eventually the original is out of print or offline while the copies remain. Nothing in the resulting set is independent, but it looks like consensus.
The way out is to trace rather than to count. Follow each source back until it either produces a contemporary document or produces another summary. Most chains end at one place, and a surprising number end nowhere, at a sentence with no source that everyone has been quoting.
Three practical tells that a chain is short:
- The same unusual phrasing appears in several accounts. Independent writers do not converge on the same odd sentence.
- The precision is inconsistent. A date given to the day for one event and the year for a neighbouring one usually means one of them came from a document and the other from memory.
- The earliest thing you can find is a retrospective. If nothing contemporary exists, the entry is a reconstruction, and it should be marked as one.
The material itself is disappearing
Even careful work runs into the fact that the primary record for this subject is unusually fragile.
Pages move and vanish, and the citation that pointed at them stops resolving. Link rot is not an occasional annoyance in this field, it is the background condition, and it is worst for exactly the material that matters most: announcements, help pages, terms of service and developer notes, all of which are edited in place without a version history a reader can see.
Web archiving recovers some of it, and its coverage is uneven in ways worth understanding before relying on it. Public pages are captured better than anything behind a login. Popular pages are captured more often than obscure ones. Anything assembled by script in the reader's browser may be archived as a shell with no content. And a capture has its own date, which is not the date the page was published.
So a timeline built today from archived material is not a record of what happened. It is a record of what was captured, filtered by what was public, popular and simple enough to save.
Building an entry that survives review
- Write the claim, then the date, then the date type, then where it came from, then the date you checked it. All five, every time.
- Prefer the operator's own documentation over coverage of it, and prefer developer documentation over marketing pages, because it is written for people who will notice errors.
- Where a release was staged, record the stages rather than choosing one. "Available in some regions before others" is a more accurate entry than any single date.
- When two sources conflict, keep both and say what each rests on. Averaging two dates produces a third that nothing supports.
- Mark reconstructions as reconstructions. An entry inferred from surrounding evidence is legitimate and it is not the same as a documented one.
- Say what is missing. A timeline with a stated gap is more trustworthy than one that looks complete.
What a timeline cannot show
Spacing implies pace, and a line implies causation. Both are usually wrong.
Events plotted at even intervals suggest steady development. Real change in this area is lumpy, and long quiet periods do most of the work. Two entries next to each other on a line invite the reader to connect them, and readers do, whether or not there is any relationship.
The other systematic distortion is survivorship. A timeline is built from things that lasted long enough to be recorded. Systems that were widely used and then closed leave a thinner trail than smaller ones that persisted, so the line quietly describes durability rather than importance.
Where those effects matter, a table beats a line. It carries the same information without the visual argument, and it has room for the date type and the source, which is the information a reader actually needs.
How this connects to the rest of the site
The definitional problems that make chronology hard here are set out in more detail under early social networks, where the question of what counts as a beginning turns out to determine the entire order of events. That page and this one are the two halves of the same difficulty: one is about what you are counting, and this one is about when you say it happened.
Common questions
Why not just use the company's own history page?
Use it, and label it. A company's account of itself is a primary source about what the company says, which is genuinely useful, and it is edited to serve the present. It is the right source for a founding claim and the wrong source for how something was received.
Is an approximate date better than no date?
Yes, if it is marked approximate. "Some time in this period, from a retrospective account" is an honest entry. The same value written as a precise date is a fabrication with good manners.
How do I handle something that launched in stages?
Record the stages. A staged rollout has no single date, and forcing one produces an entry that is wrong for most readers. This is the most common single error in published platform timelines.
What should I do when a cited page has disappeared?
Note that it is gone, keep what you quoted, and look for a capture. If nothing survives, the entry drops from documented to reported, and it should be relabelled rather than quietly kept at its old confidence.