BuildWithDev

A public product lab, and what its own counter says

Self-initiated. Live. The homepage counter currently reads 00 / 30 PRODUCTS BUILT, PHASE 01: DISCOVERY, 0% COMPLETE.

That counter is the most useful sentence in this case study, so it goes at the top rather than buried in section 13. I built a site that publicly commits to shipping thirty products and instruments its own progress. The instrument says zero. Anyone can load the page and read it.

There is a version of this case study that quietly omits the counter. My portfolio has been running that version: it claimed BuildWithDev consolidated four SaaS tools, cut bounce rate 60% and generated ten-plus inbound leads in its launch month. None of that is evidenced, all of it is removed, and the counter is what replaces it.

---

01 · Context

I ship a lot of small things. Between February and June 2026 I authored seventeen repositories: NFC payment infrastructure, creator tooling, an AI trip planner, a link-in-bio, a POS prototype, a habit tracker, a roommate coordination app, an AI recruiter. Most were built alone, fast, with heavy AI assistance.

That volume creates a specific problem. Seventeen repositories is not a portfolio. It is a list. A founder looking at a GitHub profile sees activity and cannot tell whether the person behind it can think, or only type. The artifacts exist and the reasoning is invisible.

BuildWithDev was the answer to that: a place where the reasoning is the product. Not a blog attached to a portfolio, but a standing public commitment. Thirty products, built in the open, with the decisions written down as they happen.

The framing on the site is deliberately unsubtle. "Building 30 products in public. Documenting every failure, every win, every lesson." A visible phase indicator. A progress bar. It reads like a manifesto because that is the mechanism: a public number is harder to abandon quietly than a private intention.

Which is exactly why the number reading zero matters, and why this case study keeps it.

02 · Problem

Output without narrative does not compound. Each shipped project resets to zero attention. There is no accumulating asset, no reason for anyone to return, and no way for a stranger to understand a decision made three projects ago. Volume alone produces a longer list, not a stronger position.

A portfolio makes claims; it does not demonstrate thinking. The standard portfolio format asserts competence retrospectively, in polished form, after every uncertainty has resolved. A founder reading it learns what I say I did. They learn nothing about how I decide under ambiguity, which is the only thing they actually need to know before hiring me.

Freelance product work is a trust purchase and I had no trust surface. A founder handing over their product roadmap to a stranger is taking a substantial risk. Case studies reduce it a little. Watching someone reason in public over months reduces it much more, because it cannot be faked cheaply and it cannot be ghostwritten convincingly.

And the specific problem BuildWithDev now demonstrates: publishing a commitment is easy, and honouring it competes with paid work. That is the real finding from this project and it is in section 14.

03 · Why the problem mattered

Because the market I want does not respond to advertising. US startup founders looking for product and AI help do not read cold outreach. They ask people they trust, or they find someone whose writing already answered a question they had. The only two viable channels are referral and demonstrated thinking. I had access to neither, and only one of them can be built from a standing start.

Because in 2026 the cost of building fell and the cost of judgement did not. AI coding tools mean anyone can produce a working application in a weekend. That makes shipped software a weaker signal than it was even two years ago. What remains scarce is knowing which software to build, when to stop, and what to cut. Judgement is not visible in a repository. It is only visible in writing.

Because the anonymous generalist is the hardest thing to hire. My positioning spans product, design, engineering and growth. To a founder that reads either as unusually useful or as unfocused, and the difference is entirely down to whether they can see the reasoning behind the range. A body of public work resolves the ambiguity. Nothing else does.

04 · Research

Desk research and pattern observation, not a study.

I read how the people who successfully built audiences from building actually did it, and looked at what the format has in common: Pieter Levels shipping in public with revenue numbers attached, the indie hacker convention of open metrics, the newer wave of AI builders documenting process rather than outcomes. The consistent pattern is that specificity beats polish. A post that says "here is the exact query that was costing me forty dollars a day and here is what I changed" travels. A post that says "lessons from building my startup" does not.

I also looked at what fails, which is more instructive. Build-in-public accounts fail in two ways. They go quiet, or they become content about building rather than building. The second is worse, because it is self-sustaining: writing about the process is easier than the process, so the writing gradually replaces it.

What I did not do. No audience research. No interviews with founders about what they read before hiring. No keyword or search-volume analysis, which for a content-led acquisition strategy is a genuine gap and not a small one. I built the platform on an intuition about what would earn trust rather than on evidence about what my buyers actually consume.

05 · Insights

The commitment is the content. A blog is a series of posts and nobody follows a series of posts. "Thirty products" is a narrative with a beginning, a middle and a knowable end, and narrative is what makes a stranger return. The counter is not decoration, it is the plot.

Failures are the differentiated asset. Everyone publishes launches. Almost nobody publishes the version where the architecture was wrong and had to be torn out. That asymmetry means the failure post is both more valuable to a reader and less contested in the market.

Process content ages better than product content. A post about a specific product becomes obsolete when the product changes. A post about how you decided between two architectures stays useful for years, because the decision recurs.

Publishing to two audiences at once creates a positioning problem. BuildWithDev speaks to builders. My client work needs to speak to founders. Those readers want different things: builders want technical specifics, founders want judgement about outcomes. Writing for both from one surface produces content that half-serves each. I did not solve this and it is why the two properties still sit awkwardly together.

Public progress indicators cut both ways, and that is their entire value. A counter that can only go up is marketing. A counter that can sit at zero for months is evidence. I chose the second kind, apparently without fully anticipating the second case.

06 · Product thinking

BuildWithDev is a product with users, an acquisition model and a retention problem, so it deserves to be reasoned about as one.

Who it is for. Two segments, and I should have picked one. Segment A is other builders, who arrive from technical writing, are easy to reach and cannot hire me. Segment B is startup founders, who are hard to reach, arrive from judgement-led writing, and are the entire commercial point. A publication optimised for A produces traffic. A publication optimised for B produces clients. I built something in between.

What the core loop is. Build a product, write the decisions, publish, repeat. The loop's health depends on one variable: whether building and writing are the same activity or two activities. If writing is a separate task that happens after shipping, it will lose to whatever is urgent. If the writing is produced as the building happens, it survives. I treated it as a separate task.

What the MVP scope should have been. In hindsight: five products, deeply documented, no counter. Five is achievable while doing paid work. Thirty is a number that sounds like ambition and functions as a liability. The counter's honesty is a virtue but the number it counts toward was chosen for its rhetorical weight rather than its feasibility.

What "done" means for this product. Not thirty products. A body of work substantial enough that a founder who reads two pieces decides to email me. That is the actual success condition, and it is reachable at a much smaller n than thirty.

07 · Strategy

Separate the properties by job. devchopra.life is the professional surface: who I am, what I have worked on, how to hire me. buildwithdev.xyz is the laboratory: what I am building right now, and what I am learning while it breaks. Different domains, different tone, different visitor intent. I still believe this split is right, and it is the strongest structural decision in the project.

Commit publicly and specifically. A number, a phase, a percentage. Vague intentions produce nothing.

Write process, not announcements. The TapQR article is the model of what the platform is for: it describes the decisions in order, including the ones that were wrong, and it labels the unbuilt parts as unbuilt. That is the format the site exists to produce.

Own the archive. A custom-built site rather than a hosted newsletter platform, because the writing is a long-term asset and it should not live somewhere that can change its terms or its layout.

What the strategy is missing. Distribution. There is no newsletter capture, no syndication, no discernible search strategy. A content-led acquisition plan without a distribution mechanic is a diary, and I have written elsewhere about how easily this failure hides behind productivity.

08 · Information architecture

/                    manifesto, progress counter, phase indicator, latest writing
/blog                the archive
/blog/[slug]         individual pieces
/projects            the thirty  ← currently empty
/about               who is doing this and why

Five routes and the structure is correct for the concept. The problem is not architectural, it is that /projects is the load-bearing page and it has nothing in it. A visitor who reads the homepage claim and clicks through to see the products finds an empty page. That is the worst possible sequence: the promise is made, the visitor acts on it, and the payoff is absent.

The counter and the empty page are the same fact stated twice, once numerically and once experientially. The numerical version is honest. The experiential version is just a broken promise, and there is a straightforward fix that does not require shipping thirty products: /projects should show what has actually been built, including the seventeen repositories, with honest labels. There is real work to point at. It is currently pointing at nothing.

09 · UX and design

The visual language is deliberate and it does its job.

Terminal aesthetics as positioning. Monospace type, the phase indicator, a zero-padded counter. This is a signal, not a style: it says the person behind this site builds things. For an audience of builders and technical founders it establishes competence before a word is read. The tradeoff is that it narrows the audience, which is a reasonable choice for a laboratory and a poor one for a client-facing surface. This is another argument for the two-domain split.

Progress made physical. 00 / 30, PHASE 01: DISCOVERY, 0% COMPLETE. Three redundant encodings of the same state. Redundancy here is right: it makes the state unmissable, which is the point of a public commitment.

Hierarchy. The commitment dominates the homepage, writing sits below it, navigation is minimal. Correct ordering for a first-time visitor, whose question is "what is this" rather than "what is new".

Interaction cost. Effectively zero. Read, click, read. There is nothing to configure, which is right for a publication.

Where the design fails: reading. The pieces are long, and long-form monospace at tight measure is tiring. The strength of the homepage becomes a weakness on the article page. The fix is a separate reading typeface for body copy while the monospace stays for the interface, which is a standard editorial solution and would cost very little.

Where the design also fails: the empty state. /projects empty is not a designed empty state, it is an absence. An empty state should tell you what will be here and what to do meanwhile. This one just stops.

10 · Technology

Modern React stack. Server-rendered, statically generated content, deployed on standard hosting. The technical requirements of a publication are modest and were met.

The relevant technical observation is about the counter, not the stack. 00 / 30 is either derived from a data source or it is hardcoded. If it is derived, the mechanism works and the number is a fact. If it is hardcoded, then the site's central honesty mechanism is a string literal, and the whole instrument is decorative. I have not verified which, and stating that is more useful than assuming the flattering answer.

The lesson generalises past this project: a public progress indicator is only meaningful if it is wired to something that can move without being edited. Otherwise it is a claim wearing the costume of a measurement.

11 · Marketing and GTM

Positioning. "Building 30 products in public." Concrete, memorable, verifiable. A good line.

ICP, stated honestly: unresolved. See section 06. The site speaks to builders; the business needs founders.

Distribution: largely absent. No newsletter, no email capture, no syndication to the platforms where this audience actually reads, no evident search strategy. Publishing without distribution is the most common failure in content-led acquisition and it is the one I made. The work of writing is visible and satisfying. The work of getting it read is neither.

Content produced to date: two pieces I can verify. A dated first-person build narrative about TapQR from June 2026, which is genuinely good and does exactly what the platform is for. An undated essay on the history of AI, which is well-argued and cites poorly: bare URLs, no authors, no dates, and two of its nine sources are Wikipedia. That sourcing standard is the reason the research notes in this archive cite properly.

Conversion path. There isn't one. A reader who finishes the TapQR article and wants to hire the author has no obvious next step. A single line at the end of each piece would close that gap.

Claims removed from this section. Bounce rate cut 60%, ten-plus inbound leads in launch month, four SaaS tools consolidated. No analytics, no lead record, no consolidation artifact. All excluded.

12 · Execution

Built and shipped:

• A live site at buildwithdev.xyz on a custom build
• The public commitment mechanism: counter, phase indicator, progress percentage
• A blog with at least two published pieces, one of them dated and substantial
• Five routes with a coherent structure
• A consistent visual identity distinct from the professional portfolio

Not built:

• Any of the thirty products, on the site's own account
• /projects content
• Newsletter or email capture
• Distribution beyond the site itself
• A conversion path to paid work

13 · Results

Reported by the product itself: 00 / 30 products built, PHASE 01: DISCOVERY, 0% COMPLETE.

That is the only outcome metric this project has, it is public, and it is unflattering. It is also, unusually, exactly the kind of number a founder can trust, because no one publishes that on purpose to look good.

What exists: a live site, a working commitment mechanism, and two published pieces, one of which is a strong piece of writing that has directly informed how everything in this archive is written.

What does not exist: traffic data, subscriber counts, lead attribution, or any of the four outcome claims previously published about this project.

The honest read. BuildWithDev succeeded as a positioning artifact and stalled as a production system. The idea is sound, the design communicates, the one substantial article proves the format works. The engine is not running. Both halves of that sentence are true and the second half is the one that predicts what happens next.

14 · What went wrong

I chose a number for how it sounded. Thirty products is a good headline and a bad plan. It sounded like the level of ambition that gets attention, and I did not sanity-check it against how many hours a week I actually have while doing paid work. Five deeply documented products would have been more credible, more achievable and more useful to a reader. The counter is stuck at zero partly because the target was set by rhetoric.

I treated writing as a second job instead of part of shipping. This is the structural cause of the stall. Building is urgent and visible; writing about building is neither, so it lost every time the two competed. The fix is not discipline, it is sequencing: the decision log has to be produced while the decision is being made, not reconstructed afterwards.

I built a publication with no distribution. Deciding what the site is for and what it looks like is the interesting part. Getting it read is the part that determines whether any of it matters. I did the interesting part.

I made a public promise and then let the payoff page stay empty. /projects empty is worse than /projects absent. And there was no need for it to be empty: seventeen repositories exist and could have been listed honestly, with accurate labels, from the first week.

I published a case study about this project that contradicted the project. My portfolio claimed BuildWithDev had cut bounce rates and generated leads while buildwithdev.xyz was telling every visitor it was zero percent complete. Anyone who read both would conclude the case studies were unreliable, and they would be right. This is the worst failure in this document and it is not a product failure, it is an honesty failure.

I cited badly in my own writing. Bare URLs and Wikipedia in a piece making historical claims. The argument in that essay is good enough to deserve better sourcing, and weak citation invites a reader to doubt the parts that are actually well-founded.

I did not resolve who this is for. The two-audience problem was visible from the start. I left it open because both audiences felt worth having, and the result is a site that is not optimised for either.

15 · What I learned

A public commitment is a real mechanism and it has a real cost. It works. It also produces a permanent record of the gap between intention and delivery. I still think building the instrument was right, and I would keep the counter visible even now, because a person who publishes their own zero is more trustworthy than a person who publishes a curated ten.

Writing has to be a byproduct of building or it will not happen. Any content system that depends on a separate act of will after the work is done will fail during the first busy month. This is the single most transferable lesson from this project.

Distribution is the product. Not an afterthought, not a growth phase. If you cannot say how a reader arrives, you have built a folder.

Consistency is the only unfakeable signal. Anyone can write one good piece. Publishing for a year cannot be shortcut, which is why it works, and why the entry cost is higher than it looks from the outside.

Never let a portfolio claim outrun the artifact it describes. If the product is telling visitors one thing and the case study is telling them another, the case study loses, and it takes the rest of the portfolio with it.

16 · What I would do differently

Reset the target to five and say why in public. "I said thirty. Thirty was the wrong number. Here is what I am actually doing and why." Publishing the correction is better content than the original commitment was, and it demonstrates the exact quality a founder is hiring for.

Fill /projects this week with what exists. Seventeen repositories, honestly labelled: what it is, whether it is deployed, whether it is abandoned. An honest inventory of seventeen unfinished things is more impressive than an empty page under a claim of thirty.

Make the decision log part of the build. A running notes file per project, written during the work. The published piece is an edit of that file, not a fresh act of composition. This changes writing from an act of will into an act of editing, and editing is much easier to sustain.

Pick founders and accept the traffic cost. Fewer readers, better readers. The technical audience is easier to reach and cannot buy.

Ship a distribution mechanic before the next piece. Email capture on every article, one syndication destination, a single line at the end of each piece explaining what I do and how to reach me. Small work, and it is the difference between an archive and a channel.

Fix the citations retroactively. Author, title, publisher, date, URL. It takes an hour per piece and it changes how the argument is received.

Add a reading typeface for body copy. Keep monospace for the interface. Long-form deserves to be readable.

17 · Current status

Live. Publishing intermittently. The counter is accurate and stays.

Item	Status
Site	Live at buildwithdev.xyz
Products built, per the site's own counter	00 / 30
Phase indicator	PHASE 01: DISCOVERY, 0% complete
/projects	Empty
Published writing verified	2 pieces, one dated June 2026
Newsletter, syndication, conversion path	None
Outcome metrics	None. Four previously published claims removed.
Previous case study on devchopra.life	Contradicted the product; superseded by this document

---

Related reading in this archive

• What building in public actually costs: the mechanism and its failure modes, argued in general
• What seventeen products in five months actually taught me: the volume this platform was built to make sense of
• The case for building many small products: why the portfolio has this shape
• TapQR: the project the platform's best article is about
• The Build Archive: the seventeen repositories that should be on /projects

Sources

1. buildwithdev.xyz homepage: manifesto, progress counter (00 / 30), phase indicator (PHASE 01: DISCOVERY), 0% COMPLETE. Retrieved August 2026. https://buildwithdev.xyz
2. buildwithdev.xyz /projects: empty as retrieved. https://buildwithdev.xyz/projects
3. Dev Chopra, "Building TapQR: My Journey From Freelancing to Creating a Smart Payment Ecosystem", buildwithdev.xyz, 6 June 2026. https://buildwithdev.xyz/research/building-tapqr-my-journey-from-freelancing-to-creating-a-smart-payment-ecosystem
4. Dev Chopra, "AI Was Never Sudden", buildwithdev.xyz, undated. https://buildwithdev.xyz/research/ai-was-never-sudden-the-hidden-timeline-power-plays-and-truths-we-ignored
5. GitHub, TheDevChopra: 19 repositories, 17 authored February to June 2026. https://github.com/TheDevChopra
6. devchopra.life /projects/buildwithdev: the superseded case study containing the four excluded outcome claims. https://devchopra.life/projects/buildwithdev