The Build Archive

Seventeen repositories in five months, and what the pattern reveals

Every fact in this case study can be checked in about ninety seconds by loading github.com/TheDevChopra. That makes it the most verifiable document in this archive and the reason it is worth writing.

The record: nineteen public repositories, eighteen of them authored by me and one a fork. Seventeen of the eighteen were pushed between 18 February and 29 June 2026. The remaining one, a password strength and hashing utility, dates from August 2025. TypeScript, JavaScript and Python, in that order of volume.

This is not a case study about one product. It is a case study about a working method, examined from the outside, using the only artifact that cannot be embellished: a commit history with dates on it.

---

01 · Context

In February 2026 I started building at a rate I had not previously sustained. The list, in the order the record shows:

Pushed	Repository	What it is
18 Feb	dev-portfolio	Portfolio site
2 Mar	tapqr-platform	TapQR frontend
2 Mar	tapqr-backend	TapQR API
12 Mar	pos-prototype	Point-of-sale prototype
19 Mar	mysterybox	Undescribed
27 Mar	Inflio	Reverse influencer discovery: find creators before they go viral
27 Mar	Startup-Graveyard	See how funded startups failed
4 Apr	temply	Free template exchange platform
4 Apr	StealPage	Undescribed
4 May	tapbio	Link-in-bio builder focused on conversion blocks
9 May	looplite-tracker	Undescribed
15 May	flowbit	Undescribed
5 Jun	trippilotai	BITSoM capstone project
17 Jun	roommate-os	Undescribed
17 Jun	hirequest-ai	Undescribed
18 Jun	hridaychawla	"Something for a cousin"
29 Jun	creatoros	CreatorOS, an influencer co-pilot

Plus password-strength-hashing from August 2025, a CLI and demo for password strength checks and hashing, which lines up with cybersecurity coursework rather than with this run.

Seventeen repositories across five calendar months while enrolled in a graduate programme. Two of them are the two halves of a live product. One is a university capstone. One is a favour for a family member. Six have no description at all.

I want to examine that record rather than present it, because the interesting questions are the uncomfortable ones. What does this rate actually demonstrate? What does it cost? And why can I not point a founder at most of it?

02 · Problem

The problem this working method was solving, and the problem it created.

What it solved: I did not know what I wanted to build. Product instinct is not introspectable. You cannot sit down and reason your way to which problem you should spend two years on. You find out by building small things and noticing which ones you keep returning to. Seventeen repositories is a search procedure.

What it created: a body of work that is nearly unusable as evidence. Six of the eighteen have no description, no README anyone would learn from, and no deployed instance. To an outside reader they are folder names. Work that took real hours is currently indistinguishable from work that never happened, which is a failure of packaging rather than of building, and it is entirely mine.

And a positioning problem. A profile with seventeen repositories in five months reads two ways depending on the reader. To one founder it says: this person ships, unusually fast, alone. To another it says: this person cannot finish anything. The record is identical. The interpretation is set by whether the reader can see a thesis behind the list, and until this document existed there was none.

03 · Why the problem mattered

Because unpackaged work has no market value. A founder assessing whether to hire me for product work is trying to answer one question: can this person take an ambiguous problem and produce something real. My repository list is the strongest available evidence and it was sitting in its least legible form.

Because the search only pays off if you notice what you found. The point of building many small things is the signal in which ones recur. If nobody, including me, ever reads the pattern back, then it was seventeen disconnected efforts instead of one investigation. The pattern is in section 05 and finding it required treating my own history as a source.

Because the rate itself is the claim worth making, and it is the one thing here nobody can dispute. I can be argued with about design judgement or product strategy. The dates are the dates.

04 · Research

There was no research programme behind this. Saying otherwise would be an invention, and the honest description of the method is less impressive and more useful.

How ideas actually arrived. Mostly from friction I hit personally, plus adjacency to whatever I was already working on. roommate-os is a shared-living problem I had. looplite-tracker is a habit-tracking itch. Startup-Graveyard came from reading failure post-mortems and wanting them in one place. tapbio came from noticing that link-in-bio tools are optimised for aesthetics and not for conversion, which is a genuine product observation and the only one in the list that came from analysis rather than annoyance.

What validation happened before building. For most of them, none. I built first and evaluated after, because with AI assistance the build was often cheaper than the evaluation would have been. That is a defensible tradeoff at prototype scale and a terrible one at product scale, and section 14 has more to say about it.

Research I did do, for this document. I read my own repository list as a data set: dates, descriptions, languages, clustering, gaps. That is desk research on a single-operator sample, which is what it is, and it produced section 05.

05 · Insights

The clustering is the finding. Read chronologically, the list is not random.

Cluster one: payments and commerce infrastructure. tapqr-platform, tapqr-backend, pos-prototype, all inside eleven days in early March. Three repositories on the same theme in one fortnight is not a coincidence, it is a concentration of attention. TapQR is the only one of the seventeen that reached a live product with pricing, which suggests the concentration was correct.

Cluster two: the creator economy, returned to three times across three months. Inflio in March, reverse influencer discovery, finding creators before they go viral. tapbio in May, link-in-bio built around conversion rather than presentation. creatoros in June, an influencer co-pilot, and the most recent repository in the archive. Three separate attempts at the same market from three angles: discovery for brands, conversion for creators, then operations for creators. Coming back to a problem space three times, unprompted, at three-week to eight-week intervals, is the strongest product signal in this entire record. It is the thing I would not have noticed without reading the archive as data.

Cluster three: tools for builders. temply, a template exchange. Startup-Graveyard, structured startup failures. flowbit and StealPage, undescribed but named like developer utilities. Building for people like me, which is the most common trap in indie software: the audience is easy to reach and rarely willing to pay.

Cluster four: personal utilities. looplite-tracker, roommate-os, mysterybox. Genuine itches, no commercial intent, and useful precisely because they are honest about that.

Two singletons. trippilotai, the BITSoM capstone, which is a student project and labelled as one. hridaychawla, described in my own words as "something for a cousin", which I keep in the list because deleting it would make the archive look more strategic than it is.

The language finding. TypeScript almost throughout. Not a fashion choice: type safety is what makes it possible to move fast alone, because the compiler absorbs the class of mistake that a code reviewer or a QA pass would otherwise catch. One-person velocity at this rate is partly a tooling artifact.

The gap finding. Nothing between mid-August 2025 and mid-February 2026. Six months. That is not a lapse to explain away, it is what a record looks like when someone is doing other things, and it is also the fact that makes the February-to-June density mean something.

06 · Product thinking

The marginal cost of an experiment collapsed, and that changes what an experiment is for. Building a working prototype used to cost enough that you had to be substantially confident before starting, which meant validation preceded building. With current AI coding assistance the build can be cheaper than a proper validation exercise. When that inverts, building becomes a legitimate research method rather than a commitment. Seventeen repositories in five months is only rational under those conditions.

This is my reading of my own working conditions rather than a measured claim, and I want to be careful with it, because it is the kind of statement that flatters the person making it. What I can say concretely: several of these went from idea to working prototype in a small number of days, alone, which was not available to me two years ago.

But the cost did not disappear, it moved. Deciding what to build, judging whether it worked, packaging it so someone else can understand it, and maintaining it are all unchanged. The archive is proof: the building got done seventeen times, the packaging got done twice. When one input gets cheap, the bottleneck relocates to the ones that did not, and I optimised the wrong one.

Prototype, product and experiment are three different objects and should be labelled as three. A prototype answers a build question. An experiment answers a demand question. A product has users. Of the seventeen, one is a product, three or four are prototypes, and the rest are experiments. Calling any of the experiments products would be the exact fabrication this archive exists to avoid.

On portfolio strategy. The correct move is not fewer builds. It is the same number of builds with a decision at the end of each: kill it, park it with a public README, or invest. I did none of the three, so everything stayed in an indeterminate state, which is why the profile reads as unfinished rather than as a portfolio of concluded experiments.

07 · Strategy

The strategy visible in the record, which was partly deliberate and partly retrospective.

Search broadly, then concentrate. Wide sampling in March, then a real concentration on TapQR, which became the only project with a live URL and a price. This is the right shape and it happened at least half by accident.

Build alone, choose the stack accordingly. TypeScript for everything, one framework, one deployment pattern. Consistency across projects is what allows the second project to be faster than the first, and by the fifth the scaffolding cost is nearly zero. Standardising your own stack is an underrated velocity decision for a solo builder.

Let interest be the signal. Rather than force a roadmap, notice what you return to. The creator-economy cluster is what that produced, and I would now act on it directly instead of waiting to notice it.

What is missing from the strategy: an exit condition per project. Every experiment needs a stopping rule written before it starts. Without one, projects do not end, they fade, and a faded project is worse than a killed one because it still occupies attention and it litters the record.

08 · Information architecture

Not a product's architecture. The archive's, which is the thing that is broken.

What a reader currently encounters:

github.com/TheDevChopra
  19 repositories, sorted by last push
  6 with no description
  1 fork
  no pinned selection
  no grouping
  no indication of which are live

What it should be:

The Archive
  Shipped, with users        TapQR
  Prototypes, deployed       [needs URLs]
  Experiments, concluded     Inflio, tapbio, Startup-Graveyard, temply …
  Personal utilities         roommate-os, looplite-tracker, mysterybox
  Coursework                 trippilotai, password-strength-hashing
  Not a project              hridaychawla

Two changes carry almost all of the value. First, pinning six repositories so the profile leads with a curated selection instead of chronological order. Second, writing a description for the six that have none. Both are under an hour of work and they are the difference between a founder seeing a body of work and a founder seeing a scroll.

The taxonomy matters more than the presentation. The reason the profile reads as unfinished is that finished and unfinished are visually identical.

09 · UX and design

The archive has one design surface, the README, and I mostly did not use it.

A README is the product page for a repository. It answers what this is, why it exists, whether it runs, and whether it is maintained. Six repositories answer none of those questions. Those are the six that a founder skims past.

The minimum viable README, for a prototype, is four lines. One sentence on what it is. One on why it was built. Status: prototype, abandoned, or maintained. A link if it is deployed. That is a two-minute artifact and it converts an unreadable folder into a legible experiment.

Screenshots are the highest-return addition and I have almost none in repositories. A reader will look at an image and will not clone and run a project to see what it looks like. Twelve interface screens exist elsewhere in my work. Almost none are in the repositories they belong to.

Undescribed work is not modesty and does not read as it. It reads as abandonment. If a project is dead, saying so is more credible than silence, because a person who marks their own dead projects is a person whose live ones can be believed.

10 · Technology

TypeScript for seventeen of eighteen. One repository in JavaScript-plus-Python territory and the payments backend in JavaScript. The uniformity is the interesting part: same language, same framework family, same deployment pattern, which is what allows a solo builder to start a new project on a Saturday without re-solving anything infrastructural.

Where the compiler substitutes for a team. Alone, there is no code review, no QA pass and no second pair of eyes. Static types absorb a meaningful fraction of what those processes would catch. This is not a language preference argument; it is a statement about which safety nets exist when you are one person moving fast.

What the archive shows about depth. Two repositories for one product, a frontend and a separate backend, is the only place in the record where a project has real architectural separation. That is consistent with what it is: the one project that went further than a prototype.

What the archive cannot show. Test coverage, code quality, whether any of it runs today. I am not going to assert any of those. A repository proves that code was written, and it does not prove the code is good, and the difference is worth being honest about in a document whose entire premise is verifiability.

One claim I will make about method. Heavy AI assistance throughout, for scaffolding, for boilerplate, for unfamiliar APIs. The judgement about what to build and how to structure it was mine. Anyone claiming this cadence without tooling assistance in 2026 would be describing something other than what happened.

11 · Marketing and GTM

Almost none, and that is the archive's central commercial failure.

Of seventeen repositories from 2026, one has a live public URL with pricing. The rest have no landing page, no announcement, no distribution and, in six cases, no description. Work that nobody can find has no market value regardless of its quality.

The specific missed opportunity: Inflio and creatoros. Reverse influencer discovery and an influencer co-pilot are both real product ideas in a market with money in it. Three separate builds against one market, and not one of them has a landing page. Had any of the three been deployed with a two-paragraph page and posted once where creator-economy people gather, I would now have demand evidence for the strongest thesis in my archive. Instead I have three repositories and an inference.

Claims removed. Three projects promoted elsewhere on my site carry substantial user numbers: five thousand-plus beta users, twelve thousand-plus active users, fifty thousand-plus sessions in a launch week. None of the three has a repository in this archive, a live URL, a screenshot or an app listing. They are excluded from this document and queued for either evidence or deletion. The contrast is the point of this case study: seventeen modest, dated, checkable repositories are worth more than three impressive unverifiable ones.

12 · Execution

Eighteen authored repositories. Seventeen between 18 February and 29 June 2026, one from August 2025. One fork.

Of those:

• 1 live product with public pricing: TapQR, across two repositories
• 1 university capstone: TripPilot AI, BITSoM
• 3 described experiments in one market: Inflio, tapbio, CreatorOS
• 3 described builder tools: temply, Startup-Graveyard, plus the portfolio site
• 6 undescribed repositories: mysterybox, StealPage, flowbit, looplite-tracker, roommate-os, hirequest-ai
• 1 personal favour: hridaychawla
• 1 coursework utility: password-strength-hashing, August 2025

Deployed and publicly reachable: one. Documented well enough for a stranger: two.

13 · Results

The result is the record, and the record is the strongest evidence in this portfolio. Seventeen repositories in five calendar months, dated, public, and impossible to embellish. For the question a founder is actually asking, can this person turn an idea into working software quickly and alone, this is better evidence than any case study I could write.

No usage metrics are reported, because none exist. These projects were not instrumented, most were not deployed, and none had users I could count. There is nothing to report and I am not going to manufacture something.

What the record proves: shipping cadence, breadth across problem domains, consistent technical choices, and a repeated unprompted return to one market.

What it does not prove: that any of it works well, that anyone wanted it, or that I can operate inside a team. Volume is evidence of throughput and nothing else. Anyone reading this as more than that is reading too much into it, and I would rather say so than let it be inferred.

14 · What went wrong

I built seventeen things and packaged two. This is the failure that costs the most and it is embarrassingly cheap to fix. Six repositories with no description represent real hours that are currently invisible. An hour of writing would recover most of that.

I never deployed the creator-economy work. The clearest product signal in five months of building, three times over, and not one live URL. Had I put Inflio in front of even twenty brands, I would know something about demand instead of having a pattern to interpret. This is the single largest opportunity cost in the archive.

I let building substitute for deciding. Building became the way I avoided the harder question of what to commit to. Starting the next thing feels like progress and is much easier than finishing the last one, and with AI assistance the next thing is always available. The archive documents a cadence that occasionally functioned as productive avoidance.

No project had a stopping rule. Nothing was killed, so nothing concluded. Fourteen repositories exist in an indeterminate state that is neither alive nor dead, and that indeterminacy is what makes the profile read as unfinished.

I did not notice my own pattern for four months. Three attempts at one market, spaced weeks apart, and I only saw the thesis when I read the archive as a data set for this document. Reviewing your own record is a cheap and neglected practice. I would now do it monthly.

The portfolio built on top of this ignored it. My site promoted three projects with large user numbers and no artifacts, while seventeen verifiable repositories went unmentioned. I was marketing the least defensible part of my work and hiding the most defensible. That is not a small misjudgement; it is exactly backwards.

15 · What I learned

Reading your own archive is a research method. The pattern in your work is legible from the outside and invisible from the inside. Descriptions, dates and clustering told me something about my own product instincts that no amount of reflection produced.

Packaging is not a lesser activity than building. I treated the README as admin. It is the interface to the work, and work without an interface does not exist for anyone but its author.

When the cost of building drops, the discipline has to move to deciding. The scarce skill in 2026 is not producing software, it is choosing which software to finish and knowing when to stop. Cheap building makes that harder, not easier, because it removes the natural friction that used to force the decision.

Consistency of stack is compound interest. Same language, same framework, same deployment for seventeen projects. By the fifth, starting costs nothing. This is the most practical velocity lesson in the archive.

Returning to a problem three times unprompted means something. Trust that signal over any amount of market analysis, because it is evidence about you, and you are the one who has to sustain the work.

A dated public record beats a polished private claim. Seventeen checkable repositories outperformed every unverifiable metric on my site, and the metrics were actively damaging by comparison.

16 · What I would do differently

Write the four-line README at the moment of the first commit, not later. What it is, why, status, link. Never later, because later does not arrive.

Deploy everything, even badly. A working URL on free hosting, however rough. The difference between a repository and a link is the difference between a claim and a demonstration.

Set a stopping rule before starting. "If nobody uses this in two weeks I archive it publicly and write one paragraph about why." Concluded experiments are an asset. Abandoned ones are noise.

Act on the recurrence signal immediately. The moment I built the second creator-economy tool I should have named the thesis and gone deep instead of building a third variation and moving on.

Review the archive monthly. Fifteen minutes reading my own commit history, looking for the pattern. It is the cheapest strategic input available to me.

Pin six and let the profile lead with judgement rather than chronology. Curation is the difference between a portfolio and a scroll.

Take screenshots while building. Twelve interface screens exist somewhere other than the repositories they came from. A screenshot in a README does more work than a paragraph.

17 · Current status

The archive is public, static, and mostly undocumented. That is the correctable part.

Item	Status
Public repositories	19 total: 18 authored, 1 fork
2026 run	17 repositories, 18 February to 29 June
Earliest	password-strength-hashing, August 2025
Most recent	creatoros, 29 June 2026
Live with public pricing	1 (TapQR)
Repositories with no description	6
Repositories with a deployed URL	1 confirmed
Primary languages	TypeScript, JavaScript, Python
Usage metrics	None. Never instrumented.
Pinned selection	None

The gap between what this record could say and what it currently says is a few hours of writing, not months of building. That is the most actionable finding in this archive.

---

Related reading in this archive

• What seventeen products in five months actually taught me: the argument version of this record
• The case for building many small products: why breadth is a strategy and where it fails
• Shipping MVPs with AI coding tools: the tooling that makes this cadence possible, and what it does not solve
• The generalist product builder: reading breadth as a signal rather than a gap
• TapQR: the one project in the archive that reached a price
• BuildWithDev: the platform that should be indexing all of this
• Productivity claims in AI-assisted software development: the published studies set against this record

Sources

1. GitHub profile, TheDevChopra: bio "Product Builder | Generalist | AI", location Delhi, India, website devchopra.life. Retrieved 25 August 2026. https://github.com/TheDevChopra
2. GitHub repositories tab: 19 repositories with names, descriptions, primary languages and last-push dates as recorded in section 01. Retrieved 25 August 2026. https://github.com/TheDevChopra?tab=repositories
3. tapqr.live: the one deployed product with public pricing. https://tapqr.live