Inflio, tapbio and CreatorOS

Three attempts at one market in three months

Influencer marketing has a structural pricing problem that almost nobody in it talks about directly: by the time a creator is discoverable, they are no longer underpriced.

Every discovery platform indexes creators by follower count and engagement rate. Those numbers are also what set a creator's rates. So the moment a creator becomes findable through the standard tools, the market has already repriced them. Brands are paying efficient prices for reach that is efficiently priced, and the returns are correspondingly ordinary. The excess return, if it exists anywhere, is in the window before a creator is legible to the tooling.

That observation produced Inflio in March 2026. Then tapbio in May. Then CreatorOS in June. Three repositories, three angles on the same market, spaced across three months, and I did not deploy or announce a single one of them.

Status: self-initiated experiments. Three public repositories. No deployments, no users, no revenue. This document treats them as one investigation, because that is what the record shows they were.

---

01 · Context

The three projects, as I described them at the time:

Pushed	Repository	My own description
27 March 2026	Inflio	"A reverse influencer discovery platform that helps brands find high-potential creators before they go viral"
4 May 2026	tapbio	"A simple 'link in bio' builder but focused on conversion blocks"
29 June 2026	creatoros	"CreatorOS, an influencer co-pilot"

Read in order they trace a specific movement. The first serves brands and treats creators as inventory. The second serves creators and treats their traffic as the asset. The third serves creators and treats their whole operation as the problem.

I did not plan that arc. I built each one because it seemed like a good idea at the time, and the arc is visible only in retrospect. What it tells me, and this is the reason the three belong in one case study rather than three, is that I kept walking around the same market looking for the door. Three unprompted returns to one problem space over three months is the strongest product signal in my entire build record.

creatoros is also the most recent repository in my archive, which means this is where my attention actually was when the run ended.

02 · Problem

Three related problems, one per project.

Inflio: discovery is retrospective, and prediction is where the value would be. Brands using Aspire, Grin, Upfluence or in-platform tools search a ranked index by follower count, engagement rate, category and geography. That is a search over past performance. The commercially interesting question is different: which creators are about to matter. A brand that signs a creator three months before their audience triples has bought at a price the market has not set yet.

tapbio: link-in-bio tools are presentation tools sold as conversion tools. The category standard is a vertical list of visually consistent links. Every link has equal weight, which means the design expresses no priority. But the creator almost always has one thing they need a visitor to do this week: buy the thing, join the list, watch the video. A list of twelve equal links is a menu. A conversion surface needs a hierarchy.

CreatorOS: a creator is a small business with no operations function. Content, scheduling, cross-platform repurposing, brand outreach, negotiation, contracts, invoicing, chasing payment, tracking what performed. A creator does all of it, and the parts they are good at and enjoy are a minority of the total hours. That is the structural gap a co-pilot would fill.

And the problem underneath all three, which is the one that actually mattered: none of them shipped. Three repositories, zero landing pages, zero users, zero demand signal. Whatever the merits of each thesis, I learned nothing testable from any of them.

03 · Why the problem mattered

Because the creator economy is large, fragmented and full of underserved operators. Individual creators are running real businesses with no back office, and they are willing to pay for tools that recover hours. Fragmentation is what makes it attractive to a small builder: there is no single incumbent whose presence forecloses the space.

Because the discovery problem is genuinely unsolved and genuinely valuable. If the prediction were tractable, a tool that surfaced pre-viral creators would be worth a lot to brands. Section 05 is where I have to be honest about whether it is tractable, and the honest answer complicates the premise substantially.

Because link-in-bio is a category where the incumbent's design choices leave real room. Linktree and its imitators optimise for setup speed and visual consistency, which are the right goals for adoption and the wrong ones for outcomes. A creator with a launch does not want a tidy list.

And because this is where my instincts kept pointing. Three returns in three months is data about me. Ignoring it would be a strange thing to do with the only longitudinal evidence I have about my own product interests.

04 · Research

Method: desk research and product teardown, plus reading the academic literature on cascade prediction after the fact. No brand interviews, no creator interviews, no demand testing. That absence is the defining limitation of all three projects and it is why section 13 has nothing in it.

Product teardown. Existing influencer discovery platforms, and how they rank. Existing link-in-bio tools, and what their default templates optimise for. Existing creator tooling, which is mostly scheduling and analytics rather than operations.

Literature, and this is the part that changed my mind. After building Inflio I read the work on predicting cultural success, and it is not encouraging for the premise. Salganik, Dodds and Watts's MusicLab experiment showed that when participants could see what others had chosen, outcomes for the same songs diverged wildly across otherwise identical worlds, and that intrinsic quality explained only a modest share of success. Martin, Hofman, Sharma, Anderson and Watts later examined the limits of prediction in social systems directly and concluded that for cascade-like outcomes, performance is bounded well below what practitioners typically assume, even with rich data and strong models.

The implication for Inflio is uncomfortable and I would rather state it than bury it. If virality is substantially path-dependent rather than a property of the creator, then "find creators before they go viral" is asking a model to predict something close to the theoretical limit of unpredictability.

What I never did. No brand conversation to test whether they would buy a probabilistic signal. No creator conversation to test whether conversion blocks matter more than aesthetics. No test of whether operations pain is acute enough to pay for. Every one of those is a week of work and would have been worth more than any of the code.

05 · Insights

Inflio's premise is half right, and the half that is right is more interesting than the half that is wrong. Prediction of individual virality looks intractable. But that was never the only available framing. The tractable version is not "who will go viral" but "who is currently underpriced relative to their trajectory", which is a much more modest claim about growth rate, engagement velocity and audience quality rather than about a future spike. Underpricing does not require predicting a cascade. It only requires noticing that rates are set by follower count and follower count lags engagement. The literature kills the demo pitch and leaves the actual business intact, which is exactly the kind of finding that only appears if you go and read.

Engagement rate is the metric everyone uses and it is the easiest one to fake. Follower fraud and engagement pods exist because the market pays for the number. Any serious discovery product's real differentiator is audience quality assessment, not another ranking of the same gameable inputs.

tapbio's insight survives contact with the literature better. Iyengar and Lepper's finding that a display of twenty-four jams produced far less purchasing than six is the canonical demonstration that more options can reduce action. A link-in-bio page with twelve equal links is that experiment run on a creator's most valuable traffic. One primary action, with everything else subordinate, is the design that follows.

Link-in-bio traffic is high-intent and gets treated as low-intent. Somebody tapped a link in a bio after watching a video. That is the warmest traffic a creator has, and the standard product presents it with a menu. This is a genuine gap and it does not require any clever technology to exploit.

CreatorOS sits on the most defensible thesis of the three, and it is the least glamorous. Operations tooling is unfashionable and sticky. A creator who runs their sponsorship pipeline and invoicing in a tool does not casually leave. Discovery tools are switched between; operating systems are not.

The signal in the sequence: I moved from serving brands to serving creators and stayed there. Two of three, and the two later ones. That is worth acting on, and it also identifies which side of the market I actually understand.

06 · Product thinking

On which of the three I would build now: CreatorOS, and it is not close. The reasoning is about defensibility rather than appeal. Inflio requires solving a prediction problem that may be bounded, and it requires data access that platforms restrict, which is section 10's problem. tapbio is a good product in a category with a well-funded incumbent and low switching costs in both directions. CreatorOS addresses a daily pain, generates retention through accumulated data, and does not depend on predicting anything.

On the two-sided trap in Inflio. A discovery marketplace needs brands and creator data. Brands arrive if the data is good. The data is expensive to acquire and restricted. That is a cold-start problem where the expensive side must be solved first, alone, without revenue. For a solo builder that is close to disqualifying, and I should have recognised it before writing code rather than after reading a paper.

On MVP scope, per project. Inflio's minimum honest version is a single-category watchlist with transparent scoring, positioned as an underpricing signal rather than a virality oracle. tapbio's is one page, one primary action, one measured metric: click-through to the primary action versus a conventional list. CreatorOS's is the sponsorship pipeline alone, because outreach through to payment is the part with money attached and the part creators most visibly mishandle.

On what all three needed and none had: a demand test before a build. A landing page, a specific claim, and traffic from one place where the audience already gathers. Two days each. I built for weeks instead, three times, which is the mistake that defines this whole thread.

On pricing, which distinguishes them sharply. Inflio is a brand tool with brand budgets, so it can be expensive per seat. tapbio serves creators, who are numerous and price-sensitive, so it needs a free tier and mass adoption. CreatorOS can charge a monthly fee that is trivially justified against one recovered invoice, which is the easiest pricing conversation of the three.

07 · Strategy

Serve creators, not brands. This is the strategic conclusion of the whole thread and it is the one the sequence itself points to. Creators are reachable, underserved and can be acquired without an enterprise sales motion. Brands have budgets and require a sales function I do not have.

Choose the thesis that does not depend on prediction. Inflio's value proposition rests on forecasting something the literature suggests is hard to forecast. Operations tooling rests on the observation that creators waste hours, which requires no forecast at all.

Compete on outcomes where the incumbent competes on appearance. tapbio's whole position is that Linktree optimises for looking tidy and creators need to sell. That is a legitimate wedge and it needs conversion measurement built into the product to be credible.

Own the money workflow, because that is where retention lives. In CreatorOS the sponsorship pipeline is the wedge: outreach, rates, contract, delivery, invoice, payment received. Once a creator's income history is in a tool, the tool becomes infrastructure.

Test demand before building. Every time. This is stated as strategy rather than as a lesson because it is the specific policy change the thread produced.

08 · Information architecture

The three are structurally quite different, which is part of why building all three was inefficient.

Inflio, a research tool for a brand:

Watchlists                  saved sets of creators being tracked
  Creator
    Trajectory              growth rate, engagement velocity over time
    Audience quality        the differentiated part
    Signal explanation      why this creator surfaced, in plain language
Discovery                   filtered by category and trajectory, not size
Comparison                  side by side, because brands decide comparatively

The load-bearing element is signal explanation. A probabilistic recommendation without a reason is unusable in a brand context, because a marketer has to justify the spend to somebody else. An opaque score is not a product.

tapbio, a conversion surface:

Page
  Primary block             one action, visually dominant
  Secondary blocks          subordinate, ordered
  Social proof              optional
Analytics
  Click-through to primary  the only metric that matters

The architecture is the argument. Making one block structurally primary is what distinguishes it from a list.

CreatorOS, an operations system:

Pipeline                    the core: outreach → negotiation → contract → delivery → invoice → paid
Content                     calendar, cross-platform repurposing
Relationships               brands, contacts, history, past rates
Money                       invoices, outstanding, income by source
Insights                    what performed, what paid

Pipeline first. Everything else is reference data that the pipeline consumes. A creator opens this tool to answer "where is my money" and "what is due", and those are pipeline questions.

09 · UX and design

No interface artifacts from these three exist publicly, so this section describes the design problems rather than screens.

Inflio's design problem is communicating uncertainty to a buyer who wants certainty. A brand marketer wants a shortlist. The honest output is a ranked set with confidence levels and explanations. Presenting probabilistic output as definitive is how these tools lose credibility on the first miss, and presenting it too tentatively means nobody acts. The workable design shows the trajectory that produced the signal, so the user evaluates the evidence rather than trusting a number.

tapbio's design problem is that its whole value is one deliberate violation of visual consistency. Every other builder in the category makes all blocks look alike, and that consistency is what destroys conversion. So the primary block has to be visibly different in size, weight and colour, and the product's templates have to force that choice rather than offer it. A creator given the option to make everything equal will make everything equal, because it looks neater. Opinionated defaults are the product.

CreatorOS's design problem is information density against low tolerance. A pipeline view is inherently dense, and creators are not operations professionals and will not tolerate a CRM. The resolution is a single dominant view answering what needs attention today, with depth available and not presented. This is the opposite of the density argument that applies to professional audio tools, and the difference is expertise: a producer's mental model is already dense, a creator's is not.

Common to all three: mobile is not the secondary case. Creators work from phones. A tool that is comfortable on desktop and tolerable on mobile has inverted its priorities for this audience.

10 · Technology

TypeScript for all three, consistent with the rest of my archive. I am not going to describe implementation internals, because none of the three has documentation I can point a reader at.

The technical content worth recording is the constraint that makes one of these three much harder than the others.

Data access is Inflio's real blocker, and it is not an engineering problem. Reverse discovery requires longitudinal creator data across platforms: follower counts over time, engagement per post, audience composition. Every route to that data is restricted. Instagram's Graph API provides business and creator account data with permissions the account holder grants, which is fine for creators who opt in and useless for discovering creators who have not heard of you. TikTok's research API is gated to approved researchers with usage conditions. Scraping is against platform terms and is legally and operationally fragile.

So the honest architecture for Inflio is not a crawler. It is either a creator-opt-in network, which is a cold-start problem, or a licensed data relationship, which is a commercial arrangement rather than a build. The product's feasibility was gated by a data-access question I had not resolved before writing code, and that is a planning failure rather than a technical one.

tapbio is technically trivial and that is a strategic fact, not a compliment. Hosted pages, a block model, click tracking. Anyone can build it, so the defensibility is entirely in the opinionated design and the conversion measurement, and none of it is in the engineering.

CreatorOS's technical substance is integration surface, and it is genuinely awkward. Email for outreach, calendar for scheduling, platform analytics for performance, payment and invoicing. Each integration is small and each is a maintenance liability, which is the standard reason operations tools are hard to build alone and hard to displace once built.

Where AI belongs in each, stated carefully. In Inflio, scoring and explanation generation, grounded in retrieved metrics rather than generated from nothing. In tapbio, essentially nowhere, and resisting the urge to add it is the correct product decision. In CreatorOS, drafting outreach, extracting terms from a brand email, and summarising performance, all of which are language tasks with a human approving before anything is sent. Adding a model to a product that does not need one is the most common product error of this period, and one of these three genuinely does not need one.

11 · Marketing and GTM

None was done, and this is the failure that makes the whole thread a loss rather than a finding.

No landing page for any of the three. No announcement. No distribution. No waitlist. Three products, one of them addressing a market I had now approached three times, and not one public URL.

What it would have cost. A one-page site per project: the problem, the claim, an email capture. Two days each. Then one post in a place where the audience already gathers, and the creator economy has abundant such places. That is a week of work total for three real demand signals.

What I have instead. Three repositories and an inference. I can tell you what I think about this market. I cannot tell you what anybody in it thinks about my products, because I never asked and never gave them the chance to react.

This is the same failure documented in my build archive, and it recurring across the specific market I care most about is what makes it worth stating twice.

12 · Execution

Built:

• Inflio, TypeScript, pushed 27 March 2026: reverse influencer discovery for brands
• tapbio, TypeScript, pushed 4 May 2026: conversion-focused link-in-bio
• creatoros, TypeScript, pushed 29 June 2026: creator operations co-pilot

Not built:

• Any landing page
• Any deployment
• Any demand test
• Any brand or creator conversation
• Any resolution of Inflio's data-access dependency

Three repositories exist and are public. That is the extent of the artifact.

13 · Results

No results. No deployments, no users, no revenue, no demand data.

The output of three months of intermittent work on this market is three repositories and one insight I could have had from reading: that my product interests point at creators rather than brands, and at operations rather than prediction.

That insight is real and it is worth something. It cost far more than it needed to. A week of landing pages would have produced it plus actual demand evidence, and I chose three build cycles instead.

14 · What went wrong

I built three times and validated zero times. The central failure. Each project was a plausible thesis that could have been tested in two days and I chose weeks of building instead. Building is more enjoyable than validating and it feels like progress, and with AI assistance it is fast enough that the tradeoff never forces itself on you.

I built Inflio without resolving whether the data was obtainable. Reverse discovery needs longitudinal cross-platform creator data, and every route to it is restricted or licensed. That is a feasibility question and it belonged in the first hour, not after the code.

I did not read the relevant literature until after building. The prediction limits work directly bears on Inflio's premise. Half a day of reading would have reframed the product into its defensible version, which is the underpricing signal rather than the virality oracle, and I would have built the right thing.

I did not notice my own pattern until the third attempt was finished. Three unprompted returns to one market is a loud signal. I only heard it when reading my repository list as data, months later. Anyone building at volume should be reviewing their own record deliberately.

I abandoned each project at the point where the interesting work started. In all three cases the code got to roughly working and then stopped, which is precisely where the questions worth answering begin: does anyone want it, will they pay, does the conversion claim hold. I collected three beginnings.

I never wrote a README for any of them. Three descriptions of one sentence each, which is what makes this document necessary in order for the work to be legible at all.

15 · What I learned

Repeated unprompted return to a problem space is the most reliable signal you have about your own product instincts. It is worth more than market sizing, because market size tells you about the opportunity and this tells you what you will actually sustain.

Read the literature before building, not after. Half a day on cascade prediction would have changed Inflio's product definition entirely, and for the better. The academic work on a problem is usually cheap to find and frequently tells you which version of your idea is buildable.

A premise can be wrong in its headline and right in its substance. "Predict virality" appears to be near-unpredictable. "Identify creators whose rates lag their trajectory" is arithmetic. The pitch was the problem, not the business, and distinguishing between those two is a skill.

Check data feasibility before designing a data product. If the product needs data you cannot legally obtain at scale, no amount of design or engineering matters. This is the first question, not a later one.

Some products should not have AI in them. tapbio is better without a model. Recognising that in 2026 required actively resisting a default.

Cheap building removes the friction that used to force validation. When a build cost weeks of painful effort, you validated first out of self-preservation. Now you have to impose that discipline deliberately, because nothing else will.

16 · What I would do differently

Ship a landing page for CreatorOS this month, before writing another line of code. The specific claim: run your sponsorship pipeline from outreach to payment in one place. Email capture. One post where creators gather. Then decide based on what happens.

Reframe Inflio as an underpricing signal and scope it to one category. Transparent scoring, visible trajectory, explicit about being probabilistic. Solve the opt-in data question first or do not start.

Test tapbio's whole thesis with a single measurement. One creator, one launch, a conventional list against a single-primary-action page, click-through to the primary action compared. That is one week and it either validates the entire product or kills it.

Read for half a day before building anything with a prediction claim in it.

Write the four-line README at first commit. Three repositories are currently one sentence each.

Review my own build record monthly, looking specifically for repetition. The signal was there in May and I read it in August.

17 · Current status

Three public repositories. None deployed. One clear thesis, untested.

Project	Pushed	Status
Inflio	27 March 2026	Repository only. Premise reframed after reading; data access unresolved.
tapbio	4 May 2026	Repository only. Thesis testable in a week; untested.
CreatorOS	29 June 2026	Repository only. The one I would take forward.

Item	Status
Deployments	0 of 3
Landing pages	0 of 3
Users	0
Demand tests	0
READMEs	0
Conclusion of the thread	Serve creators, own the money workflow, stop predicting

---

Related reading in this archive

• The case for building many small products: the strategy this thread was executing, and its failure mode
• Why founders should care about activation before growth: the conversion argument behind tapbio
• What seventeen products in five months actually taught me: validation debt, generalised
• AI features and AI-native products are not the same thing: why tapbio should have no model in it
• The Build Archive: where these three sit in the wider record

Sources

1. GitHub, TheDevChopra/Inflio: "A reverse influencer discovery platform that helps brands find high-potential creators before they go viral", TypeScript, pushed 27 March 2026. https://github.com/TheDevChopra?tab=repositories
2. GitHub, TheDevChopra/tapbio: "A simple 'link in bio' builder but focused on conversion blocks", TypeScript, pushed 4 May 2026. https://github.com/TheDevChopra?tab=repositories
3. GitHub, TheDevChopra/creatoros: "CreatorOS - an Influencer Co Pilot.", TypeScript, pushed 29 June 2026. https://github.com/TheDevChopra?tab=repositories
4. M. J. Salganik, P. S. Dodds and D. J. Watts, "Experimental Study of Inequality and Unpredictability in an Artificial Cultural Market", Science 311(5762), 2006. https://www.science.org/doi/10.1126/science.1121066
5. T. Martin, J. M. Hofman, A. Sharma, A. Anderson and D. J. Watts, "Exploring Limits to Prediction in Complex Social Systems", WWW 2016. https://arxiv.org/abs/1602.01013
6. S. S. Iyengar and M. R. Lepper, "When Choice is Demotivating: Can One Desire Too Much of a Good Thing?", Journal of Personality and Social Psychology 79(6), 2000.
7. Meta, Instagram Graph API documentation: permissions model for business and creator accounts. https://developers.facebook.com/docs/instagram-api/
8. TikTok for Developers, Research API access conditions. https://developers.tiktok.com/products/research-api/