It goes like this. We, as internet people, are all able to create free accounts on a number of global platforms, and each of these free accounts can be used to deploy some part of a larger app. (Which kind of app — and what “deploy” even means here — we’ll get to shortly.)
These free accounts can be subdivided further, into projects, services, features and so on — and each of those subdivisions can be a deployment space, too.
We’ll tie that all together in a second, but first, the liverfluke analogy. If you haven’t heard of the lancet liver fluke, it’s kind of absurd. This tiny parasite hijacks three unrelated species that never otherwise cooperate — a snail, an ant, and a grazing cow — and marshals them into a single pipeline that exists only to move the fluke through its life cycle. It even mind-controls the ant into climbing a blade of grass at dawn so the grazing cow eats it.
Yeah. Nature.
Free personal accounts
Back to the free personal accounts, then (your accounts on Google, Cloudflare, etc.). We’ll call each of these — be it the account itself or a relevant project or feature within it — a host. Taken together, and in light of our app-deployment scenario, these hosts add up to something like a liverfluke pipeline of snails, ants and cows.
Next, let’s separate the hosts into ones that can serve an app’s frontend needs and ones that do the backend.
Frontend needs
- Telegram:: If an app needs a chat-style UI, Telegram can be that — the place where the user chats away with whatever backend lies beneath.
- Google Docs:: Likewise, Google Docs, Sheets and Forms can be windows to backends that live elsewhere, serving as the place where the user reads things out and types things in.
Backend needs
- Cloudflare:: The backend machinery you get with a free account here is a lot! (People are sleeping on Cloudflare, in our opinion.)
- Firebase:: Google’s app platform — home to Firestore, Firebase Auth and all that good stuff.
And many more.
Each account handles its own component, and, with a little finesse, the components all start talking to each other — meaning the end user can start using the app as normal. Or, in liverfluke terms, each species gets taken over in the proper order until there exists a pipeline serving the fluke’s ultimate purpose.
Platforms, plural
I say platforms plural because no single platform can host all the components a genuinely useful liverfluke app needs to work.
For example, one component of the app might live on Google Sheets, another on Cloudflare, another on Telegram. Three components, three accounts, three platforms, three separate companies behind them — but all the components talking to each other to create a single cohesive app experience that is greater than the sum of its parts.
This is only natural. Google simply does not offer a chat experience like Telegram’s, and Telegram does not offer a sign-in system like Google’s. If your app needs both parts, you have to wire Google and Telegram up together. But if you do wire them up — and then wire up a few more platforms for good measure — the result can be a highly functional cloud app that runs for free, or at very low cost, on a mesh of accounts that you, not the developer, control the sign-in for.
Not to be confused with a multi-platform suite
To be clear, this is not the same concept as a multi-platform software suite — say, some suite of accounting tools that offers an iOS app, a Chrome extension and maybe a Google Sheets add-on too. Yes, those can be seen as parts of an app that run across a mesh of user-controlled accounts, but that is still ordinary “install this here, install that there” behaviour.
No, this is actual deploying, sleeves rolled up. Adding a Telegram component to a liverfluke app means generating and managing an API key for a Telegram bot. Adding a Google Sheets component means activating Apps Script, and perhaps an OAuth client in the end user’s own Cloud Console. Adding a Cloudflare component means standing up a full-on key-value database. Adding an AWS component means free-tier Lambda functions. And so on.
The crux is this: with a multi-platform software suite, every piece the user installs is really a doorway back to the developer’s own infrastructure. (That’s why the pieces are so easy for the user to add.) The iOS app phones home, the Chrome extension phones home, and “home” is the developer’s servers.
Here there is no home to phone. The pieces are the app, wired directly to each other inside the user’s own accounts, with the developer’s own runtime infrastructure nowhere in the loop — because the loop is already complete. When all is done, the user is in real control of the fate of the app (minus, of course, the control that the platforms retain). Contrast this with the multi-platform suite, where if the developer stops paying their own bills then something, somewhere, is going to break.
Put another way: the liver fluke’s ecosystem doesn’t really exist outside of the snails, the ants and the cows. There is no separate and outside liverfluke hood. The snails, the ants and the cows, they are the hood.
Never really a thing before
Developers, being notoriously cheap, have long been using liverfluke-type methods to deploy apps for their own personal use, seeing this as a sort of infrastructure hack. One developer publishes a hobby project, another asks about it, and the first replies, “oh, well, the backend is on X and the frontend is on Y and some of it’s also on Z, and also…” — going on to list pretty much every free service they’ve managed to cobble together, in true liverfluke fashion.
What’s never really been a thing is developers deploying apps in this way for non-technical end users. In other words, developers have not been asking themselves: “Why don’t I design an app that an average person can deploy across their own Firebase, Cloudflare and Telegram accounts, so that they can run for free?” (Won’t that be fun!)
It’s not hard to see why a developer would write off this mesh of user-controlled free platform accounts as a serious deployment space for non-technical users.
First, the app would have to be designed in a very different way. It would have to lose its “ego,” a point we’ll come back to, and developers don’t so much like that.
Second, and more fundamental: non-technical users would get stuck. Maybe they’d need to hire a Fiverr freelancer, at a cost of potentially hundreds of dollars, to get the app actually deployed and working. A button here and a toggle there, this is not! Getting a meaningful app experience up and running across a mesh of free-tier personal platform accounts, spanning several platforms and companies, takes a lot of intricate wiring.
Not anymore!
Or at least that was the case. But AI has changed this. (AI has changed so many things.) A team of AI agents can now do in twenty minutes what would take a Fiverr freelancer weeks. So we’ve reached a time where, if a developer wants to treat this mesh of free-tier personal accounts as a viable deployment space for apps for non-technical users, they can actually do that.
The developer sends in a team of agents and lets them bounce from one account to the next, doing all the wiring themselves and navigating the edge cases that stop simpler scripts in their tracks. (The AI-driven edge-case navigation is what really makes this work.) For pennies. And without the user needing to understand anything beyond one critical skill: granting and revoking access.
And it all works! And — bonus — it can be maintained the same way.
So it is now possible for any user to “install,” or have installed for them, an app experience across their own mesh of free-tier personal accounts. They create the accounts, give the agent-master temporary access, and kick the agent-master out when done.
What makes a liverfluke app
It’s this “possible for everyone now” aspect that got us thinking we needed a slang term for this deployment method. While the specifics of how the liver fluke serves that purpose are still coming into focus, our experience deploying Ask My Agent suggests that the core characteristics of a liverfluke app land something along these lines:
- It runs entirely on user-controlled platform accounts.
- It typically straddles multiple platforms, from multiple companies — typically global tech firms.
- Those accounts typically have generous free tiers, meaning the app, once deployed, can scale to a decent amount of usage for free.
- These accounts are often newly created, and thus empty from a privacy standpoint.
- It typically leverages nerd-level features of these accounts: APIs, mini VMs, databases, scripts and so on.
- The end user is themselves typically not a nerd. (The juxtaposition between this point and the one before it is a defining trait.)
- The developer uses an AI agent, or a team of them, to do the wiring up, which requires the user to grant access to the agent-master. (Understanding how access-granting works is a big part of the learning curve.)
- The developer often exits after wiring up, by way of the end user simply revoking access to the project or account.
- Once the app is running there is nothing the developer can switch off.
- The deployed experience, though mish-mash in nature, has a genuinely cohesive feel to it — a bit of a Ghost in the Machine feel. (More on that below.)
Several of those points overlap, and there’s a fair amount of nuance to some. For example, when we say “accounts,” we could mean the whole account, a project within the account (such as a Google Cloud project), a service within the project (such as a separate OAuth client), or something as granular as a single Google Sheet. (With certain Apps Script skills, you can run a fairly robust app component housed entirely within one Sheet.)
The “straddles several platforms” point is also nuanced. “If your agents can get access to the user’s Firebase account, then why not just do everything there? Why ask the user to grant access to all these other accounts?” These are questions we sometimes get. Part of the answer is user experience. Let’s say the liverfluke app needs a chat. Yes, you could deploy an open-source chat on the end user’s Firebase, but how well is it going to work? What’s the latency? Where is the user going to access it from? And so on. It’s usually far better to integrate a Telegram bot than to deploy your own Firebase-hosted chat.
Most often, though, Platform A, which is critical for Thing X, just doesn’t have Thing Y — and since you also need Thing Y, you need to add Platform B. Say a liverfluke app leverages AWS for something important, but also needs the user to point a domain they own at it. AWS really isn’t in that business; domain registration, reverse proxying, edge caching and free unmetered DDoS protection are much more in Cloudflare’s realm (or GoDaddy’s, etc.).
Last, the point about end users being typically non-technical is also a packed one. When we mention to others that our own Ask My Agent app runs on the end user’s own Cloudflare key-value database, or on their own Google OAuth client, people often assume our end users are developers. The truth is that most of our end users have no idea what OAuth means — nor should they. They’re just regular users who managed to figure out how to create an account and share access with a startup.
Parasitic or symbiotic?
The liverfluke analogy is an obvious segue to jokes that turn users or developers of these kinds of apps into parasites — but the liverfluke itself is just such a cool part of the natural world that we couldn’t not use it, parasite jokes notwithstanding. (It’s also very easy to say and remember.)
This truth is a win-win, for users, developers and the platforms themselves.
For users, the win is more control and less cost. Control, because access is theirs to grant and theirs to revoke — the app runs inside accounts they own, and the security underneath it is maintained by the well-funded engineering teams of the platforms, not by a five-person startup doing its best (insert blushing emoji). Cost, because the user is no longer quietly subsidising a startup’s infrastructure bill. When the developer has nothing to keep running, the developer is under far less pressure to charge a subscription — and that saving flows straight back to the user.
For developers, the win is outsourcing the tricky stuff to where it belongs. Sign-in, uptime, storage, edge delivery — these are solved problems at the platform level, and re-solving them in-house is just reinventing the wheel (often square-shaped). Shedding all that frees the developer to focus on support and customisation, which, we’d argue, is where the real developer economy is heading in the age of AI.
And the platforms win by having more users, greater exposure, and — maybe most interestingly for them — regular, non-nerd users finding their way into parts of the platform that previously only nerd users would ever touch. Every liverfluke deployment mints a few more everyday people with an Apps Script project or a key-value database to their name, and that is exactly the kind of stickiness platforms spend real money trying to buy.
The liverfluke user experience
So what does it feel like to use a liverfluke app? There is a definite Ghost in the Machine feel to it. In Ask My Agent’s case: the system prompt is a Google Doc. Chat histories land in a dedicated Google Sheet. When a chat happens, the user is pinged on Telegram and can jump in right there — and the jump-in shows up in the Sheet’s history. Other parts install as a notification-enabled PWA on the user’s phone.
Tying it all together is a pinboard-style dashboard, in our case hosted on Cloudflare. (More on why this pinboarding matters in the design section below.)
The result, for many users, is the feeling that there is a thing living across their online world. What’s striking is how intuitive that turns out to be — partly because operating systems themselves have been drifting this way for years, most visibly in how notifications have evolved to work.
“Installation”
Installing a liverfluke app can be something of an event.
Typically there’s no App Store, or extension gallery, or other such place from which the user clicks to download. There technically could be — think of apps that run locally after download and never call home to any server, or those pre-formed VM images found on cloud marketplaces, click-to-deploy onto your own VM. But more often than not, it’s a case of the developer sending the agents on in, and the agents taking care of the many edge cases that would stymie any less intelligent deployment method.
For Ask My Agent, we do it over a training call. Ask My Agent is in the business of personal agents, and a personal agent is something most people need training on anyway. (We firmly believe in the future of human-to-human training for AI, ironic as that sounds.) For us, everything begins with the training call — that call is the real bulk of the product.
At the start of the call, the customer is guided to create a few accounts and projects — a Cloudflare account, a Google Cloud project, and more — and share access to those with our team. (The accounts are almost always empty at this stage.)
Once that’s done, the training starts: the user learns how an agent link is created and shared, how to run a small fleet of personal agents that sit behind those links, and so on. While that’s happening, our human bot-master sends in a ferocious team of red-bulled-up agents to wire up a full frontend and backend across those newly shared accounts — a job no human could do in the same amount of time. AI has changed the game.
By the end of the call, voilà: the app exists, and the user has a pretty good idea of how to use it.
Designing a liverfluke app
Ask My Agent isn’t our only liverfluke app (we have a few others in the works), and we’ve been at this for a little while, so we have some general intuitions for how liverfluke design can work (grain of salt accepted).
You can approach design from the platform side first, if you want. Do you want your liverfluke app to span Telegram, Cloudflare and MongoDB? Or Google Sheets, Cloudflare and some free-tier Azure instance thingy? Coming at it from the platform side usually means there’s a geographic angle — either your target users are limited in which platforms they can register accounts for, or there are local network effects that you want to ride. (Telegram, for example, is huge in certain parts of the world, yet hardly used in others.)
Or you can come from the functionality side: what stuff does this app need to do, and what is the ideal set of platforms to wire together to get that stuff done, regardless of how popular they are and where.
This, incidentally, touches on the “ego loss” we alluded to earlier: the app has to accept that it can’t have its own unmistakable design language throughout. Rather, it must embrace the fact that the thing making the app unique is the “ghost in the shell” feel it gives off — something much harder to pin down, more of a je ne sais quoi than any form of classical trade dress.
It still needs one surface that pins all the pieces together — some kind of pinboard dashboard. Every piece can live wherever it lives, so long as there exists this pinboard component somewhere. But by and large this is an exercise in feels rather than looks, and that takes some serious getting used to.
Maintaining a liverfluke app
On the face of it, a liverfluke app sounds like a maintenance disaster. You have an app running inside the end user’s own accounts, on infrastructure the end user may have no real understanding of — and the team that set it up (and therefore does understand it) has since been kicked out.
All apps need maintenance, and liverfluke apps are no different. (Worth separating, though: maintenance in the sense of fixes and security updates is one thing; customising or augmenting the app is a different thing, and usually this latter area is where user interest lies.)
The answer lies in the same trick that installed the app in the first place. The user re-grants access, the agent team comes back in, patches or upgrades what’s needed, and gets out again. Liverfluke maintenance is just a liverfluke install all over again, at a smaller scale.
Pricing a liverfluke app
A liverfluke app doesn’t live anywhere the developer owns. There is nothing to turn off. So you can’t, in good conscience, charge for electricity — or for any proxy of electricity.
We think the natural business model is on-demand human support. It’s rather ironic that some of the best startup business models in the age of AI centre on human love and attention — and some of the worst on trying to out-AI the big AIs — but here we are!
We’ll report back as Ask My Agent grows, but so far, charging for the wire-up call plus ongoing support seems best for both sides. The wire-up call doubles as a training session and as the window when the agents go in — the user is right there, able to grant access and flip switches as needed.
We charge per wire-up, which takes about sixty minutes on average.
Liverfluke apps and privacy
Liverfluke apps are very private in one specific sense: after being “kicked out” post setup, the developer cannot see anything that goes on. This is because there is no central, developer-controlled database where your data is aggregated. In a traditional SaaS model, your data lives on the developer’s servers; if they are breached, or if they decide to change their privacy policy, your data is at risk. With the liverfluke model, the “mothership” is your own set of accounts. Your chat history, your files, and your logic stay within your own digital perimeter, protected by the global-scale security of platforms like Google and Cloudflare rather than the potentially shaky security of a small startup.
Liverfluke apps and ultimate ownership
Yes, the platform, be it Firebase, Cloudflare, Telegram or whatever else, ultimately owns the account. But a liverfluke deployment fills in a nice gap between self-hosted and installed from afar.
There is also a high level of interoperability. Because the app isn’t a monolithic block of code on a proprietary server, you can swap out components. If you decide you don’t like Telegram for chat, agents can wire out Telegram and wire in a different app, such as Discord, without rebuilding the backend logic. As a user, you are controlling a machine made of parts that you can replace. If engineered well, it breaks the “locked-in” cycle of modern software, where moving your data or experience from one provider to another is often an impossible chore.
On top of that, every platform is strongly incentivised to keep offering the free features that make it a candidate piece of the mesh in the first place. Telegram is not about to drop bot integration; Google is not about to put Apps Script behind a paywall. In that sense it’s a safe enough space to design for over the long term. (The bigger headache is the little changes each platform makes here and there — but again, AI can patch those up quickly.)
Get in touch!
I’ll leave it at that for now. If you’re interested in this liverfluke concept please get in touch with me, I’m always happy to jump on a call. Or try out Ask My Agent at askmyagent.love and see how the whole thing feels once up and running for you.