OCXLY Digital Media House — Stories

The quiet return of the static web

Tue, 01 Sep 2026 00:00:00 GMT

For most of the web’s history, a page was a file. You asked for it, a server handed it over, and your browser drew it. Then, for a decade or so, publishing became a live performance: every visit assembled the page from a database, a template engine, a personalisation layer and a dozen third-party scripts, all in the few hundred milliseconds before a reader lost patience.

That model is quietly being unwound. Not by a new framework, but by a rediscovery of an old idea: build the page once, put the finished file on a network of servers close to readers, and only run code where something genuinely has to change per person.

Why it came back

Three pressures pushed publishers in the same direction.

Speed stopped being optional. Search engines now measure how quickly a page becomes usable, how stable its layout is and how fast it responds to a tap. A pre-built file served from a nearby cache wins those measurements almost by default. A page assembled on demand has to work hard to tie.

Attack surface became a board-level topic. A server that runs application code on every request is a server that can be exploited on every request. A static file has no login form to brute-force, no query to inject into and no session to hijack. The dynamic parts, such as a newsletter sign-up or a comment system, can be isolated into small services with narrow permissions.

Cost curves inverted. Serving files from a content delivery network is cheap enough that a traffic spike from a viral story is an inconvenience rather than an outage. Running enough application servers to survive the same spike is expensive, and the money is spent whether the spike arrives or not.

What “static” actually means now

The word is misleading. Modern static sites are not frozen. The content lives in a content management system, a Markdown repository or a headless database. A build step turns that content into HTML, images and feeds. A deployment step pushes the result to the edge. Editors keep their tools; readers get files.

Interactive features have not disappeared. They have been demoted to components. A search box can query an index that was generated at build time. A video player can load its heavy code only when someone presses play. A form can post to a tiny function that validates input and forwards it, without the rest of the site knowing the function exists.

The trade-offs are real

Static-first is not free. Builds take time, and a site with hundreds of thousands of pages has to be clever about rebuilding only what changed. Truly personal experiences, such as a logged-in dashboard, still need a server. Editors used to seeing a change appear instantly have to learn that “published” and “deployed” are separate steps that usually complete within a minute or two.

The honest summary is that static-first moves complexity rather than removing it. The complexity moves from the moment a reader arrives, where every millisecond and every vulnerability is expensive, to the moment an editor publishes, where a slow or failed build is annoying but harmless.

Why it matters for readers

A page that loads instantly, does not jump around and works when the network is poor is a page that respects the person reading it. A site that cannot be compromised by a request is a site that will not leak the reader’s data through a hole nobody noticed. Those are editorial values expressed as architecture.

This site is built the same way. The stories you are reading are files. The chrome around them is glass, but the words underneath are solid.

The creator economy has a middle-class problem

Sun, 30 Aug 2026 00:00:00 GMT

The promise of the creator economy was that anyone could build an audience and make a living from it. The first half came true. The second half came true for a very small number of people, and the shape of the distribution is not an accident.

Feeds reward the extremes

Recommendation systems are optimised to keep people scrolling. The content that does that most reliably is either enormous, produced by people who already have reach, or novel, produced by people who have not yet been seen. The vast middle, creators with a real but modest audience, is the least useful to the algorithm and receives the least distribution.

This produces a familiar pattern. A creator has a piece that travels, gains followers, and then discovers that those followers do not see the next piece unless it also travels. The audience exists on paper. The relationship does not.

Rented land

The deeper problem is ownership. A follower on a platform is a row in that platform’s database. The creator cannot export the relationship, cannot contact the person directly and cannot move them elsewhere if the platform changes its rules, its ranking or its business model. Every large platform has done all three, repeatedly.

The creators who have built durable careers tend to have one thing in common: a channel they control. An email list, a website, a community space with a member list they can export. The platform becomes a discovery layer rather than the home.

What the middle looks like when it works

Away from the feed, a different model is quietly maturing. Small communities, often a few hundred to a few thousand members, organised around a topic or a craft rather than a personality. Revenue comes from membership, from tools the community builds together, from events and from work the community generates, rather than from advertising against attention.

These spaces have properties the feed cannot offer. Members know each other. Reputation is earned over time rather than reset by every post. The person running the space can make a decision without an algorithm overriding it. A modest audience becomes viable because the relationship is direct.

The trade-offs

Community-owned spaces are harder to grow. Discovery still happens on the platforms, so most creators run both, using the feed to find people and the owned space to keep them. Moderation is real work that does not scale automatically. And the tooling, while much better than it was, still assumes a level of technical comfort that not every creator has.

There is also a risk of building a smaller version of the same problem. A community platform is still a platform. The test is whether you can leave with your people and your content intact.

Why it matters

A healthy digital culture needs a middle class of creators: people who make specific, careful things for specific audiences and can afford to keep doing it. The feed has not produced that class and, structurally, cannot. The communities that will are being built now, one member list at a time.

Building tools, ideas and spaces for that middle is part of why OCXLY exists.

A field guide to spotting research that will actually ship

Fri, 28 Aug 2026 00:00:00 GMT

Technology reporting has a recurring genre: the laboratory result presented as an imminent product. A new battery chemistry, a display technology, a model architecture, a medical sensor. The demonstration is real, the press release is confident and the timeline is vague. Most of these announcements are never heard from again. A few become the infrastructure of daily life. Telling them apart in advance is a skill, and it rests on a handful of questions.

Does it work outside the demo?

Laboratory results are produced under controlled conditions by the people most motivated to make them work. The first question is whether the effect survives contact with a different team, different equipment and ordinary users. Independent replication is the strongest signal available and the one press releases mention least.

For software, the equivalent question is whether the demonstration is cherry-picked. A model that produces a stunning output once is a curiosity. A model that produces acceptable output on nine tries out of ten is a product.

What has to be true about manufacturing?

Many technologies work perfectly and ship never, because making them at scale is a different problem from making one. Ask what the production process looks like, whether it uses existing factories or requires new ones, and whether the input materials are available in the quantities a real market would need. A result that depends on a rare material or a bespoke process is years away at best, however good the prototype.

Who has to change their behaviour?

The easiest technologies to adopt are the ones nobody notices. A better battery inside the same phone ships as soon as it is cheap enough. A technology that requires users to learn a new interaction, businesses to rewrite processes or an industry to agree on a standard faces a much longer road, and the road is paved with the remains of superior products that asked too much.

Is the cost trajectory plausible?

Early versions of everything are expensive. The question is whether there is a credible path down. Technologies built on components that are already declining in price, such as sensors, compute or standard manufacturing, tend to follow that curve. Technologies whose costs are dominated by labour, rare materials or regulatory approval do not get cheaper just because demand exists.

Who benefits, and can they pay?

A technology needs a first customer who values it enough to pay early prices and tolerate early problems. Research that solves a problem nobody is currently paying to solve has to create a market as well as a product, which is far harder. The most reliable early adopters are organisations with an expensive existing problem and a budget line already attached to it.

What is the failure mode?

Every technology fails somehow. The ones that ship have failure modes that are tolerable: a slightly worse result, a graceful fallback, an obvious error. The ones that stall have failure modes that are catastrophic or invisible. Ask what happens when it goes wrong and whether the answer is acceptable to a regulator, an insurer and an ordinary customer.

Using the guide

None of these questions requires expertise in the technology itself. They require the willingness to ask about the boring parts: manufacturing, cost, adoption, failure. The announcements that survive those questions are worth following closely. The ones that cannot answer them are worth a paragraph, not a headline.

This is the lens OCXLY tries to bring to innovation coverage. Excitement is cheap. Shipping is the story.

What "open source" actually promises, and what it doesn't

Thu, 27 Aug 2026 00:00:00 GMT

“Open source” is one of the most successful phrases in the history of software. It is also one of the most over-loaded. People use it to mean free, safe, community-run, transparent, ethical and permanent. The definition guarantees exactly one of those things, and only partly.

What the licence gives you

An open source licence is a legal instrument. It grants permission: to read the code, to run it for any purpose, to change it and to pass it on, sometimes with conditions attached. That is a large grant, and it is the reason the modern internet exists. Almost every server, phone and browser is built on code that anyone can inspect.

But a licence is not a service agreement. It does not say the code works. It does not say anyone will fix it if it breaks. Most licences say the opposite, in capital letters, in a paragraph that nobody reads.

What it does not give you

Maintenance. A project can be open and abandoned at the same time. Much of the software that critical systems depend on is maintained by one or two people in their spare time, and the fact that the code is public does not create a queue of volunteers to take over when they stop.

Security. “Many eyes make all bugs shallow” is an aspiration, not a law. Eyes have to be pointed at the code, and they have to belong to people who know what they are looking for. Serious vulnerabilities have lived for years in widely used open libraries because everyone assumed someone else was auditing them.

Governance. Who decides what gets merged? Who holds the publishing keys for the package registry? What happens when a maintainer’s account is compromised, or when a company that funds the project changes its mind? Open code can sit under closed decision-making, and the licence has nothing to say about it.

Permanence. Licences can change for future versions. Projects can be relicensed, forked, or simply left to rot. The code you downloaded stays open; the project you depended on may not.

The supply-chain framing

The most useful mental model for open source today is not “free software” but “supply chain”. Every dependency you add is a supplier. You are trusting their code, their build process, their account security and their judgement about their own dependencies, recursively.

That framing suggests the right questions. Who maintains this? When was it last updated? How are releases signed? Does the project have a security policy and a way to report problems privately? Does anyone actually read its changelog? None of these questions are answered by the licence file.

What good stewardship looks like

The healthiest projects have boring characteristics. More than one person can publish a release. Contributions are reviewed by someone other than the author. Dependencies are pinned and audited. Security reports have a private channel and a public disclosure timeline. Funding, where it exists, is visible.

None of that is glamorous, and none of it is required by the definition of open source. It is simply what it takes for the promise in the licence to mean something in practice.

The point

Open source is one of the great collaborative achievements of the last half-century. Treating it as a free resource that maintains itself is the fastest way to break it. The label tells you what you may do. The rest is your responsibility.

Your website is only as private as its third-party scripts

Tue, 25 Aug 2026 00:00:00 GMT

Most privacy policies are written by lawyers and read by nobody. Most websites are assembled by developers under deadline, adding a script for analytics, another for a chat widget, another for an embedded video, another because marketing asked for it. The policy describes what the organisation intends. The scripts describe what actually happens in the reader’s browser, and only one of those documents is enforceable by the browser itself.

What a third-party script can do

When a page loads a script from another domain, that script runs with the same authority as the page’s own code. It can read everything the page can see, including form fields as they are typed. It can set identifiers that follow the reader across every other site that loads the same script. It can load further scripts from further domains, none of which the site owner chose. And it can change its behaviour at any time, because the site owner is loading whatever the third party serves today.

That last point is the one that surprises people. A script that was harmless when it was added can become a tracker, a miner or a payload after a supply-chain compromise, and the site will serve it faithfully until someone notices.

The measurable gap

Because scripts are visible, the gap between policy and practice is easy to audit. Load the page with the network panel open and count the domains. Check which ones set cookies and which run before any consent has been given. Look for pixels that fire on form submission. Compare the list to the policy’s description of “trusted partners”.

On most commercial sites the count runs into dozens, the policy names a handful, and several of the scripts run regardless of what the consent banner says. That is not usually malice. It is the accumulation of individually reasonable decisions with no one responsible for the total.

The defensive tools

Browsers now provide the site owner with real controls. A Content Security Policy tells the browser which domains are allowed to run code, load images or connect to servers; anything else is blocked and reported. Subresource integrity lets a page verify that a script has not changed since it was reviewed. Permissions policies deny access to cameras, microphones and location to any frame that does not need them. Referrer policies limit what the site leaks about its own readers to the destinations they click.

None of these is difficult to deploy. All of them are rarely deployed, because they require someone to write down what the site actually needs, and that inventory is the work nobody has done.

The editorial version of the problem

For a publisher, the question is sharper. Readers extend a degree of trust to a publication that they do not extend to a shop. A news site that loads twenty trackers is monetising that trust in a way the reader did not agree to and would not recognise from the masthead.

The alternative is not to have no analytics. It is to choose tools that measure without identifying, to host what can be hosted, to load embedded media only when the reader asks for it and to write a policy that matches the network panel.

A simple test

Open your own site. Open the developer tools. Load the page. If you cannot explain every domain in the list, your privacy policy is describing a website you do not have.

Why group chats became the real social network

Sat, 22 Aug 2026 00:00:00 GMT

Ask most people where they had their best online conversation this week and the answer will not be a public timeline. It will be a group: friends from school, a family thread, a handful of colleagues, a community of people who share an unusual hobby. The public feed still exists and still shapes culture, but the centre of gravity of ordinary social life has moved into rooms with a door.

The performance problem

Public feeds have an audience problem that has nothing to do with algorithms. When everyone you have ever met can see a post, you write for the worst possible reader. Jokes are tightened, opinions are softened, and anything uncertain is left out. The result is a feed full of finished statements from people who have stopped thinking out loud.

A group chat has a known audience. You can be wrong in it. You can ask a stupid question, change your mind, share something half-formed. Those are the conditions under which people actually talk, and they are almost impossible to recreate in public.

What changed technically

Three things made private groups viable at scale. End-to-end encryption became the default in the most popular messaging apps, so a group could be genuinely private rather than merely unlisted. Media sharing in chat became good enough that links, videos and documents no longer needed a separate platform. And the apps themselves grew features that used to belong to forums: threads, reactions, pinned messages, roles and, in the larger community platforms, whole channel hierarchies.

The result is that a group chat can now do most of what a small social network did, without a public profile, an advertising model or a recommendation system deciding who sees what.

The costs

Private does not mean healthy. Groups can be echo chambers with better encryption. Misinformation travels through trusted contacts more effectively than through public posts, precisely because the trust is real. Harassment inside a closed group is invisible to everyone outside it. And the people who study public discourse, from researchers to journalists, have lost visibility into where a large share of it now happens.

There is also a fragmentation cost for the people inside. Attention is split across dozens of rooms, each with its own norms and its own expectation of presence. The feeling of never being caught up is now a private experience rather than a public one.

The lasting change is a separation of functions that platforms used to bundle. Discovery still happens in public: you find people and ideas through feeds, search and recommendations. Relationship happens in private: you keep people through groups. Identity is split accordingly, with a polished public version and a series of context-specific private ones.

Platforms have noticed and are chasing the private side with community features, paid groups and creator channels. Whether they can host genuine private spaces while running advertising businesses is an open question. The early evidence suggests people are choosing tools that do not have to answer it.

Why it matters

Where conversation happens determines who can shape it, who can moderate it and who can study it. The move to private groups returns a measure of control to participants and removes a measure of visibility from everyone else. Both halves of that are worth taking seriously.

Passkeys, explained without the marketing

Wed, 19 Aug 2026 00:00:00 GMT

Passwords fail for a simple reason: the same secret is stored in two places, and one of them is a server you do not control. When that server leaks, the secret is gone. When a convincing fake site asks for it, people type it in. No amount of complexity rules fixes a design in which the secret has to be sent to be checked.

Passkeys change the design rather than the rules.

How they work, briefly

When you register a passkey with a site, your device creates a pair of mathematically linked keys. One half, the public key, is sent to the site and stored. The other half, the private key, never leaves your device. It sits in a secure area of the hardware and is unlocked by whatever you already use to unlock the device: a fingerprint, a face, a PIN.

When you sign in, the site sends a random challenge. Your device signs it with the private key. The site checks the signature with the public key it stored. Nothing secret crosses the network, so nothing secret can be intercepted, and a database breach yields a pile of public keys that are useless without their private halves.

The passkey is also bound to the site’s real address. A fake site with a similar name cannot ask your device for a signature that belongs to the real one. That single property removes the most common form of phishing.

Where the trust goes

Every security design moves trust somewhere. Passkeys move it from the website’s password database to three places.

Your device. If someone can unlock it, they can use your passkeys. Device security becomes account security in a much more direct way than before.

Your platform account. For passkeys to survive a lost phone, they have to be backed up and synchronised. That means the ecosystem you use, whether it is a phone maker, a browser vendor or a password manager, holds an encrypted copy. The encryption is strong, but the recovery process for that account is now the weakest link for everything protected by it.

Recovery processes. When a device is lost and the sync account is unavailable, what happens? Sites still need a recovery path, and recovery paths are where attackers go when the front door is locked. A site with excellent passkey support and a weak “forgot my device” flow has not improved much.

The practical questions

Can you move passkeys between ecosystems? Increasingly yes, but it is still less smooth than exporting a password list, and it depends on which vendors you use.

Should you keep a password as well? Many sites keep it as a fallback, which means the old weakness remains. The strongest position is passkeys plus a recovery method you actually understand, with the password removed once you trust the setup.

What about shared accounts? Passkeys are personal by design. Shared logins need a different answer, usually delegated access rather than shared secrets.

The honest verdict

Passkeys are the biggest practical improvement in everyday authentication in decades, and the criticisms of them are mostly about the surrounding systems rather than the cryptography. They remove the two failure modes that cause the most harm: reuse and phishing. What they add is a dependence on device and platform security that is worth understanding before you rely on it.

Use them. Understand your recovery path. Do not assume the marketing covers the second part.

Design systems are how small teams pretend to be big ones

Sat, 15 Aug 2026 00:00:00 GMT

The most convincing products from small teams share a quality that is hard to name and easy to feel: everything looks like it belongs together. Buttons behave the same way on every screen. Spacing has a rhythm. Colour means something consistent. That quality is not talent alone. It is usually a design system, and a design system is mostly a set of decisions made once so they never have to be made again.

Tokens before components

The foundation is not a component library. It is a short list of named values: a handful of colours with roles rather than hues, a type scale, a spacing scale, a few radii, a few shadows, a few durations. These are the tokens. Every visual decision in the product refers to one of them by name.

The effect is that changing the product’s look becomes a matter of changing the list. More importantly, the constraint stops drift. When the only available spacing values are on the scale, nobody nudges an element by three pixels because it looked slightly off. The scale is the answer, and if the scale is wrong, the fix is to the scale.

Components are decisions made visible

With tokens in place, components are the second layer: a button, an input, a card, a navigation bar, each built from tokens and each encoding a set of behaviours. What does focus look like? What happens on a slow network? How does it behave at a narrow width? A component answers those questions once, and every screen that uses it inherits the answers.

The discipline here is scope. A design system with two hundred components is a maintenance burden pretending to be an asset. The useful ones are small: a few dozen components that cover most of the interface, with clear rules for when to compose them and when to build something new.

The refusal list

The hardest part of maintaining a design system is saying no. No to the fourth shade of blue that a stakeholder likes. No to a special button for one campaign. No to a slightly different card because the content on one page is slightly different. Every exception is a future inconsistency, and inconsistency is precisely what the system exists to prevent.

Good teams keep an explicit refusal list, a record of what was requested and declined and why. It stops the same debate happening every quarter and it makes the system’s values legible to new people.

Why it works for small teams specifically

A large organisation can afford inconsistency because it has the staff to smooth it over. A small team cannot. Every hour spent redeciding a spacing value or rebuilding a button is an hour not spent on the thing that makes the product worth using. The system converts taste into infrastructure, which is the only way a handful of people can produce something that feels like it came from a much larger one.

There is a second benefit. A design system is documentation that cannot go stale, because it is the product. New contributors learn the visual language by using it rather than reading about it.

Where to start

Start with the tokens and be ruthless. Five colours with roles, a six-step type scale, a spacing scale that doubles, two radii, three shadows. Build the four components you use most from those. Ship it. Add to the system only when the same need appears three times.

The result will look like the work of a bigger team. That is the point.

Local AI is a hardware story

Wed, 12 Aug 2026 00:00:00 GMT

Every few months a demonstration circulates of a capable AI model running entirely on a laptop or phone: no cloud, no account, no data leaving the device. The demos are real. The explanation that usually accompanies them, that clever compression made the model small enough, is only half the story. The other half is the physical layout of the machine.

The bottleneck is not compute

When a language model generates text, it produces one token at a time, and for every token it has to read essentially all of its parameters. A model with several billion parameters, stored at a couple of bytes each, is several gigabytes of data that must stream past the processor for every word.

The processor is rarely the limit. Modern phone and laptop chips can multiply numbers far faster than they can fetch them. What decides the speed is memory bandwidth: how many gigabytes per second the memory system can deliver. Double the bandwidth and, for this kind of workload, you roughly double the words per second.

That is why the devices that run local models well share a specific design choice. They place memory very close to the processor, often in the same package, with a wide bus between them. It is also why devices with plenty of storage but modest memory bandwidth struggle regardless of how fast their chips are on paper.

Quantisation is a bandwidth trick

The compression techniques that make local models feasible, collectively called quantisation, work by storing each parameter in fewer bits. A model stored at four bits per parameter needs a quarter of the memory traffic of the same model at sixteen bits. The quality cost is real but often small, and the speed gain is roughly proportional to the reduction in bytes.

In other words, quantisation is a way of buying bandwidth you do not have. It is a software technique in service of a hardware constraint.

The dedicated accelerator question

Phone and laptop makers now ship dedicated neural processing units alongside the main processor and the graphics chip. Their advantage is efficiency: they can do the specific arithmetic that models need using far less energy, which matters when the battery is the budget. Their limitation is that they share the same memory system, so they hit the same bandwidth wall. A more efficient engine does not help if the fuel line is the constraint.

Where these accelerators shine is in the many small, continuous tasks that were previously too expensive to run all the time: transcription, image understanding, on-device search over your own files. The headline chat-with-a-model demos are the least representative use of them.

Why it matters beyond speed

Local inference changes who sees your data. A model running on your device can read your messages, photos and documents without any of it being uploaded. That is a meaningful privacy shift, and it also changes the economics: a feature that costs the vendor nothing per use is a feature they can ship to everyone by default.

It also changes what fails. A cloud model fails when the network or the company does. A local model fails when your device is too old, which pushes the upgrade cycle and raises a fairness question about who gets the good version of the software.

What to watch

Ignore parameter counts in marketing. Look for memory bandwidth figures, how much memory is actually available to applications and whether the vendor publishes which tasks run locally and which fall back to the cloud. The interesting progress in local AI over the next few years will be visible in chip layouts, not model names.

RSS never died. It just stopped being marketed.

Tue, 11 Aug 2026 00:00:00 GMT

Every so often someone declares a feed technology dead, usually because a large company stopped supporting it. The technology in question carries on regardless, because it does not depend on any large company. RSS, the simple format that lets a site publish a machine-readable list of what it has recently published, is a case study in how open standards outlive the products built on top of them.

What it does

An RSS feed is a file. It lists a site’s recent items with a title, a link, a date and usually a summary or the full text. A reader application fetches that file periodically from every site you follow and shows you what is new, in the order it was published, with nothing hidden and nothing promoted.

That is the whole feature, and it is the opposite of a modern feed in almost every respect. There is no ranking. There is no engagement metric deciding what you see. There is no platform between the publisher and the reader. If you subscribe to a site, you see what it publishes, and if you unsubscribe, it stops.

Why it faded

RSS lost its mainstream moment for ordinary reasons. It required a separate app and a little setup. Social platforms offered discovery as well as following, and discovery is what most people wanted most of the time. Publishers found that social distribution reached more people, even if it reached them less reliably. And the format itself was never a product with a marketing budget; nobody’s revenue depended on you knowing it existed.

Why it is back

Three things changed. Platform feeds became noticeably worse at showing people what they had asked to see, and the reasons became widely understood. Podcasts, which run entirely on RSS, became one of the largest media categories in the world, demonstrating that the model scales. And a new generation of reader apps made subscribing as easy as pasting a link, with polished interfaces that no longer feel like a developer tool.

There is also a quieter driver. Anyone building a tool that needs to know what a site has published, whether that is a search engine, a research project, an archive or an assistant, uses feeds if they exist. A site with a good feed is a site that participates in the wider web. A site without one is a site that can only be reached through whichever platform happens to be ascendant.

What a good feed looks like

Full text rather than truncated teasers, so that reading does not require a click-through. Correct dates, so items appear in order. A stable link per item. Enclosures for media, so that audio and video feeds work in podcast apps. Category feeds for readers who want one subject and not the others. And a link in the page’s head so that reader apps find the feed automatically.

None of this is difficult. It is simply a matter of treating the feed as part of the publication rather than a legacy checkbox.

Where OCXLY stands

This site publishes a full feed and category feeds, and the video and audio sections have their own. If you would rather follow us through a reader than through a platform, that is exactly what they are for. The open web is not a nostalgia project. It is the part of the internet that still works the same way regardless of who owns it this year.

Digital identity is now a stack of accounts you don't control

Sat, 08 Aug 2026 00:00:00 GMT

Who are you online? The honest answer is a list. A handle on one platform, a different one on another, a login provided by a third company that you use to sign in to a fourth. A purchase history here, a viewing history there, a reputation score somewhere you have never logged into directly. None of those pieces is you, and none of them is yours in any sense that would survive the company holding it deciding otherwise.

How it got this way

Every service needs to know who is asking. The simplest answer was for each service to keep its own record, which is why the average person has hundreds of accounts. Sign-in providers reduced the friction of creating them but concentrated the dependency: lose access to the provider and you lose access to everything behind it.

Meanwhile, the valuable part of identity, the accumulated history and reputation, was never designed to move. A decade of reviews, posts, purchases or contributions lives inside one product’s database. It is yours to look at and theirs to keep.

What portability would mean

Real portability has three parts. You should be able to take your data out in a form another service can read. You should be able to keep your identifier, so that people who know you by a name can still find you. And you should be able to carry your reputation, so that starting somewhere new does not mean starting from zero.

The first part exists in law in many places and in practice in a few. The second is emerging through decentralised identity systems that let a domain name or a cryptographic key serve as an identifier that no single platform issues. The third is largely unsolved, because reputation is context-specific and the contexts do not trust each other.

The security angle

A stack of accounts is also a stack of attack surfaces. Recovery flows, security questions, linked phone numbers and email addresses form a web in which compromising one node often yields the rest. The person who controls your primary email address effectively controls your identity, which is a strange amount of power to hand to a free service most people signed up for as a teenager.

Consolidation helps until it doesn’t. Fewer accounts mean fewer weak points, but a single provider becomes a single point of failure. The pragmatic middle is a small number of well-protected core accounts, hardware-backed authentication where it is offered and a recovery plan you have actually tested.

The policy question

Technical solutions exist for most of this. What is missing is an obligation. Platforms have no incentive to make leaving easy, and voluntary standards for portability have a history of being adopted enthusiastically by the platforms that have the least to lose. Where regulators have required data portability, it has arrived; where they have not, it has been announced and quietly deprioritised.

Identity portability will follow the same pattern. It will exist where it is required and be a talking point everywhere else.

What you can do now

Own a domain name and use it as your durable address. Keep an exported copy of anything that matters. Prefer services that publish how to leave. And treat your primary email and phone number as the critical infrastructure they have become, because to every other service on your list, they are.

The startup ideas that survive are boring on purpose

Wed, 05 Aug 2026 00:00:00 GMT

If you follow startup news, you would conclude that new companies are mostly about consumer apps, moonshot hardware and whatever technology is currently on magazine covers. If you follow which startups are still operating five years later, you would conclude something different. The survivors sell unglamorous things to organisations that were already paying for a worse version.

The budget line test

The single best predictor of a young company’s survival is whether its customers already have a budget for the problem it solves. A tool that replaces a spreadsheet someone is paid to maintain, a service that reduces a bill the customer already receives, a piece of infrastructure that removes a task an engineer currently does by hand: these do not need to convince anyone that the problem exists. They need to be better and easier to buy.

Consumer ideas and category-creating products fail that test by definition. They have to create the budget as well as win it, which means spending on education, on marketing and on the long wait for behaviour to change. Some succeed spectacularly. Most run out of money first.

Reliability is a feature people pay for

Boring products compete on characteristics that exciting ones neglect: uptime, support response, backwards compatibility, clear pricing, predictable roadmaps. These sound like operational details. To a customer who has to defend the purchase internally, they are the product. A tool that is slightly less clever but never breaks wins against one that is brilliant on a good day.

This is also why boring companies tend to have better economics. Customers who buy for reliability stay, and a customer who stays for years is worth far more than one who arrives on a wave of attention and leaves on the next one.

Infrastructure compounds

Companies that sell tools to builders benefit from everything the builders build. A payment service, a hosting platform, a data pipeline or a component library grows as its customers grow, without having to win each end user individually. The growth is slower at first and much steadier later, and it is far less exposed to shifts in consumer taste.

The trade-off is visibility. Infrastructure companies are rarely famous. Their customers are, and the customers do not usually mention what they are built on.

Boring is not the same as small

The mistake is to read “boring” as “modest”. Some of the largest technology companies sell databases, logistics software, identity management and cloud storage. Their ambition is enormous. It is simply pointed at problems that do not photograph well.

The founder’s question

For someone starting a company, the practical question is not “what is exciting?” but “who is already paying to have this problem, and how badly is their current solution serving them?” The answer to that question is usually unglamorous, frequently profitable and, over a decade, more transformative than most of the ideas that got the headlines.

OCXLY covers innovation with that lens. We are interested in what ships and what lasts, and the two are more closely related than the coverage suggests.

OCXLY Digital Media House — Stories

The quiet return of the static web

Why it came back

What “static” actually means now

The trade-offs are real

Why it matters for readers

The creator economy has a middle-class problem

Feeds reward the extremes

Rented land

What the middle looks like when it works

The trade-offs

Why it matters

A field guide to spotting research that will actually ship

Does it work outside the demo?

What has to be true about manufacturing?

Who has to change their behaviour?

Is the cost trajectory plausible?

Who benefits, and can they pay?

What is the failure mode?

Using the guide

What "open source" actually promises, and what it doesn't

What the licence gives you

What it does not give you

The supply-chain framing

What good stewardship looks like

The point

Your website is only as private as its third-party scripts

What a third-party script can do

The measurable gap

The defensive tools

The editorial version of the problem

A simple test

Why group chats became the real social network

The performance problem

What changed technically

The costs

The new shape of “social”

Why it matters

Passkeys, explained without the marketing

How they work, briefly

Where the trust goes

The practical questions

The honest verdict

Design systems are how small teams pretend to be big ones

Tokens before components

Components are decisions made visible

The refusal list

Why it works for small teams specifically

Where to start

Local AI is a hardware story

The bottleneck is not compute

Quantisation is a bandwidth trick

The dedicated accelerator question

Why it matters beyond speed

What to watch

RSS never died. It just stopped being marketed.

What it does

Why it faded

Why it is back

What a good feed looks like

Where OCXLY stands

Digital identity is now a stack of accounts you don't control

How it got this way

What portability would mean

The security angle

The policy question

What you can do now

The startup ideas that survive are boring on purpose

The budget line test

Reliability is a feature people pay for

Infrastructure compounds

Boring is not the same as small

The founder’s question