DEV Community: The Startup Café

When a Company Becomes Too Dependent on One Person

TheBitForge — Thu, 12 Nov 2026 17:01:07 +0000

For years, Jensen Huang has been more than Nvidia's CEO. He has become one of the most recognisable faces of the AI industry.

The black leather jacket, confident stage appearances, ambitious announcements, and Nvidia's extraordinary growth helped turn him into something unusual in modern business: a CEO who almost represents the company himself.

Then came the controversy.

Huang publicly admitted to being unfaithful to his wife and apologised to his family and colleagues. Nvidia's board also announced an independent investigation following reports about a possible foreign intelligence operation. Those allegations are serious, but they should not be treated as proven facts. On November 12, the Associated Press reported that Huang had resigned, with CFO Colette Kress named interim CEO.

Suddenly, the conversation was no longer just about Nvidia's technology or its position in the AI market. It was about leadership, personal conduct, corporate responsibility, and how much power one individual should hold.

But something else happened online.

The internet did what it often does when a powerful person faces a public crisis: it turned the situation into memes, jokes, edited pictures, and endless commentary about the famous leather jacket.

Some people mocked him. Others defended his achievements. Some treated the situation as proof that the entire AI industry had built too much around one person.

And perhaps that last point deserves more attention than the jokes.

The problem with making a CEO bigger than the company

There is nothing wrong with celebrating a founder.

People who build successful companies often deserve recognition. Huang helped build Nvidia over decades, and its role in the modern AI industry is difficult to ignore.

But celebrating a leader and making a company dependent on that leader are two very different things.

When a CEO becomes the company's public identity, every personal controversy can become a business concern. Investors start asking questions. Employees wonder what happens next. Customers and partners may reconsider their confidence.

That raises an uncomfortable question:

If a company worth trillions cannot comfortably imagine its future without one executive, is that a sign of great leadership or a failure of leadership planning?

A strong company should benefit from its founder's vision without becoming trapped by the founder's presence.

The internet's reaction says something about us, too

The public reaction has been interesting, and sometimes uncomfortable.

For years, Huang was presented as a symbol of ambition, technical leadership, and the AI revolution. His jacket became part of his identity. His stage appearances became familiar internet moments.

Now, the same recognisable image has become material for jokes.

There is a wider lesson here about how quickly public admiration can turn into public ridicule.

People often confuse business success with personal perfection. A CEO can build an extraordinary company and still make serious personal mistakes. Both things can be true.

But online conversations rarely leave much room for that complexity. People often choose a side: defend everything or condemn everything.

Neither approach is particularly useful.

The better question is not whether someone deserves memes. It is whether the criticism is focused on the right issues.

A person's private life, workplace responsibilities, possible conflicts of interest, and national-security concerns are not automatically the same issue. They should be examined separately, based on evidence.

Where was the board?

This situation also puts Nvidia's corporate governance under the spotlight.

A board is not supposed to exist only for financial reports, executive appointments, and shareholder meetings. It has a responsibility to oversee leadership, manage risks, and protect the long-term interests of the company.

If a CEO becomes so central that questioning his position feels almost impossible, the board has a difficult problem.

And if the company has no convincing succession plan, that problem becomes even bigger.

Nvidia's technology, engineers, customers, suppliers, and business relationships do not disappear with one CEO. The company is much larger than any single individual.

So why does leadership uncertainty create so much anxiety?

Perhaps because the market has become used to treating Huang as part of Nvidia's competitive advantage. But a company's long-term value should not depend entirely on one person's reputation or ability to remain in office.

The real lesson is bigger than Jensen Huang

This is not an argument that founders should stop being celebrated. It is an argument that successful companies need stronger systems than personal loyalty.

A founder can create the vision. A leadership team must be able to carry it forward. A board must be willing to ask difficult questions. And the organisation must be prepared for a future in which its most recognisable person is no longer in charge.

Nvidia's next chapter will test more than its technology or market position. It will test how much of the company was built into its systems, and how much was built around one individual.

The jacket was always just a jacket.

The more important question is whether the company underneath it was prepared to stand on its own.

Questions worth discussing

I'd genuinely like to hear how developers, founders, and people working in tech see this situation:

When does founder worship become a business risk? Is there a point where admiration starts preventing people from questioning leadership?
Should a company's reputation be tied so closely to its CEO? Or should a healthy organisation be able to survive almost any leadership change?
If a founder creates enormous value but later damages public trust, how should a board balance both realities?
Do investors sometimes reward charismatic leadership more than strong corporate systems?
Are memes and public mockery a form of accountability, or do they distract us from the more important questions?
Would you trust a company more if its founder could leave tomorrow and the business would continue without major disruption?
What should matter more when evaluating a CEO: past achievements, personal conduct, or the company's ability to operate independently of them?

I don't think there is one simple answer. But perhaps this situation gives the tech industry a reason to reconsider how it celebrates founders, builds leadership teams, and prepares for change.

A great founder can build a company. A great company should be able to outlive its founder.

Your Startup Doesn't Need Everyone. It Needs the Right Niche

Hanzla Baig — Wed, 11 Nov 2026 19:31:50 +0000

In early 2011, Jason Goldberg shut down Fabulis, a social network for gay men that he had launched about fourteen months earlier. By one report at the time it had more than 140,000 registered users. Goldberg told the same outlet that he did not believe a non-sexual social network for gay men could pass a million members, and that without ten million it was hard to build a significant business in that space.

That is an awkward place to start an article in favor of niches, because Fabulis was a niche. It was narrow in exactly the way startup advice tells you to be. PayPal, by contrast, began with a group of eBay power sellers that Peter Thiel has put at 20,000 to 25,000 people, and Facebook began on a single campus. Same advice, opposite outcomes.

So the useful question is narrower than "should you niche down?" It is what a niche has to contain before it deserves the name. My argument, which I will test against the evidence as we go, is that a niche is a shared situation rather than a small market. The groups that worked were stuck with the same problem, could be found, and talked to each other. The one that failed had a clear identity but no urgent problem in common.

What "everyone" costs you

Targeting everyone rarely fails because the market is too big. It fails because nothing ever gets ruled out. When your customer is a crowd, every choice about message, channel, first feature and price lacks a tiebreaker.

Bill Aulet's Disciplined Entrepreneurship gives a workable test. Customers in a real segment buy the same product, buy it in the same way, and influence one another. His site adds a practical check: if your sales approach has to change from one customer to the next, you have not narrowed enough.

Paul Graham gave the Airbnb founders related advice: focus on 100 people who love you instead of a million who mildly like you. Brian Chesky has called it the best advice he ever received. That is advice about depth more than size, but depth is easier to reach when the group is small enough to meet.

Article #5 argued that a price selects your audience. A niche does something similar earlier. It decides whose words you borrow, where you show up, and which complaints you hear first.

What PayPal and Facebook actually had

Look at how Thiel described PayPal's first market in a 2014 talk at Harvard Business School. The power sellers were people who needed something much better than checks, and he says PayPal reached 30 to 35 percent of them within three months. That is a recollection from an investor with every reason to tell it well, so treat the percentage with caution. Notice the shape of it, though: a concentrated group with a daily, costly annoyance. Inc. reports Thiel's account of an earlier plan, payments between PalmPilots, as too large and too spread out for the company to dominate.

Facebook's early record is easier to check because a student newspaper wrote it down. After about three weeks of Harvard-only access, the Crimson reported that 5,055 Harvard students had joined, and that the site had just opened to Columbia and Stanford, with Yale next. Early profile counts at Columbia and Stanford were 37 and 26. The new campuses started tiny. What carried over was that students see each other every day, so word of mouth came built into the setting, and the same product worked at each school. Those line up with Aulet's three conditions, though that comparison is mine, not the Crimson's.

Both are survivor stories, and PayPal's is told partly by the people who profited. They show what a working niche can look like. They do not show that narrowness caused the result.

The niche that wasn't enough

Back to Fabulis. Goldberg gave several explanations when it closed. He said progress on gay rights had reduced demand for a gay version of existing services, and that the one real success in the space, Grindr, worked because it met a pressing need his company chose not to serve. He also said he could not make the numbers work. Fab then reinvented itself as a design flash-sale site.

My reading, which Goldberg's account partly supports but does not prove, is that Fabulis defined its audience by who they were, while PayPal defined its audience by what they were stuck with. An identity is a good way to find people. It is not a reason for them to leave the networks they already use. The power sellers had a daily annoyance with a price tag attached. The Fabulis audience had alternatives and no urgent job.

It also shows the ceiling problem. A hundred and forty thousand registered users sounds substantial, and Goldberg still judged it far short of what the business needed. Whether a niche is too small depends on the business you are trying to build.

Four checks before you commit

These are my synthesis of Aulet's criteria and the Fabulis account. I have not seen evidence that they predict success, so read them as questions and not as a score.

1. Can you describe the group by a situation instead of a label? "Small business owners" is a label. "Sellers who reconcile payouts from three marketplaces every Friday" is a situation. A situation tells you what to say, where to say it, and what they already do about the problem.

2. Can you list a hundred of them by name, and do they know each other? Reachability and word of mouth are why a small group can be won quickly. If you cannot name them, you will spend your time searching instead of selling.

3. Do they already spend time or money managing the problem? A workaround, a spreadsheet, a part-time hire, a monthly fee for something worse. This is the difference between identity and urgency, and it is the check Fabulis seems to have failed.

4. Does the ceiling fit the business you want? Work backwards. Say 3,000 people in your niche are reachable, 10 percent buy, and each pays $29 a month. That is 300 customers and $104,400 a year (invented numbers, for illustration). A solo founder might be happy with that. A team that needs ten times as much has found a beachhead, not a business, and should ask early where the next ring of customers is. Goldberg's ten million came from the company he was trying to build, not from a universal threshold.

Finding the group, and testing it before you build

Most founders choose a niche at a whiteboard. A better starting point is evidence you already have. Article #3 laid out stages from reached to committed. Look at the people who got furthest and sort them by situation, not by demographics. If your three best conversations share a situation you did not plan for, that is your candidate.

Then try a test of my own, which I have not seen validated anywhere. Write one sentence of offer aimed at that situation. Show it to five people inside the situation and a few just outside it. If only the insiders lean in, your edge is real. If everyone reacts the same way, you have described a label, and the niche is not doing any work.

Finally, ask for something with a cost. Article #2 ranked evidence from compliments to payments, and Article #5 covered paid pilots. Five people in one situation agreeing to a paid pilot tests the niche and the demand at once. That is cheaper than building for months and learning that your niche was a label.

When to stay narrow and when to widen

Facebook widened within weeks, while Harvard was still signing up, but each step added a group that already behaved like the first. Thiel describes the pattern as moving gradually into related, slightly broader markets. The sequence seems to matter more than the speed.

I would widen when people outside the niche arrive unprompted and use the product the same way, when customers inside it refer others without being asked, and when the next group would buy the same product the same way, which is Aulet's test applied to the neighbor. I would stay when customers still need you to explain what the product is for, or when serving a second group would make you say two different things on one page.

The evidence for niche-first is thinner than the advice suggests. A 1994 study of 123 new ventures in the Strategic Management Journal found the highest sales growth among ventures pursuing broad strategies in high-growth industries. An older study of mature manufacturing firms found that broad-scope firms did better on average, though some narrow strategies worked. That is a different era and industry, so it is no verdict on software startups. And a 2025 study of 988 AI ventures found that academic founders built technology applicable to more industries, while its author noted that serving many niches takes resources. That measures how widely a technology applies, not who you sell to first, and the difference is worth keeping. Your technology can be general while your first customer is specific.

I could not find a controlled comparison of niche-first and broad-first startups. What exists is a handful of survivor stories, a few failures, and reasoning about limited resources.

So

A niche is a bet that a small, specific group will teach you faster and pay you sooner than a crowd would. It is not a guarantee, and it is not a permanent identity. Fabulis shows that narrow is not enough. The group needs a problem it is already trying to solve, people who can be reached, and enough of them to carry the business you want.

Pick the smallest group that is stuck with your problem, then let them tell you when to stop being a niche.

Your turn: If you narrowed your audience, or deliberately refused to, what was the first real sign that you had picked the right group, or the wrong one?

PB&J: The Story of the Three People Behind DEV

Hanzla Baig — Wed, 11 Nov 2026 08:45:29 +0000

Let me tell you a story about a sandwich 🥪

Open the About page on DEV and you will find this sentence:

DEV About page

"DEV is led by Forem's co-founders Ben Halpern, Jess Lee, and Peter Frank ("PB&J")."

Ben ( @ben ) is the B. Peter ( @peter ) is the P. Jess ( @jess ) is the J. A peanut butter and jelly sandwich, made out of three people.

I read that line and had one of those "wait, how did this actually happen?" moments. I knew DEV started as a Twitter account. I knew it got big. I knew it was open source. But I had no idea how three people ended up running it together, who did what, or how the whole thing started in the first place.

So I went and read everything I could find. Podcast transcripts. AMAs. Old progress reports. Funding announcements. A college newspaper article from 2009 (yes, really). And what I found was a better story than I expected, with a missing date, a mystery typo, a Twitter account with 108,000 followers, and a plot twist in February 2026.

This post is that story, told in order, so you do not have to piece it together like I did.

The rules I am following

Before we start, a few promises, because this kind of article is easy to get wrong.

I did not talk to any of them. Everything here comes from things the founders and companies made public. When someone told a story about themselves, I say "Ben said" or "Jess wrote." I have not checked their personal stories against anyone else, and I say so when it matters.
When I am guessing, I will say "I am guessing." A few dates have to be worked out from other numbers. Those are marked as my math, not as official facts.
When nobody has said something, I will not invent it. There are real gaps, like deal prices and exact titles. I will point at the gap and move on.

Who is who (so you do not get lost)

Here is the cast, so you can come back to this if you get confused:

Ben Halpern started the Twitter account that became DEV. He is the funny one, the one who writes most of the announcements, and the one most people think of first.

Peter Kim Frank (sometimes just "Peter Frank") is Ben's earlier business partner. He is the one on the business side, and he has been running online projects since high school.

Jess Lee met Ben a bit later, joined the project in 2016, and runs operations. Jess uses they/them pronouns, which Jess shared in a post in March 2026, so that is what I use here. When I quote older interviews that say "she," I leave them as they were.

And two words people mix up constantly:

DEV is the community, the website at dev.to.

Forem is the open-source software DEV runs on (and the company that grew around it). DEV is the first Forem. We will get to why that matters.

Okay. Ready? Let's go back to the beginning. Or at least, as far back as the record goes.

Chapter 1: A guy with a second Twitter account 🐦
Chapter 2: The business partner who started young
Chapter 3: The person who did not know what a startup was
Chapter 4: From a joke account to an actual website
Chapter 5: The decision, and the date that cannot be right 🕵️
Chapter 6: The year everything grew 17 times
Chapter 7: The day the code went public 🔓
Chapter 8: Money arrives, and the office disappears
Chapter 9: DEV gets a big sibling called Forem 🌍
Interlude: how DEV actually felt to run
Who does what, in plain English
Chapter 10: February 18, 2026 🚀
Where the three are now
Epilogue: the ten-year promise

Chapter 1: A guy with a second Twitter account 🐦

Our story starts with Ben, and Ben starts with a website he built at about 13.

In a Learn to Code With Me interview, Ben said he grew up fascinated with HTML and built websites as a hobby. His first real application, he told Developer Tea, was a fantasy sports site. He has also said he has been an entrepreneur in some form "since I was 12." (That one is from the Changelog interview.)

Then the plot gets less straight. He took some computer science in college, dropped out of that track, and graduated with a marketing degree. He interned somewhere and did not enjoy it. So he thought about comedy writing, spent a summer in New York living with his brother and trying to meet people in TV, and found there was not much of a path.

Meanwhile he had stopped believing programming was for him. A professor had discouraged him, and he has admitted to imposter syndrome. Then around 2012, a friend in a college cafeteria pointed him at Ruby on Rails while Ben was thinking about an app idea. That was it. He got back into programming "for real," he said, and he loved it.

He also overdid it. He has talked about 17 and 18 hour coding days, and about getting shingles twice from overwork. So when you read the rest of this story and think "these people worked a lot," keep that in mind. At least one of them has told you how much.

Where does the Twitter account come in?

Here is the part I like.

Ben's own profile says he is "a Canadian software developer who thinks he's funny." In his 2017 interview on Developer Tea, he explained that he made a second Twitter account, The Practical Dev, so he could post about programming without annoying the friends who followed his personal one.

Notice what that is. It is not a business plan. It is a guy trying not to spam his friends.

At first the account shared programming articles. Then he added his own opinions and jokes, and that is when it "really started taking off." He also said his marketing degree helped him understand how to grow it, so the degree he thought he wasted came in handy.

He told Learn to Code With Me that jokes are only about 5 percent of what the account posts. Which is funny, given what people remember it for.

The Changelog hosts asked him about the O'Reilly-style parody book covers. Ben called them "the first major chapter" of the story. If you have ever seen a fake programming book cover with an animal and an absurd title, that style of joke is part of what made the account spread.

When did this start?

Ben does not give a birthday for the account in the interviews I read. But the founders' first progress report, from November 2017, says it had been 1,174 days since the account started. If you count back from November 1, 2017, that lands around August 15, 2014.

That is my math, not an official date. I will do the same trick with other dates in a minute.

By April 2017, when Ben spoke to Developer Tea, the account had about 108,000 followers. In an earlier interview he said "just under 100,000." Each tweet, he said, sent a few thousand people to dev.to.

So hold that picture: a joke account, three years old, with a big and loyal audience, and a guy who has just realized the audience could be a community.

Right. Now meet the second person.

↑ Back to contents

Chapter 2: The business partner who started young

If you want to understand Peter, start with a college newspaper from 2009.

The Wesleyan Argus ran a story in February 2009 about a freshman in the class of 2012, Peter Frank, who was running a website called CollegeACB from his dorm room. ACB stands for anonymous confession board. It was a network of roughly 500 boards for different schools, and the Wesleyan one was the busiest.

Here is what the article says, and I am only repeating it:

CollegeACB had been started about a year earlier by two other students. Peter took it over about three months before the article, after they said they wanted a successor.
He had already been running a small company, Sumdae LLC, since his sophomore year of high school in 2005. It was built on registering domain names.
After a rival site called Juicy Campus shut down, Peter struck a deal with its founder. For two months, Juicy Campus's traffic was sent to CollegeACB. The article says it was a five-figure deal that Peter paid for himself. Traffic jumped from around 60,000 hits a day to about half a million, almost overnight.
He said he was up until 4 a.m. that night adding schools.
He went from spending a couple of hours a week on the site to five or six hours a day.

The article also says he turned down buyout offers, and it quotes him:

Peter Kim Frank

"If I create a service that's needed, wanting the money takes care of itself."

That sounds a lot like a young entrepreneur's philosophy, and I think it is a useful clue to how he later thought about building things.

To be fair to everyone, the same article mentions concerns about the tone of those sites. The previous owner said he hoped Peter would change the negative tone that had come with the Juicy Campus traffic, and Wesleyan's president said he found the site disturbing. Peter told the paper he would moderate it: he said he read the flagged posts and removed spam, and the site automatically deleted posts with enough complaints. I am including this because it is part of the record, not to judge it. It was 2009 and he was a freshman.

Texts.com and then Ben

Peter's personal site lists CollegeACB, then Texts.com and Argo among his projects. It says he was an English major at Wesleyan and is based in New York City.

The 2009 article actually mentions texts.com too, as one of the domain names he held, at that point offering international text messages. By the time Ben joined, Texts.com was becoming a student textbook exchange.

And how did they meet? Peter has the answer, in a fun-fact reply during his DEV AMA in December 2017: they met on Reddit, in the r/nycjobs forum. Ben said in the same thread that he had worked with Peter since moving to the United States, to New York, almost five years earlier. So that would put the start of their partnership around the beginning of 2013.

Ben was the technical person on Texts.com. In his Learn to Code With Me interview, he said he was hired to help start it, and that it later pivoted and became Argo. On the Changelog, he said he later folded dev.to into that same company, which became Dev Community Inc. Those are two different interviews, and I could not reconcile every detail of the corporate history, so treat that part as Ben's loose summary.

The "least technical" co-founder

Peter is open about not being a developer. In that same AMA, he called himself the team's "least technical" member. He works on strategy and operations.

He also told a funny and honest story about learning to work with engineers. Early on, he said, he had a "JUST" mindset, the kind where you ask why can't you "just" add a feature. He said he underestimated how demoralizing it is for developers to work with non-technical stakeholders, especially when specs keep changing. The team now quotes the XKCD "Tasks" comic internally to explain the gap.

His fix is something I find kind of admirable. He writes detailed issues. He reads pull requests to see "what went where." And he told other non-technical people that they are "totally capable of understanding what's going on" with effort and good teammates.

He also shared some personal facts: he says he was one of Tinder's very first users, he sold an online community in 2011, he was once on the Montel show after spotting a hiker in trouble from a helicopter tour in Hawaii at age 15, and he is half-Korean and half-Ashkenazi. All of that is his own telling in the thread, and I have not checked any of it.

So by the end of 2016, we have:

Ben, who has a huge Twitter audience and a day job at the startup he runs with Peter.
Peter, the business and legal partner on that startup, who has been running online projects since high school.

And the missing piece walks in next.

↑ Back to contents

Chapter 3: The person who did not know what a startup was

Jess Lee's path is the most unexpected one, so let's slow down for it.

In a 2021 podcast interview, Jess said they studied music in college and then worked in music publishing, a job that took away much of their passion for music. Then came a temp job at a startup, doing business analysis. Jess noticed something: the developers there were treated like first-class citizens.

That is what sent them to a coding bootcamp. Jess has not named the bootcamp in anything I found.

After the bootcamp, there was a catch. The only place that would hire Jess, a nonprofit that helps young people take social action, did not have developer roles, so Jess became a product manager instead. Jess said that job gave them enough energy to work on DEV at night and on weekends.

And here is a line I love, from the same interview:

Jess Lee

"I didn't even know what a startup was six years ago."

(Six years before 2021, so roughly 2015.)

Loneliness is the origin story

Jess says the thing after the bootcamp was isolation. They did not know how to keep up with the field or where to meet other developers. They mention that bootcamp instructors told students to set up throwaway Stack Overflow accounts in case they got shut down for asking "bad" questions.

Ben, in his own telling, met Jess through a friend after Jess finished the bootcamp, and started mentoring them. Jess says the two of them had the same feeling: there was no place for new developers that felt welcoming. That shared frustration, they say, was what turned into DEV.

Different people tell it slightly differently, but I find the overlap clear: two people, both new-ish to the field in different ways, both tired of the unfriendly parts of the developer internet.

Ben describes the pairing with a great line. He calls himself "extremely abstract, chaotic and disorganized," and Jess the opposite, the person who brought order and discipline. Ben told another interviewer that Jess handles the taxes, expenses and organizational tasks he finds hard. Ben also noted that Jess writes code, so the business side is not all Jess does.

By the day counts in that first progress report, Jess officially joined the project about 485 days before November 1, 2017. That is around July 4, 2016, though again that is my arithmetic.

Jess gave their first public talk in 2017 too, at Write/Speak/Code, a women's conference in Portland, Oregon, about dev.to and developer identity. They called that their biggest achievement of the year.

One small warning: there is a completely unrelated Jess Lee, a businesswoman linked to Polyvore and Sequoia. Some web pages mix them up. Same name, different person.

So now we have three

At this point, in mid-2016, the picture is:

Person	What they brought	Where they were
Ben	The audience, the code, the humor	Running a startup with Peter, building dev.to on the side
Jess	Operations, community thinking, product sense	Working a day job and building dev.to on the side (Jess's 2021 interview mentions a nonprofit, while the 2017 report says a larger company)
Peter	Business and legal skills, and a long history as an entrepreneur	Co-running that startup with Ben

Only two of them are actually working on dev.to at this point. The third is about to be pulled in.

But first, we need to talk about how dev.to even came to exist.

↑ Back to contents

Chapter 4: From a joke account to an actual website

So how does a Twitter account turn into a website?

Slowly, and with a few accidents.

Ben told Developer Tea that he first registered practicaldev.com, and later switched to the shorter dev.to. According to the November 2017 progress report, the dev.to domain was bought about 550 days before the post, which lands around April 30, 2016. (My arithmetic again.)

Ben also said that around this time he decided to take the project seriously and build a real programming platform, while keeping most of his creativity pointed at the Twitter account. That sounds right to me. The account was the thing people loved, and the site had to earn its place next to it.

His goal, as he put it on the Changelog, was to fix the things he had been making fun of: career chaos, inconsistent learning resources, and a lack of tools and places for developers to gather. In other words, the jokes were the symptoms and the site was the treatment.

The first article was an interview with DHH

This is my favorite detail in the whole story.

Ben told the Changelog that the first thing published on dev.to was an interview with DHH, the creator of Rails, timed around the Rails 5 release. How did a guy with a joke account land an interview with one of the most famous names in the Ruby world? Ben said he emailed him, asked nicely, and made it easy to say yes. That is the whole trick.

He lined up more interviews with other open-source people after that. The original idea was a high-touch, interview-driven site. Then, he said, audience feedback pushed it in a different direction: a place where anyone could write about anything software-related, with an enforced code of conduct.

If you have used DEV, you know which version won.

The login button nobody could find

Here is a detail that made me laugh. Ben said the login feature was hidden in the footer at first. Hidden. And people found it anyway and logged in in large numbers, which surprised him.

A few other early choices are worth knowing, because they explain why DEV felt the way it did:

Sign-up needed an existing Twitter or GitHub account.

Ben called that a low barrier for most developers. It also gave the team some history to look at, since a brand new account that mirrors a banned one can be flagged as spam or harassment. If you had neither account, he said, they worked with you.

Writers could cross-post.

Jess said an early feature let creators import posts through RSS while keeping their canonical URL, so people could bring their blog posts with them without losing credit.

The team reached out to writers by hand.

And the Twitter account amplified quality content from writers who were not famous, which Jess says helped DEV grow.

The technical choices were deliberately dull.

Ben picked Rails and called it "boring and old" on the Changelog, which he meant as a compliment. In his 2021 Indie Hackers AMA, he said the choice of "solid, stable technology" was the best early decision they made. He also said he had been using Node at his day job and wanted an environment he liked more.

One more quote I like from Developer Tea:

Ben Halpern

"A blog post is worth a thousand readmes."

Ben was making the case that a person explaining a tool in their own words is often more useful than the project's official docs. That is basically DEV's entire pitch in one sentence.

The worry that almost stopped it

Now for the quiet tension in this chapter.

Ben told the Changelog he was protective of the project. He worried that turning it into a business could ruin it. He wanted everything on the site to be "additive," not extractive.

What changed his mind? A conversation with Saron Yitbarek, the founder of CodeNewbie, who had just left her job to run CodeNewbie full-time. Seeing that, Ben said, helped him believe the project could be a real business.

And then he made a promise: he committed to giving the project ten years. In his 2021 Indie Hackers AMA, he repeated that as advice for anyone building open-source companies: commit to a ten-year horizon, even through the slow years.

Hold on to that ten-year promise. We will come back to it at the end.

How big was it, at the very start?

We have exactly one number from the early days, and it comes from the progress report. The team ended October 2016 with 69,259 sessions for the month.

That is not nothing, but it is small. A year later, the same report would say something very different. We will get there. First, we need to answer the question that has been hanging over this whole story.

How did three people become a company?

↑ Back to contents

Chapter 5: The decision, and the date that cannot be right 🕵️

On November 1, 2017, Jess published a post called "First monthly dev.to progress report." It is short, it is written by one of the founders, and it is the closest thing to an official origin story that the team put in writing at the time.

Jess Lee

Nov 1 '17

First monthly dev.to progress report

#meta

2 min read

Read it carefully and you get the whole setup. At the time of the decision, Jess was working at a larger company and getting ready to go full-time on dev.to. Ben was in what the report calls a "trickier situation": his day job was CTO of a small startup, which he ran with Peter Frank. Ben had met Peter through Reddit and had worked with him for four years.

Peter knew the community was growing. So it was no great shock when Ben raised a problem: dev.to was taking more and more of his attention, which was a conflict of interest with the startup. Meanwhile, he and Jess were trying to figure out how Jess could work on dev.to full-time.

After some "soul-searching," the post says, the three decided to combine their efforts and resources. They merged teams, five people in total, and had been running on friends and family funds ever since. About ten months later, the report says, they were "really happy" with the balance. And then comes one of my favorite throwaway lines in the history of startups: as a "fun fact," the post says the three are referred to as PBJ internally.

That is the first time I found the nickname in writing. I could not find who invented it or when.

Ben tells a similar story in the Changelog interview, from his side. He says the project was folded into the existing company, and that Peter, his partner, took on much of the business and legal work. In the Dec 2017 AMA, he put it more simply: when dev.to "could be bigger than a two-person side project," that is when they brought Peter on. And, with a joke, he said, "Having three partners is great for breaking ties in arguments."

Wait. January 2016?

Here is where the detective work starts.

The progress report says the three agreed to combine "in January 2016." I read that line, then read the post's own numbers, and something did not add up.

Let me lay it out, because this is the kind of thing you can only trust if you can check it yourself:

Jess had not joined yet in January 2016. By the report's day counts, Jess joined 485 days before November 1, 2017. That is about July 2016. So Jess could not have been preparing to go full-time six months before even starting.
Ten months does not match 2016. The report says the merged team had been together for "about ten months." Ten months before November 2017 is roughly January 2017.
The report says they were dreaming of it a year earlier. It also says that in October 2016 they were "dreaming of" working on dev.to full-time. That only makes sense if the decision came after October 2016.

So my reading is that "2016" is a typo for 2017. And I am fairly sure, because more sources lean the same way:

In the AMA Peter posted on December 20, 2017, he says he has worked on dev.to with Ben and Jess "since last January."
Peter's DEV profile says he joined on January 3, 2017.
In the same thread, Ben says they brought Peter on when dev.to "could be bigger than a two-person side project earlier this year." (Earlier this year, as in 2017.)
Jess, in the 2021 interview, says the team went full-time in 2017.

I want to be honest about what this is. It is an inference from the report's internal numbers and the founders' other statements. I did not find anyone correcting the original post. But I would be surprised if the answer were anything other than January 2017.

A coincidence I cannot explain

While I was working on this, I found something interesting. DEV has a Product Hunt page with a launch date of January 2, 2017. The ranking of number one for the day is credited to January 3.

So the Product Hunt launch, Peter's DEV join date, and the "January" decision all happen in the same few days.

I want to be very clear: I have no evidence that these are connected. It may just be a coincidence of timing. I also cannot fully explain why the page shows two dates for the launch. Time zones and the way Product Hunt displays launches might explain a one-day gap, but that is a guess, and the upvote counts on the page were ambiguous, so I am leaving them out. The founders do not say the launch caused anything. I will not say it for them.

What the report does not tell us

This is one of the places where the record goes quiet, so let me list what is missing, because it is a lot:

Who suggested the merger.
How equity was split, or what anyone was paid.
How titles were handed out.
Who came up with "PBJ" and why it stuck.

I looked for these elsewhere and found nothing. That does not mean the answers do not exist. It means they have not been made public, as far as I can tell.

↑ Back to contents

Chapter 6: The year everything grew 17 times

Now we get to the fun part. Let me show you what the first year of the three-person team looked like in numbers.

In the same progress report, the team says that October 2017 brought 1,203,378 sessions and 39,539 registered members.

Let me put that next to the number from the previous October:

Month	Sessions	Where it came from
October 2016	69,259	The November 2017 report
October 2017	1,203,378	The same report

That is about 17.4 times more traffic in twelve months. (I did that math myself, and both numbers are sessions from the same report, so it is a clean comparison.)

Meanwhile, in April 2017, Ben told Developer Tea that dev.to got about 30,000 unique visitors a day, roughly 600,000 to 700,000 a month. Do not subtract that from the October number. Those are different measures: unique visitors count people, sessions count visits. Mixing them gets you nonsense.

Ben also said the most-read articles then reached around 100,000 reads, and a typical article got several thousand. And he said something I think is a good picture of the time: he was encouraging people to write short, practical posts, since long drafts tend to stall, and a quick "heads up" tip can be really valuable.

What the team shipped that year

By Jess's November 2017 AMA, the product list had grown. Jess listed:

Reactions on articles (with a note that "the unicorn reaction is up for interpretation")
Notifications
A smarter home feed
Self-created organization accounts
A #hiring board

And Peter said hiring tools were an area he saw as important for revenue, as long as people who did not care could ignore them.

How the team ran in those days

Here is one of my favorite details, again from Jess's AMA. The team held a retro every Friday, in a "Rose, Bud, Thorns" format. Roses are things to celebrate, buds are new things to be excited about, and thorns are things to fix. Jess admitted that the hardest part was remembering to give feedback, because the team often rushed through them.

Jess also gave some practical advice on hiring: remove personal details from resumes, and have each interviewer write their feedback on a form before discussing it, so the group does not just follow the loudest voice.

And about growing a community, Jess said it takes time and cannot rely on a "build it and they will come" mentality. The hardest part, they said, is deciding which advice to take and which to drop. They also gave the community the credit: "our tech isn't anything to write home about."

Honestly, that is a pretty healthy attitude for a startup in a year when everything was going up and to the right.

The monthly report, as a habit

One more thing about that November 2017 post. It was titled the first monthly progress report. The idea was to keep the community in the loop each month. It is a small thing, but it matches what the founders said about transparency. When Mayfield later invested, they made a point of saying the code and the business were open to the community's scrutiny.

But before we get to the money, there is another milestone in 2018, and it is a big one.

↑ Back to contents

Chapter 7: The day the code went public 🔓

If you want to understand DEV's character, look at what the team did on August 8, 2018.

They gave away the code.

Ben picked the date himself. On the Changelog he called 08.08 "a lucky number." The code went live at 1 PM Eastern, and the Changelog hosts recorded their interview with him a couple of hours later. You can hear that in the conversation: this is a person who has just done something big and is still a little buzzed from it.

The team had announced the date more than a month in advance, which Ben said created a deadline and some excitement. Before launch, outside auditors reviewed the codebase for security problems, and DEV ran a modest bug bounty that turned up small exposure issues over time. Ben also brought up the Homebrew supply-chain incident as a reason to take security seriously in open source.

Then came the question everybody asks: aren't you afraid somebody will just clone it? Ben's answer was that the community is more valuable than the code. So no, that did not stop them.

"A starting line"

On the day itself, Ben published a post called dev.to is now open source, credited to him together with Jess and Peter. He wrote that this was "not a finish line" but "a starting line."

Ben Halpern

Aug 8 '18

dev.to is now open source

#meta #opensource

1070

143

4 min read

The code is a Ruby on Rails app with a Preact front end, released under the AGPL-3.0 license, with some extracted libraries under MIT. The repository started under the thepracticaldev organization and later moved to forem/forem. (I could not open the GitHub repo from my environment, so the license and repo details come from DEV's own posts and other reading, not from checking the repo directly.)

forem / forem

For empowering community 🌱

Forem 🌱

For Empowering Community

Welcome to the Forem codebase, the platform that powers dev.to. We are so excited to have you. With your help, we can build out Forem’s usability, scalability, and stability to better serve our communities.

What is Forem?

Forem is open source software for building communities. Communities for your peers, customers, fanbases, families, friends, and any other time and space where people need to come together to be part of a collective See our announcement post for a high-level overview of what Forem is.

dev.to (or just DEV) is hosted by Forem. It is a community of software developers who write articles, take part in discussions, and build their professional profiles. We value supportive and constructive dialogue in the pursuit of great code and career growth for all members. The ecosystem spans from beginner to advanced developers, and all are welcome to find their place…

View on GitHub

According to a note on the announcement page, the first merged pull request went to a contributor with the handle _bigblind. Somebody always has to be first.

Ben's one regret

Here is something I did not expect. When the Changelog hosts asked Ben what he would change, he said he wished the project had been open source right away. It would have been "much cleaner the whole way," he said. He added that he would not close-source a future project without a very good reason.

I like that answer, because it is not the polite "no regrets" answer. It is a practical one: closed-source code tends to pick up shortcuts nobody wants to show.

He also pointed to Linux as the model for open development, and said Microsoft had to embrace open source to survive.

Did anyone actually contribute?

Fair question. Headlines like "hundreds of contributors" can mean almost anything, so here are the specifics the team gave.

By November 22, 2018, in a thank-you post, the team said 90 community members had contributed since August. The changelog entries it mentioned included a feature to export posts (by a contributor called rhymes), a GitLab link on profiles (by sidemt), and updates to the comment box (by Nick Karnik).

By August 8, 2019, in the one-year post, the team said traffic had more than tripled, the site had passed 200,000 registered members, and hundreds of developers had pull requests merged.

And then there are the small, human details, which I love:

A day after the announcement, rhymes opened pull request #303, suggesting the team run the bundler-audit vulnerability checker before each build.
Andrew Bone's first pull request (#1227) moved a menu background down by 8 pixels. A later one (#1306) added CSS variables that made multiple site themes possible. That is a very nice path: from "8 pixels" to "themes."
The team hired contributors from the project onto the core team. rhymes joined a couple of months after the 50th merged pull request in March 2019.

In 2021, Jess said more than 550 people had contributed to the codebase. They also said something that stuck with me:

Jess Lee

"open source code blossoms and closed source decays."

And they admitted that when DEV was first open-sourced, the code was heavily hard-coded for the developer community, which is a nice way of saying it was not built to be reused yet.

One caution: these are the team's own numbers. I did not count commits in the repository, so I cannot confirm any totals independently.

The one-year post also sketches what the team called a "phase 2": separate community instances, with examples named like stripe.dev and community.nba.com, each running the same software with its own data.

Keep that idea in your head. It is the seed of Forem.

↑ Back to contents

Chapter 8: Money arrives, and the office disappears

Let's talk about the part of every startup story people either love or skip: the money.

Friends and family, then about $950,000

For the first stretch, we already know from the progress report that the five-person team was running on friends and family money. The report gave no amount.

The next step is a bit blurrier. When the Series A arrived in 2019, the founders looked back and said they had raised "~$950k from a group of developer-focused angel investors and funds," and linked to an October 2018 post announcing it. I could read the comments page of that post, but not the post itself. So that $950,000 figure rests on the founders' own later description. I did not find a list of investors or any terms for that round, and I am not going to guess.

The $11.5 million round

On November 7, 2019, the company announced an $11.5 million Series A led by Mayfield, with earlier investors like OSS Capital and Charge VC joining. The details line up across the founders' own announcement, the press release and independent coverage from SiliconANGLE and AlleyWatch.

Ben Halpern for The DEV Team

Nov 7 '19

Special Announcement From the DEV Founders

#news #meta

644

4 min read

Mayfield also wrote about the deal. Here is the interesting part. They compared DEV to the early days of HashiCorp, whose Series A they had also led. They said Ben, Jess and Peter (they spelled it PBJ) had a "clear and bold vision." They noted that DEV had about 5.5 million unique visitors a month and about 11.2K stars on GitHub. And they made a point of the trust angle: DEV does not track users or hoard their data, and "every line of code is auditable by the community itself."

Business Insider published the pitch deck, which is where a projection of 15 million monthly visitors by the end of 2020 and 30 million by the end of 2021 comes from. I want to be careful with that: it is a forecast made to investors, not a result. I did not find a valuation anywhere, so I will not give you one.

Who controls what?

The governance details in the announcement are worth reading closely. Ben, Peter and Jess said they would keep majority control of the board. Mayfield's Navin Chaddha and Vivek Saraswat joined it. And the post says Jess was the COO, while Peter and Ben acted as co-CEOs, with Jess joining a new compensation committee alongside Chaddha.

The announcement also says something that made me smile: the three had "not talked a lot about our specific titles" before then. So the titles were made official in 2019, and the post says they reflect how the three had already worked together for years.

How DEV said it would make money

Over the years, the founders described a pretty consistent pattern:

2017: Jess's progress report described a new #hiring page, free for companies at first, with a fee planned once it was better.
January 2018: Ben announced paid sustaining memberships, framed as a way to build a sustainable business.
2018: On the Changelog, Ben said revenue came from sponsors, partners and community contests.
2019: The Series A announcement described a "useful and unobtrusive" classified listings section and "ongoing high level sponsorship relations," and said those were not the end game. Jess told AlleyWatch that DEV's "business model is not predicated on hoarding user data" for ad revenue, and pointed toward commercial open-source models like hosting and support.
2021: In his Indie Hackers AMA, Ben said the long-term plan was Forem services, like the hosted Forem Cloud. DEV itself, he said, made money from sponsors (including its CodeLand virtual conference), online hackathons and partnerships.

What I could not find anywhere is DEV's revenue, profit or burn rate. If you see a number for any of those, treat it as a guess.

The office that went away

On October 10, 2019, Jess posted The DEV Team is now 100% distributed. The company had closed its Brooklyn office and gone fully remote, with team members in four US states and three countries.

Jess Lee for The DEV Team

Oct 10 '19

The DEV Team is now 100% Distributed

#career #meta #remote #productivity

475

4 min read

The post traces the history of where the team worked: Ben's basement and coffee shops, then a tiny office in the Flatiron area, then a larger shared office with a company called Timber. It says the team prioritizes asynchronous work with "very few meetings," and that everyone dials into video calls from their own computer, even when some are in the same room, so nobody has an advantage.

By 2021, Jess said the team had grown from about fifteen to about forty people across roughly eight time zones. They had no-meeting Fridays, meetings that default to 25 or 50 minutes, and all-hands rotated across three time zones because no single time works for everyone. The team also kept a private internal forum so it did not have to scroll endlessly through Slack, and it managed both technical and non-technical projects through GitHub. And because the team was already remote when the pandemic started, they did not have to scramble for desks and laptops.

I did not find any source linking these work habits to changes in growth or quality, so I will not claim a link. But it is a nice piece of the culture to know about.

↑ Back to contents

Chapter 9: DEV gets a big sibling called Forem 🌍

Here is the point where people get confused, so let's go slowly.

By 2020, the founders had a problem that sounds like a good one. Lots of other communities wanted what DEV had.

In a post called For Empowering Community, dated May 28, 2020, Ben explained the name Forem. The idea: each Forem runs as its own independent app, with its own database, sign-in and settings, and the goal is for Forems to be compatible with each other so people can move between them. DEV is just one instance.

Ben Halpern for The DEV Team

May 28 '20

For Empowering Community

#meta #opensource

844

116

6 min read

The post lists what a brand new Forem comes with, and it is almost everything DEV has: profiles, posts, comments, reactions, following people and tags, search, notifications, classified listings, podcasts, rich embeds, RSS ingestion, blocking, reporting, moderation, direct and group messaging, badges, theme and font settings, and data export.

A few other details from that post:

The software was already being called Forem, while the repository was still named dev.to. The team planned to move it to forem (and later did).
At the start, only public instances hosted by the team would be supported. Interested people could submit a form describing the community they wanted to build.
ThisMMALife was the second Forem.
Team members named in the post and its comments include Lisa Sy (lead product designer) and Molly Struve (lead SRE).

Self-hosting

On July 20, 2021, DEV announced that Forem self-host is now officially supported. People could now run their own Forem. A hosted version, Forem Cloud, ran alongside it.

Ben Halpern for The DEV Team

Jul 20 '21

Forem Self-Host is Now Officially Supported

#news #forem #opensource #meta

334

5 min read

In the Indie Hackers AMA a month later, Ben described Forem as "an operating system for togetherness." He said it aims to "be the kernel for a new community web." He wants it to compete with Facebook groups and Reddit, and he believes a single Forem can be very big or very small. He also repeated his regret: not planning earlier for a generalized, reusable app.

One line from that thread keeps coming back to me, because it is a trade-off many founders would recognize. You "can't do any of this in an authoritarian way," he said, and you "have to frustrate some people in order to stick to your personal values." And on decentralization, he said it has to be made invisible through good UX, because most people move toward usable, delightful experiences.

What a "Forem" looked like in practice

Jess's 2021 interview gives some real-world examples.

Forem also powers the CodeNewbie Community.
Companies like Microsoft Azure and AWS now publish on DEV through organization accounts. Jess called that a "plan for opportunism" moment, a principle that guided their career.
New Relic launched "The Relicans" on Forem and chose the hosted version instead of self-hosting.
The company produces two podcasts: DevDiscuss (Jess and Ben) and DevNews (Saron Yitbarek and Josh Puetz).
Jess leads Nevertheless She Coded, a campaign tied to International Women's Day on March 8. In 2021 it was in its fifth year.

The one sentence that clears this up

So here is the simplest way to hold it in your head:

DEV is a place. Forem is the software that makes places like it.

DEV is the first and biggest Forem. When one source says "the co-founders of DEV" and another says "the co-founders of Forem," they mean the same three people at different points in the company's history.

And what happened to Forem as a business after 2021? I could not find reliable public numbers on customers, instance counts or revenue. So I will not make any up.

↑ Back to contents

Interlude: how DEV actually felt to run

Before the big news, let me step out of the timeline for a moment, because a few things the founders said explain why DEV felt different from other places. This is the "how," and it helps make the "what happened next" make sense.

The community was the point

When the Changelog hosts asked Ben for the secret sauce, he said it was merging "fundamental human community needs with practical software development needs." He described DEV as something like Medium for developers, with portfolio features like showing your GitHub projects, and, he said, no recruiter spam. Members could host posts on their own blogs and cross-post.

He told one small story that stuck with me. A member had shut down a language project he had worked on for years, and the community showed up to support him. That is not the kind of thing you plan for in a product spec.

Moderation, in their own words

DEV's approach to moderation comes up in almost every interview, so it is worth laying out.

Ben said DEV's main difference from Twitter was that it moderates at all. He called the platform pro free speech "in every way that's practical," but said other platforms are naive about human behavior and how some groups are more vulnerable than others. He also said Twitter did not treat harassment as a problem until the outside world called it out.

The tools he described:

A code of conduct that the team enforces.
Crowdsourced reports that can escalate quickly to admins.
Private messaging and small chat rooms that act as "break-out rooms" away from big public threads.
Account history checks, so a brand-new account mirroring a banned one can be flagged.

He also noted that harassment often arrives after a post gets shared on Hacker News or Reddit. And he said the team wrote down the DEV voice in documents, with guidance like "Say this, not this," because he handled most of the communication himself and the voice had to scale.

Jess described the same philosophy in 2021. Moderation should be values-driven and human-led, not outsourced, and people who cross the line get banned. A friendly, welcoming tone lowers the barrier for newer developers. And "repeat questions are totally valid," Jess said, because the answers change as technology changes.

That is how two founders describe it. I did not find an independent audit of how well it worked in practice.

The tech, kept boring on purpose

On the engineering side, Ben's description on the Changelog is a masterclass in not overcomplicating things.

About 90 percent of traffic is served from the CDN, he said, so most page loads do not touch Rails at all.
Pages are served without personal information. Anything specific to you loads in a quick asynchronous call and is cached in local storage.
The CDN is Fastly, and he praised its instant purge, with cache clears taking roughly 100 to 200 milliseconds.
Algolia handles search, so a user in a place like Tokyo gets fast responses from nearby nodes.
Ben described using Varnish Configuration Language on the edge, which is a less common approach, and he gave a RailsConf talk about it.
Building for edge caching from the start mattered, he said. Retrofitting it later would have been "ten times tougher."

In 2021, he told Indie Hackers that Postgres is "the only technology in the stack that is really precious." He also said the team did not get too enamored with static site generators.

As always, treat those numbers as what the team said at the time. They may not match today.

Not everyone is a fan

A ShiftMag piece on the MLH deal collects community concerns: that DEV's content quality has slipped, with repetitive beginner posts, search-driven writing and AI-generated articles crowding out deeper work. Those are outside opinions, not measurements, and the piece notes some of the complaints predate the current AI wave.

I mention this because a fair story about a community should include the people who are not thrilled with it.

↑ Back to contents

Who does what, in plain English

By now you might be wondering how three people with such different skills actually split the work. The founders have described it themselves, so here is that, with dates attached, because titles change.

Founder	How the role was described	As of	Where it came from
Ben Halpern	Co-CEO: long-term vision, product decisions, community leadership	Nov 2019	Series A announcement
Peter Kim Frank	Co-CEO: partnerships, growth, new opportunities	Nov 2019	Same announcement
Jess Lee	COO: internal operations, hiring plans, team organization, compensation committee	Nov 2019	Same announcement
All three	"Forem's co-founders" who lead DEV, no individual titles	Current About page	dev.to/about

I also found an April 2021 archived copy of the About page that still listed Ben and Peter as co-CEOs and Jess as COO. The current page uses only the group description. So I do not claim any current title for any of them.

The self-descriptions fit those titles nicely:

Ben calls himself abstract, chaotic and disorganized.
Jess is the organized, disciplined one, per Ben. In 2021, Jess also described an open-source community manager, Christina Gorton, who brings community requests to the engineers.
Peter calls himself the least technical, and handles strategy, operations and much of the business and legal side.

You can also see the split in public, though that only tells you about public output, not about who worked hardest. Ben writes most of the announcements and product posts under his own name. Jess wrote the progress report, the open-source thank-you and the remote-work post. And Peter's DEV profile is quieter, with more personal side projects and the occasional post for The DEV Team.

↑ Back to contents

Chapter 10: February 18, 2026 🚀

For a long time, the story of DEV is about growth, and openness, and community. Then in February 2026, it gets a new chapter.

On February 18, 2026, Major League Hacking, known for its student hackathons, announced that it had acquired DEV. MLH's own post, Major League Hacking acquires DEV, says it plainly: "Major League Hacking has acquired DEV (dev.to)." The founders posted their own version the same day, signed "PBJ."

Ben Halpern for The DEV Team

Feb 18

A New Chapter: DEV is Joining Forces with Major League Hacking (MLH)

#news #devto #hackathon #discuss

445

125

6 min read

A press release carried the same news. ShiftMag wrote its reaction piece two days later.

What the companies confirmed

I am going to keep this section very clean, because it is where rumors love to grow.

DEV is now part of MLH.

DEV's post says "DEV is officially part of the MLH organization." The wording differs between the two sides ("joining forces" in DEV's post, "acquired" in MLH's), and DEV's own post does not use the word acquisition, but MLH's post and the press release do.

Size.

MLH describes DEV as having more than 3 million developers and MLH as reaching more than 1.5 million across nearly 100 countries, for roughly 5 million together. Those are MLH's figures.

The team stays.

DEV's post says "The original team isn't going anywhere" and that CodeNewbie remains a core part of DEV. It promises a revamped Trusted Moderator program and the return of some past community initiatives, which it calls "immediate, community-first improvements," and not sales initiatives.

Forem continues.

The post says MLH and DEV will remain stewards of Forem, that the partnership will clarify the difference between DEV and Forem, and that Forem will be able to operate more independently. It also admits the team does not have the Forem arrangement "entirely worked out," with news promised in "the coming months." MLH's post says something similar: it is working toward a structure that supports Forem's independence.

Ben has a new role.

He wrote that he was "already hard at work in my new role at MLH." The post does not say what the role is.

A livestream.

A Q&A with Ben, Jess, Peter and MLH's leaders was set for February 19, 2026. I did not watch it, so anything said there is outside this article.

What nobody has said (yet)

I looked hard for these and could not find any of them:

The price, the structure (cash, stock, both), the closing date, or a valuation. If you see a number for the deal, it is not sourced.
Titles, equity or pay for Jess and Peter after the deal, or Ben's exact role.
Who owns and governs Forem now.
Any change to DEV's domain, pricing, data handling or staffing, beyond the "original team" line.

The community's first reaction

The ShiftMag piece calls it too early to judge. It collects worries (low-effort content, a site that could turn into a marketing channel for hackathon projects) and some optimism that MLH could help if it curates strong engineering writing. Those are the opinions of the people quoted. I am not adding a verdict of my own.

How Jess described it

The most personal account I found is from Jess. In a post titled A year of change and persistence, dated March 31 (no year on the page, but the WeCoded 2026 banner makes 2026 the obvious reading), Jess called the acquisition "a moment of immense pride that also marked a profound transition."

WeCoded 2026: Echoes of Experience 💜

Jess Lee

Mar 31

A Year of Change and Persistence

#devchallenge #wecoded #career #dei

114

4 min read

They described what changed. For years, Jess, Peter and Ben ran the company as a trio, and their identities were closely tied to it. After the acquisition, Jess went from holding final responsibility for decisions to being one voice in a larger organization, which means "leading through influence rather than direct authority."

The post also covers things beyond the deal: Jess's decision to use they/them pronouns, the climate for women and underrepresented people in tech, a visit to an MLH hackathon for women in computing, and a line I think is worth repeating, that developers "are the architects of the interfaces the world lives in." It is worth reading in full if you care about the people behind DEV and not just the deal.

↑ Back to contents

Where the three are now

This is the part most likely to go stale, so every line has the date I last checked it. I checked the public pages below on November 10, 2026. DEV leaves the year off recent posts, so where I give a year for a post, I inferred it from the page's own last-updated date.

Ben. His DEV profile still says "Co-founder of DEV" and Community Curator. Recent posts include the Meme Monday series and a series called Daily Context, with the latest in October 2026 (profile last updated October 21). Ben said in February that he was already in a new role at MLH. Neither the post nor the profile names it, so I do not either.

Jess. Jess's profile lists them as Founder-in-Residence at Major League Hacking and co-founder at DEV. I did not find a description of what the Founder-in-Residence role involves.

Peter. His profile says he works "across all things partnerships, sales, biz dev at DEV and MLH." He is still posting: a welcome thread and a post for The DEV Team in 2025, and personal projects through 2026, the latest I saw dated October 13.

Ben HalpernFollow

A Canadian software developer who thinks he’s funny.

Jess LeeFollow

Building DEV with everyone here. What do we have if not community?

Peter Kim FrankFollow

Working across all things partnerships, sales, biz dev at DEV and MLH 🤝️

The three together. The About page, last updated November 9, 2026 according to its metadata, still says DEV is led by Forem's co-founders and that DEV "has joined forces with Major League Hacking." So as of that date, all three are presented publicly as still connected to DEV and MLH. What I cannot tell you is who reports to whom, who holds which title, or whether anyone is in an operating or advisory role.

↑ Back to contents

Epilogue: the ten-year promise

Let me end where I told you we would end.

Back in 2018, Ben told the Changelog he had committed to giving the project ten years. In 2021, he said the same thing to Indie Hackers as advice for open-source founders: commit to a ten-year horizon, even through slow years. If you start counting from when dev.to began in 2016, or from when the three went full-time in 2017, ten years lands in 2026 or 2027.

And that is exactly where the story is now. DEV is part of MLH. Ben is still publicly connected to it, and says he is hard at work in a new role. That is my observation, not something any of them said, and I will not stretch it into a prediction.

What the story shows

Here is what I take away, and I tried to tie each point to something the sources actually show.

The audience came first. The Twitter account began around August 2014 and the dev.to domain arrived roughly twenty months later. By the time the site had 69,259 sessions in October 2016, there was already a crowd to invite.
They combined instead of competing for Ben's attention. Per Jess's report, Ben's conflict between a CTO job and dev.to got resolved by putting three people and their resources together.
Titles came late. The founders said in 2019 that they had barely discussed titles before the Series A.
Open source was a choice, and the community showed up. Contributors made real changes, and some got hired.
Funding stayed modest for a long time. Friends and family in 2017, about $950,000 in 2018, an $11.5 million Series A in 2019, with the three keeping a majority of the board.
The revenue they described stayed small and close to the community. Job listings, sponsors, memberships, and later Forem services.

And a thing I want to say plainly: so many separate pieces had to line up for a Twitter account to turn into a company. An audience. A partner willing to take on a conflict of interest. A third co-founder ready to go full-time. And investors who liked an open-source plan. Each of those is documented. What happened in all the years in between is the part only the founders can fully tell, and I did not talk to them.

The timeline, on one page

If you got lost anywhere above, here is everything with a date, in order. "Approximate" means I worked it out from a source's numbers.

Date	What happened
About 2013	Ben and Peter begin working together, after meeting on Reddit (from Ben's and Peter's comments)
About Aug 2014	The Practical Dev Twitter account starts (approximate, from the 2017 report)
Dec 27, 2015	Join date shown on Ben's DEV profile, earlier than the domain date below; Ben first used `practicaldev.com`, which may explain it (my guess)
About Apr 2016	`dev.to` domain bought (approximate)
About Jul 2016	Jess joins the project (approximate)
Oct 2016	69,259 sessions for the month
Jan 2017	Product Hunt launch (Jan 2 or 3), Peter joins (Jan 3), the three likely combine efforts (my reading of the report)
Apr 2017	Ben cites about 108,000 Twitter followers
Nov 1, 2017	First monthly progress report, 1,203,378 October sessions
Dec 20, 2017	Peter's AMA on DEV
Jan 2018	Sustaining memberships announced
Aug 8, 2018	Codebase goes open source
Oct 2018	Roughly $950k raised (as described later)
Aug 8, 2019	One year of open source
Oct 10, 2019	Team goes fully distributed
Nov 7, 2019	$11.5M Series A led by Mayfield
May 28, 2020	Forem named
Jul 20, 2021	Forem self-host officially supported
Feb 18, 2026	MLH announces it has acquired DEV

The things I still do not know

Who came up with "PBJ," and when.
Whether "January 2016" in the 2017 report was a typo for 2017. I think so, for the reasons above, but I have no confirmation from the authors.
The terms of the 2018 round, the Series A valuation, and any figure for the MLH deal.
What Ben, Jess and Peter do at MLH, and how Forem will be structured.
Whether the community's worries about content quality play out once MLH's plans take shape. ShiftMag says it is too early to tell, and I agree.

Your turn 🙂

If you have been on DEV a while, when did you first notice the "PBJ" sign-off, and what did you think it meant? And if you were writing a note to the next team that takes this on, what would you tell them to protect?

Tell me in the comments.

Meet the team on the DEV About page

Let's Talk About Ideas! 💡 — Share Your Startup Ideas, Products & Experiments

Prasoon Jadon — Wed, 11 Nov 2026 04:48:59 +0000

Every great product starts somewhere: an idea, a problem, or sometimes just a random thought.

I want to start an open discussion for developers, indie hackers, founders, and aspiring entrepreneurs.

Let's talk about ideas!

Whether you're working on a startup, experimenting with a new technology, building a SaaS product, or simply thinking about something that doesn't exist yet, this is your space.

What can you share?

🚀 Startup ideas you're exploring.
💻 Products or projects you're currently building.
💡 Problems you think deserve better solutions.
🔬 Experimental products and prototypes.
🤝 Ideas where you'd like feedback or collaborators.

Have a product ready for testing?

If you've built something and want additional testers, you can also submit your product details to the VyomaLabs team via email for potential testing consideration.

Please include:

Product name and description.
Website or demo link.
What kind of testing or feedback you're looking for.

Email: [vyomanews@gmail.com]

Let's get the discussion started!

I'd love to hear:

What's an idea you've wanted to build but haven't started yet?
What are you currently building?
What problem do you think nobody is paying enough attention to?

No idea is too early to discuss. You don't need a finished product to participate.

Let's discover, discuss, experiment, and build together. 🚀

Does Sharing Devlogs Put Your Game Ideas at Risk?

MT Indie Dev — Wed, 11 Nov 2026 01:52:42 +0000

As a solo game developer, I enjoy sharing what I’m building. There is something satisfying about showing a scene coming together, explaining a problem I solved, or letting someone see how much a project has changed.

But lately, I’ve been asking myself a question: how much should I share before the game is released?

Devlogs invite people into the development process. They give a project a chance to find an audience while it is still taking shape. Yet that openness also means showing ideas that someone else could potentially use before you have finished building them yourself.

That possibility makes me hesitate.

When showing progress means revealing the idea

Sharing lighting improvements or a new environment feels relatively comfortable. Explaining a particular puzzle, a story connection, or an unusual mechanic feels different.

For a mystery game especially, those details can be a large part of what makes the experience worth playing. Showing how something works might reveal both the idea behind it and the surprise intended for the player.

Then there is the thought that someone with more time, money, or experience could see an idea, build their own version, and release it first. I cannot say how likely that is. But when you are developing alone and every feature takes considerable effort, it is difficult to dismiss the concern entirely.

“Ideas are nothing without execution”

This is a common response to the fear of having an idea copied, and I understand the reasoning. A concept still needs design, writing, programming, art, sound, testing, and all the decisions that turn it into a finished game.

Still, that answer does not completely settle the question for me.

Execution matters, but so does the thought that went into finding an interesting premise or designing a puzzle. A developer can spend a long time working out how separate details connect. Being told that the idea has little value until it is finished can feel dismissive of that work.

I would rather ask where the practical boundary should be. What can we share openly, and what benefits from staying private until players can experience it themselves?

There is a cost to keeping quiet, too

Waiting until release would let me develop without constantly deciding what is safe to show. It would also mean giving up opportunities to receive feedback, meet other developers, and introduce people to the game.

I enjoy those parts of sharing my progress. I don’t want every post to become an exercise in worrying about who might be watching.

At the same time, I don’t think documenting development has to mean revealing every important discovery. Perhaps a devlog can show the atmosphere, the work, and the challenges while leaving the central story and the most distinctive puzzles unexplained.

That sounds reasonable in principle. Deciding what that looks like for each post is harder.

Where do you draw the line?

I’m still working out how much of my own development process I want to share. I want people to become interested in what I’m creating, while preserving the details I’ve spent so much time imagining.

So I’d like to hear from other developers:

Have you ever worried that sharing a devlog could lead to someone copying your ideas?
Have you experienced it, or has sharing mostly brought useful feedback and support?
Which parts of your game do you deliberately keep private?
Would you share progress throughout development, or wait until the game is closer to release?

How do you decide when sharing an idea helps your game, and when you would rather keep it to yourself?**

Your “Private” Search Engine Might Run on Bing. This One Builds Its Own Index

Hanzla Baig — Sat, 07 Nov 2026 13:07:03 +0000

Be honest: when a privacy page says "we care about your data", do you believe it? 😅

Yeah. Me neither. Big promises, a padlock icon, and a footer that quietly takes half of it back.

So when I opened the LYNX page from Anoneurx, I was ready to squint again. Then I reached the FAQ, and the first honest thing it told me was that the engine is not anonymous and not "zero logs".

On purpose.

It said it again in the privacy policy. And again in the security page. And again in the benchmarks.

That was enough to make me read everything: the project page, the README, the privacy policy, the security policy, the roadmap, the changelog and the benchmark page. (Yes, even the changelog. I regret nothing.)

This post is what I found: what looks genuinely good, what is still unproven, who is behind it, and how you can help. In a hurry? The table right below is your 60-second version.

🔗 Quick links

Project page: anoneurx.com/en-us/opensource/lynx

Source code: github.com/anoneurx/lynx (AGPL-3.0-or-later)

Benchmarks: anoneurx.com/en-us/benchmark/lynx

anoneurx / lynx

An independent search engine focused on privacy, security, and fast discovery.

An independent, privacy-focused web search engine by Anoneurx

fast discovery · no tracking · open infrastructure

What LYNX is

LYNX is a search engine built the way we would want one built: fast, inspectable, and hostile to surveillance. It crawls the public web under robots.txt, indexes what it is allowed to index, and serves results without building a profile of who asked what.

v0.1.0. The §Z implementation order is complete end to end: crawler, parser indexer, query processor, BM25F ranker, public API with SERP, Postgres storage politeness and safety gates, observability, and the optional Astra answer layer. Every step is test-gated; see CHANGELOG.md. Plans beyond v0.1 — scale, sharding, multi-region — live in ROADMAP.md and are not claimed as done.

What makes LYNX different

Three structural gaps are visible in today's landscape, and LYNX is built around closing them rather than out-texting another SERP:

Gap in existing engines

…

View on GitHub

TL;DR: the 60-second version

Question	Answer
What is it?	An independent, privacy-focused web search engine
Current version	`v0.1.0`, released on October 27, 2026
Built with	Rust and TypeScript, Tantivy for indexing, BM25F for ranking
License	AGPL-3.0-or-later, with commercial licensing from Anoneurx
Status	Phases 0 to 5 shipped, Phase 6 (scale) still planned
Tests	56 test suites, which the project says were green at every gated commit
Biggest weakness	A small index: roughly 1.2M pages across about 42K domains

That last row is not me being harsh. It is the project's own number, and they put it on the benchmark page under a heading about their honest weakness.

Solid vs. still unproven

Area	Status	Why
Privacy design (no query text stored)	✅	Backed by a CI check on banned log and metric fields, per the project
Threat model	✅	35 threats, each with impact, likelihood, mitigation and leftover risk
Explainable ranking	✅	`explain=true` shows the signals per result
Comparison vs. Google, Bing, Brave, Mojeek, DuckDuckGo	⚠️	The page labels it a placeholder run with provisional scores
Speed figures	⚠️	Small corpus, one 8 vCPU / 32 GiB machine, not a production promise
Coverage for fresh, local and non-English queries	⚠️	The project admits recall is weaker here
Scale (sharding, multi-region)	🗓️	Phase 6, still planned

Notice the pattern? The ✅ rows are mostly design choices. The ⚠️ rows are mostly measurements. And the project is the one who sorted them that way, not me.

Three problems LYNX is trying to fix

I liked that LYNX does not say "we are a better Google." It points at three specific gaps instead.

1. A lot of private search runs on rented results

Some privacy-friendly engines get their web results from Bing or Google behind the scenes. Your queries may be handled respectfully, but the ranking you see still comes from the company you were trying to avoid.

Awkward.

LYNX tries to own the whole path:

crawl -> index -> rank -> serve

All of it runs under robots.txt, with no syndication deal anywhere in the loop. The project also points out that a 2024 Bing API outage took several "private" engines down with it. When your results are borrowed, someone else's bad day becomes yours.

Verdict: ambitious. The small index shows how far it still has to go.

2. AI answers that sound sure and cannot show their work

The README cites a 2025 CJR Tow Center study where all eight AI search tools tested had citation problems.

All eight. 😬

LYNX's answer layer, called Astra, is built to be cautious. More on that below.

Verdict: the right instinct. Let's see if the design holds up.

3. Ranking is a black box

Ever wondered why result A beat result B?

Normally nobody tells you. LYNX has an explain=true option that shows a "Why this ranking?" panel for each result. I'll get to that too.

Verdict: my favorite of the three.

Privacy by construction, not by promise

This is the part that made me slow down and reread.

Many services say "we don't log your searches." LYNX tries to make logging structurally awkward. The query is turned into a parsed structure (an AST) at the handler boundary, and the raw string is dropped. In their words, there is nothing left for a logger to log.

Think of a vending machine that never prints a receipt because there is no receipt printer inside it.

Even rate limiting, usually where privacy projects quietly build a profile, is handled carefully:

bucket = HMAC-SHA256( daily_salt, first_three_octets_of_your_IP )

The salt rotates every day
Counters live in memory only, with a 25-hour expiry
Nothing durable exists to follow you from one day to the next

⚖️ A real trade-off, stated openly: two people on the same /24 network share a bucket. The project chose that availability cost over a long-term identifier.

The five rules the whole system is shaped around

No query text is stored anywhere, including the database, Redis, logs, metrics and traces
No cookies, local identifiers or fingerprinting
No third-party requests, so no external fonts, scripts, analytics or CDNs
No ads, data brokering or selling anything
Every stored field has a purpose, a retention period and an owner

A CI job reportedly searches the code for banned log and metric fields. That detail matters to me more than the slogan does.

A slogan can be ignored. A failing build cannot.

What it openly says it cannot protect

This list is why I trust the rest of the page a little more:

🚧 Hosting providers and network intermediaries can still see infrastructure-level logs
🚧 When you click a result, the destination site learns about the visit
🚧 Metadata like TLS SNI and your IP can leak coarse timing information
🚧 The index is small, so coverage will be worse than the big engines

And the retention table is refreshingly specific:

🗂️ Retention table (what is kept, and for how long)

Data	Retention	Notes
Logs	14 days	Keyed by request ID only
Rate-limit counters	25 hours	In memory only
Backups	35 days	Encrypted, and the policy admits they cannot be selectively purged

Ranking you can actually interrogate

If you add explain=true, each result can show the signals behind its position:

Signal	What it tells you
Lexical	How well the text matches your query
Freshness	How recent the page is
Quality	How the page scores on quality
Authority	How the page scores on authority
Context	The situational boost
Spam	The penalty

You also see the ranking-config version, so the numbers can be traced back to a specific setup.

The project claims no mainstream engine lets you see this for a single request. I cannot verify that claim, but the idea itself is great for anyone who has ever argued with a search result. 😉

The query language already supports operators like these (illustrative examples, so check API.md in the repo for exact syntax):

site:dev.to "privacy" search engine
intitle:crawler OR intitle:indexer
"explainable ranking" inanchor:lynx

The changelog also lists after: and before: operators, fuzzy suggestions and keyset pagination. Suggestions come from corpus statistics, never from query logs.

Astra: an AI layer that is allowed to say nothing

Astra is optional and off by default. The design reads like it was written by someone who has been burned by confident nonsense before.

Design choice	What it means
Sentence-level citation check	A sentence without a verified `[n]` citation gets removed
Refuses instead of guessing	No grounded answer means no answer
Source-trust gate	Low-trust pages are not used for grounding
No tools, no memory, no agent loop	It cannot wander off and do surprising things
Fails closed	If something breaks, you get the plain results page

An AI that is allowed to say "I don't know". Imagine that.

And then the sentence I appreciated most:

In v0.1, verification is sentence-level and content-blind. A citation has to point to a source that was actually retrieved, but that does not prove the source is true.

It limits the damage. It does not certify the answer.

So here is my honest question: would you rather have an AI answer that sometimes says nothing, or one that always sounds sure? I know which one I would pick. 🙂

A crawler that assumes the web is hostile

LYNX splits the system into two planes that are not supposed to meet:

crawl plane : robots.txt -> SSRF gate -> fetch -> parse -> extract text -> index
query plane : request -> parse to AST -> search index -> rank -> respond

The query plane never touches untrusted content. The crawl plane never sees a user query.

Some other choices stood out:

No JavaScript execution. No headless browser, no cookies, no shell
Only extracted text is stored, never raw HTML
SSRF checks run before every connection and again at every redirect
unsafe Rust is forbidden across the whole workspace
A 35-threat model, where each threat lists impact, likelihood, mitigation and leftover risk
Signed container images, SBOMs per release and fuzzing targets for URL and HTML parsing

For reporting bugs, the policy promises an acknowledgement within 48 hours and says good-faith researchers will not face legal action.

The numbers, with the fine print

Here is what the v0.1.0 release rehearsal reported:

Metric	Result
NDCG@10	0.966
MRR@10	1.000
Recall@100	0.889
Average latency	about 0.57 ms
p95 latency	0.9 ms
Burst throughput	about 1,820 requests per second
Index size	about 1.2M pages, 42K domains

Pretty numbers, right? Now the important part.

🛑 Please read this before you quote any of it.

The benchmark page includes a side-by-side comparison with Google, Bing, Brave, Mojeek and DuckDuckGo. The page itself labels that comparison a placeholder run and says scores are provisional. The speed figures come from a small corpus on one 8 vCPU, 32 GiB machine, and the page says they are not a promise about production scale.

So this is not a "LYNX beats Google" story, and the project does not tell it that way. Their own footer says to cite the run, not the headline.

One detail I found oddly charming: the query categories include Urdu and Roman Urdu, and one sample query is about the weather in Lahore.

The same page also admits recall is weaker for fresh, local and non-English queries, so treat that as a direction, not a finished feature.

Where it is heading

Phase	Focus	Status
0	Architecture and design decisions	✅ Shipped
1	Search prototype and evaluation harness	✅ Shipped
2	Crawler with politeness and SSRF safety	✅ Shipped
3	Link graph, operators, sealed index generations	✅ Shipped
4	Privacy hardening and CI privacy checks	✅ Shipped
5	Astra, the optional AI answer layer	✅ Shipped
6	Sharding, multi-region, horizontal crawling	🗓️ Planned

The changelog dates the architecture work to July through October 2026, with a scaffolding release candidate in September and v0.1.0 on October 27. That is a fast timeline for something this documented.

A small docs gap I noticed: the status table near the bottom of the GitHub README still showed Phase 0 as in progress when I checked, while the website and changelog say v0.1.0 shipped. It looks like a document that has not caught up yet.

Good reminder to trust the release tag and the changelog, and to verify claims yourself. And if it is still out of date when you read this, it is a very easy first pull request (more on that at the end).

The people behind LYNX

A privacy project is only as believable as the people willing to put their names next to it. So here is who the LYNX project page credits, with links to the public profiles I could confirm.

Muhammad Qasim (@itskashie), founder and architect. The project page credits him with the architecture, the search ranking and the privacy model. He is a member of the @anoneurx organization on GitHub, and he announced the first release right here on DEV on October 29.

Shipping a v0.1 with a threat model, a retention table and an honest list of limits is a lot of work for a first release. That honest tone runs through everything I read, and it is the reason this post exists. Thank you for building it in the open.

Muhammad QasimFollow

Muhammad Qasim

Oct 29

🐾 Introducing LYNX A Private Search Engine by Anoneurx

#opensource #security #testing #anoneurx

1 min read

Nimrah Nabeel, contributor on search ranking and evaluation. Find her on GitHub as Nimrah-Nabeel.

Zainab Faisal, contributor on search ranking and evaluation. Find her on GitHub as zainabfaisal2105-dev.

Ranking and evaluation is the place where it is most tempting to oversell, and the evaluation pages of this project do the opposite: they label placeholders as placeholders and put the weak spots in plain view. Credit to everyone working in that area. It is unglamorous work, and it is what makes the other numbers believable.

I could not find a DEV profile for Nimrah or Zainab. If you two are reading this and have one, drop it in the comments and I will tag you properly.

❓ What about co-founders?

I could not find a co-founder named anywhere: not on the project page, the README, the DEV announcement or in search results. Contributors are not the same thing as co-founders, so I am not going to label anyone that way.

The maintainers are listed as "Anoneurx Core Maintainers" and "Anoneurx Labs" without individual names, and the testers and QA section currently says nobody is listed yet. If there is a co-founder I missed, tell me and I will add them with a link.

A note on sources: there are many people called Muhammad Qasim online, and I could not confirm that any other profile belongs to this founder. So I left out any background that the project itself does not publish.

When I checked on November 7, the repository had 34 commits, 1 star and 0 forks, and the DEV announcement had no comments yet.

Everyone starts somewhere. This is a very early, very well documented start.

So... would I use it today?

As my daily search engine? No, and the project would agree. Its own FAQ says coverage will be worse than commercial engines for years.

But I would watch it, and I would read the code. If any of this sounds like you, it is worth a look:

🦀 You like Rust and search infrastructure
🔒 You care about privacy engineering that shows its work
📊 You enjoy ranking and evaluation problems
🏠 You want something you can self-host and verify
📝 You respect projects that write down their own limits

What I would love to see next:

The raw comparison data published
The benchmark moved out of "placeholder" status
A clearer public list of who is maintaining what

FAQ

Is LYNX anonymous?

No. The project says so directly. It commits to not building a profile of you and not selling or sharing query data, but infrastructure-level logs still exist.

Is it the same as the Lynx text browser?

No. The FAQ states it is not affiliated with, endorsed by or derived from that project. There are also unrelated open-source projects that share the name.

Why AGPL?

Anyone who runs a modified LYNX as a network service must publish their changes. The reasoning given is that a search engine is infrastructure. Commercial licensing is available from Anoneurx.

Why Rust?

The main job is parsing and fetching content an attacker may control, so memory safety removes a whole class of bugs.

Can I self-host it?

Yes. A verification artefact ships with the release so the privacy claims can be checked by anyone, not only the authors.

Your turn 👇

LYNX is at the stage where a good bug report probably helps more than a like. The project is looking for its first contributors and testers, and the testers and QA section of the project page currently says nobody is listed yet.

Yes, that could be you. 🙌

Here is how you can help, from quick to bigger:

Star the repo and share it with someone who cares about privacy or Rust
Try it (or self-host it) and see where it breaks
Open an issue with what you found: a bug, a confusing doc, a query that returns weird results. Read CONTRIBUTING.md first so your issue lands the way the maintainers want it
Send a small pull request. A docs fix is a great start (remember the README status table?)
Test the edges. Fresh, local and non-English queries, including Urdu and Roman Urdu, are exactly where the project admits recall is weak
Share what you learn. Write your own post, run your own benchmark, or publish a critical review. The project itself says to cite the run, not the headline, so honest write-ups fit right in

One rule that matters: do not report security problems in a public issue. Use SECURITY.md instead. The policy promises an acknowledgement within 48 hours and says good-faith researchers will not face legal action.

The repo also has a code of conduct, so please read that before you jump in.

⭐ Open an issue, send a PR, or just try LYNX and tell the team what you find

I will leave you with the question from the launch post, because it is a good one: what would you want from a privacy-focused search engine? Transparent ranking? Self-hosting? No AI at all?

And a few smaller ones, if you feel like answering:

Would you use a search engine with a small index but honest limits?
Have you ever read a privacy policy all the way to the end? 😅
Which ⚠️ row in the table above worries you most?
Will you try it, open an issue, or send a PR? Tell me which one

Tell me in the comments, and if you do open an issue or a PR, drop the link there too. I read all of them.

To @itskashie and everyone credited on LYNX: thank you for building this in public and for writing down what it cannot do yet. That choice is rare, and it is why people like me stopped scrolling.

I hope you learned something new. And if you did not, I hope the tables were at least fun to look at. 😄

PS. If you spot a mistake in anything I wrote about the project, tell me. I would rather fix a post than defend one.

Should You Charge From Day One or Offer Your Product for Free?

Hanzla Baig — Sat, 07 Nov 2026 10:34:25 +0000

TL;DR

The loudest advice on both sides has real companies behind it. YC partners push founders to ask for money early. Figma, Slack and Segment let people in for free first. So the useful question isn't "which side is right?" but "what am I trying to learn, and what will it cost me?"
A payment is evidence that someone valued one specific offer at one specific price. It is not proof of product-market fit. Superhuman's founder says nobody got it free, not even investors, and an early survey still found only 22% of users would be "very disappointed" to lose it.
Free works when it has a job: spreading the product, exposing it to more people, or pushing people toward a limit they'll want to lift. Even then, conversion is modest. Slack's filing credits converted free organizations with about 8% of fiscal 2019 revenue. Dropbox reports roughly 18 million paying users against more than 700 million registered ones.
There's a menu between the two extremes: free trial, free beta with a deadline, paid pilot, founding-member price. A scorecard and a two-week test are near the end.

Jump to a section

A quick word on sources (I promise it's short) 🔍
Why most of us default to free (it's not a silly instinct)
What a price tells you that a signup can't
Paying isn't the same as fitting
When free is the smarter move
What the examples show (and what they can't)
What each option costs 🧾
It changes with the business: B2B, consumer, open source
The menu is bigger than two options
How to decide: a scorecard 📋
Two weeks of testing before you commit 🧪
Mistakes to avoid when pricing shows up 🙈
So, should you charge from day one?

Let's start with two pieces of advice that flatly refuse to get along.

In a 2022 video, three Y Combinator partners said the most honest feedback you'll get on your product arrives in the few seconds after you say the price out loud. Ouch, but fair.

Meanwhile, Figma's CEO told Lenny Rachitsky that Figma launched with no paid plans because the team expected the product to spread faster that way. It opened a closed beta in December 2015 and didn't charge until 2017.

Both companies did fine.

That's the problem.

If you're a solo founder staring at a half-built pricing page, "it worked for them" is available for either choice. Very helpful, history 😅

This is the fifth article in the series, and the question has been quietly hiding in all four earlier ones. Sneaky. We saw that likes and followers aren't buyers, that a pricing-page click sits below a payment on the evidence ladder, that a signup isn't the same as a user who cares, and that a Product Hunt launch can produce 400 signups and one paying customer. Pricing is where those lessons stop being theory and turn into an actual number on an actual page.

The moment you pick a number, or pick zero, you decide what kind of evidence you'll collect from then on.

A quick word on sources (I promise it's short) 🔍

I sorted what I used into four buckets: filings and company posts (the most checkable), founder interviews and retrospectives (self-reported, nobody audited them), investor and advisor opinions (YC partners, Pear VC, SaaStr), and my own analysis, which I flag when it shows up. Anything invented for illustration is labeled as invented.

Two honest gaps, because pretending otherwise would be silly.

You'll see "freemium converts 2 to 5 percent" repeated all over the internet, but I couldn't open an original dataset behind it, so I stuck to company filings and interviews.

And I looked for a controlled study comparing feedback from paying users and free users at startups. I didn't find one. Everything below on that question is experience, not experiment.

Why most of us default to free (it's not a silly instinct)

Free deserves a fair hearing first. It's not a silly instinct.

The YC partners listed the reasons they hear most often:

Founders optimize for feedback over revenue, because getting users feels easier when nobody pays.
They believe pricing is a one-shot decision with no redos.
And when they sell to companies, they fear a price will make a hard sale harder.

The partners' answer to the redo worry is practical: you can change prices whenever you like, existing users can be grandfathered in, and today's users will be a small slice of next year's. One partner recalled Drew Houston saying Dropbox's early price was a reasonable-sounding number picked without deep analysis, that it may have cost them a lot of revenue, and that it was still fine.

There's also a pull that has nothing to do with strategy. Jason Fried of 37signals puts it bluntly: free sells. People want to try something with no strings attached, even when the price is two dollars. And there's research behind the feeling that zero is a special number. In experiments by Shampanier, Mazar and Ariely, people chose the free option far more often than the price gap alone would predict, even when a better product was available for a small charge. Those were choices between small items like chocolates, so treat it as a clue about human behavior, not a pricing law for software.

My read: for people who build things, there's one more reason.

Free is the only model with zero setup. No billing code. No refund policy. No tax questions. No awkward conversation.

On a Friday night, that's a very persuasive argument 😅

It's just not a strategic one.

What a price tells you that a signup can't

The strongest case for charging early is about information, not money.

The YC partners' version: you can learn from free users, but you learn a lot more from people who pay. They also warn that "customers" who pay nothing can mislead you for years. Their example is a founder who says Apple is a customer, and when asked what Apple pays, the answer is nothing. They just get to talk to Apple. A free pilot with a big company, they argue, proves little, because nobody on the other side had to spend budget or political capital.

Superhuman took this to an extreme. Rahul Vohra said in a 2020 interview that no one got the product for free, investors included, so everyone could feel the cost and have an honest conversation about whether the exchange felt good.

True Link, a card company for older adults, went against the grain. Its competitors gave cards away and collected waitlists of 50,000 or more. True Link charged $10 a month, launched with a waitlist of about 50 (44 if you take out family and friends), and had around 1,000 customers after its first year. Founder Kai Stinchcombe argues that free-trial signups hadn't really bought anything, and that charging forced the team to find customers who would sustain the business. Ads and press produced weak interest but not paid signups. Word of mouth did.

Read both stories with the usual caution. They're self-reported, both companies survived, and True Link's claim that it broke even before its peers is the founder's own. (Survivors tend to tell good stories.)

But the mechanism is worth keeping, and it's the part I find most convincing: a price doesn't only measure your audience, it selects it. Everything you build afterward, from onboarding to support to marketing, gets shaped by whoever showed up. Stinchcombe says it would have been a different company in every respect.

A price doesn't only measure your audience, it selects it.

The Product Hunt article showed the mirror image: a launch with 400+ signups and one payer, where the point at which people dropped off told the founder what to fix. Free signups gave attention. The price gave a diagnosis.

Paying isn't the same as fitting

Careful, though. Money is a filter, not a verdict.

Back to Superhuman. Vohra says that when the team ran the survey asking how disappointed people would be to lose the product, only 22% said "very disappointed." That was a company charging $30 a month from the start. Charging got him honest conversations. It didn't settle whether the product was something people needed. (We covered that survey in Article 3.)

Plausible adds another wrinkle. It's often remembered as paid from the start, but its own timeline says the public beta launched in January 2019 and paid plans arrived in May, when it had 60 active beta users and some chose to stay and pay. The month ended at $64 in monthly recurring revenue. Yes, sixty-four dollars. After that it took 324 days to reach $400. Growth came later, once blog posts took off on Hacker News and the positioning against Google Analytics sharpened.

So early payments can mean "this offer works for a few people at this price." Whether it's repeatable, or whether a stranger would pay without your help, is a separate test.

When free is the smarter move

The other side has better examples than the "free is for people who are afraid" framing allows.

Figma

Figma didn't charge until 2017. In Lenny's study, Dylan Field says the team thought it would spread faster without a price, and that eventually not paying became the barrier for companies adopting it. Customers started asking why Figma wasn't charging, because they wanted to be sure it wouldn't go away. Free did its job, then began to hurt once buyers needed something to buy.

Segment

Segment launched with a free plan, added pricing pages about a month later, and didn't build real self-service billing until roughly nine months after launch. Its CTO says the goal was to nail onboarding and value first, and to learn the price by surveying users.

Basecamp

Basecamp is my favorite cautionary tale, because the founders did everything carefully. They launched with a free one-project plan. In 2015 they removed it and ran a six-month experiment that said the change paid for itself. Years later, Jason Fried and David Heinemeier Hansson said fewer people were seeing the product, which hurts a business that grows by word of mouth. In a March 2025 episode they explained why a free plan came back. They report that weekly signups more than doubled and that paid conversion was running a few percent ahead, though possibly not by a statistically significant margin.

They also say the goal isn't to lift the paid rate this month. It's to get enough people to see Basecamp over the next several years. A six-month test can't see a five-year effect.

Slack

Slack is the textbook case. Its S-1 says it attracts new organizations mainly through self-service, and that free organizations often upgrade as they use it more deeply, likely because of the 10,000-message limit and single sign-on. About 10% of fiscal 2018 revenue and about 8% of fiscal 2019 revenue came from organizations that had been on the free plan and converted that year. Freemium can be central to growth while most revenue comes from somewhere else.

So what do these stories have in common? In my read, free had a job. The YC partners say much the same: free is fine when there's a structured plan to get paid, meaning a constraint people want to get around and the discipline to track whether free users convert and how fast. Their listed exceptions are open-core products like GitLab, freemium with a real limit like Slack, and ad-supported consumer products that need enormous scale. Jason Lemkin of SaaStr adds that freemium doesn't work as a business model without a mass-scale product, and a revenue-operations lead in his roundup says it needs a huge market, no-touch onboarding and an obvious first "wow."

My shorthand for what a free plan can be for: it spreads the product (users bring others), it exposes it (people who'd never have heard of you try it), or it feeds a limit that paying users want lifted. If yours does none of those, it isn't a free plan. It's a gift.

What the examples show (and what they can't)

Company	Early approach	What the sources report	Source type
Superhuman	$30/month from the first user, no free tier, investors paid too	Early survey: 22% "very disappointed"	Founder interview, 2020
Plausible	Free public beta (Jan 2019), paid from May 2019, 30-day trial, open source	$64 MRR at paid launch; 324 days to $400; $1M ARR by June 2022; 33.5% trial-to-paid for April and May 2020 cohorts	Company posts
True Link	$10/month per card while rivals gave cards away	About 1,000 customers in year one vs rivals' 50,000+ waitlists; cards division profitable by 2017	Founder retrospective, 2017
Atlassian (JIRA)	Paid from the start; free only for non-profits, academics, open source	An early user's recollection, not Atlassian's own account	Secondhand, via Lenny
Figma	No paid plan until 2017	Customers began asking to pay; free became a barrier	CEO quote, via Lenny
Slack	Free plan plus self-serve paid plans from launch	About 8% of fiscal 2019 revenue from free orgs that converted that year	SEC filing
Evernote	Full-featured free version; most users meant to stay free	About 2% premium in 2010; aim to keep conversion within narrow bounds	CEO interview, 2010
Basecamp	Free one-project plan at launch, removed 2015, back in 2025	Signups more than doubled after the return; paid conversion maybe ~3% ahead, significance unclear	Founder podcast, 2025

Two caveats before drawing anything from this. First, the sample. Lenny Rachitsky studied 25 of the fastest-growing B2B companies. Seven had no paid plan at launch, nearly all offered a free plan from the outset, and every one eventually built a sales team. Those are winners picked after the fact. Second, I couldn't find a public retrospective from a startup that clearly blames its death on charging too early or staying free too long. That doesn't mean it never happens. Failed founders rarely write up their pricing decisions.

Notice what the table doesn't show: nothing in it proves the pricing choice made the company. Each founder was trying to answer a different question.

What each option costs 🧾

Every option comes with a bill. Here's how it shows up in the evidence.

Charging early costs you speed and exposure. True Link had 44 non-family waitlisters against rivals' tens of thousands. Plausible took 324 days to reach $400. Basecamp's lost exposure only showed up over years.

It can also cost you the right price. Shopify charged only a percentage of each sale for its first year, and its CEO told Lenny it totally didn't work; switching to monthly plans in 2007 or 2008 saved the company. YC would say prices can always change, and the YC partners are right about the number. My read is that the shape of the price (per seat, flat, percentage of sales) is harder to change than the figure.

Free costs money you may not be tracking. Jason Fried says the main cost is support: a paying customer who emails three times still leaves you ahead, a free one who emails twice means you've lost, though he says he'd rather not look at it that way.

He also says that when HEY ran in the cloud, each customer cost them about $30 a year to operate, which is partly why HEY isn't free. He adds that Basecamp can afford generosity because its margins are fat, and that you shouldn't copy it at 4% margins. If you build on paid AI APIs, that logic bites harder: when every free user triggers a model call you pay for, free isn't free. (My analysis.)

Here's invented math, not a benchmark. Say each free user costs $0.50 a month in support time and compute. Two thousand free users cost $1,000 a month. Now say 3% convert, near the real ratios below, at $15 a month. That's 60 payers and $900. Your free tier costs more than it earns until conversion, price or cost moves. Which of those you can actually move is the whole question.

2000 \times $0.50 = $1000 2000 \times 3% \times $15 = 60 \times $15 = $900

Free costs you signal. Phil Libin said in 2010 that about two percent of Evernote's users were premium. In the same interview he said the goal isn't to push conversion up but to keep it within fairly narrow bounds, because a very high rate would mean the free version isn't good enough.

Dropbox's 10-K shows 18.08 million paying users at the end of 2025, and its press releases cite more than 700 million registered users. That's roughly 2.6%, but it isn't a conversion rate: "paying users" counts licenses (a 50-person team counts as 50) and "registered" counts every account ever opened. Treat it as a sense of scale. Both companies built big businesses on a small share of users. Neither can tell you your share will be big enough.

The YC partners also describe the quieter failure: founders who give the product away, say they'll see how it goes, and keep adding features without ever charging.

It changes with the business: B2B, consumer, open source

B2B

The YC case is that companies spend money on software constantly, so a price isn't the obstacle founders imagine, and not charging can read as "will these people be around to support us?" Pear VC's Pepe Agell goes further: pilots should never be free. His formula is a pilot priced at a 20 to 50 percent discount on the expected contract, about a month long and never past three, with the pilot fee credited toward the annual deal if the customer signs.

Luke Sophinos of CourseKey says in the SaaStr roundup that mid-market and enterprise pilots need some dollar commitment or they mostly don't work, and Lemkin agrees that unpaid pilots almost never do, while admitting he once closed Google after a year-long unpaid one because the customer genuinely put resources behind it.

Even the pro-paid piece has a counterexample. The CEO of ResiQuant says in it that free proofs of concept were the right call early, to validate fit with design partners, and paid ones came once the company needed a repeatable motion.

For a solo founder, nobody is signing an enterprise pilot for your $19 tool. My translation: a paid beta, a founding-member price, or a pre-order with clear refund terms and honest notes on what's built. Also, B2B and free aren't opposites.

In Lenny's data the free tier was often for individual users, while founders sold to the buying organization directly, and founder-led sales was how most of those companies got going. The user can be free while the organization pays.

Consumer and network products

YC's exception is ad-supported consumer businesses that need a giant base. They also warn about hiding behind it. Airbnb could have called itself a social network for travel and skipped payments, the way Couchsurfing did, and instead worked out how money would move. If you go free for scale, be honest that you've chosen to build a different kind of company.

Open source

The code can be free while the business isn't. YC points to GitLab's open-core model. Plausible publishes all its code and lets people self-host, and sells a hosted version with a 30-day trial. Its own numbers: about six months of donations produced six gifts of $5, while the paid cloud product grew from $400 to more than $8,500 in monthly revenue. Its conclusion is that a managed service on top of open code seems a better model than donations for some projects.

It also shows price as positioning. Plausible kept prices affordable because Google Analytics is free and people weren't used to paying for analytics. Vohra priced Superhuman toward the top of its bracket to signal quality, and says positioning should come before pricing. Both charged. They just said different things with the number.

The menu is bigger than two options

Option	What it can test	What it can't	Seen in this article
Free forever, no plan	Reach and curiosity	Willingness to pay	YC's ad-supported exception
Freemium (limit plus paid tier)	Spread, and which limit people hit	Whether free users would pay for the same thing	Slack, Evernote, Basecamp
Free trial	Whether value shows up before the clock runs out	Long-term use	Plausible's 30-day trial
Free beta, then paid	Rough edges and early demand	Price reaction, until you charge	Plausible, Figma
Paid from the first user	Price reaction, honest conversations	Breadth of exposure	Superhuman, True Link
Paid pilot / founding-member price	Commitment from specific buyers	Whether strangers will self-serve	Pear VC's formula

(That table is my summary, not a taxonomy from any one source.) Plausible's 30-day trial with no card needed is worth a note. It reports a 33.5% trial-to-paid rate for its April and May 2020 cohorts, a period when a viral post was sending it a lot of highly interested visitors. One product, one niche, one moment. Don't copy the number. Do notice that a trial asks for a decision on a clock.

How to decide: a scorecard 📋

This is a framework I put together for this article. It isn't an established model, and there are no universal thresholds.

Question	Leans toward charging early	Leans toward free, with a plan
What's your biggest unknown?	Will anyone pay?	Will it work, or will it spread?
Who pays?	A company or professional you can name and reach	Individual users now, an organization later
Does use create exposure?	No: invites, shares and public pages don't exist	Yes: using it shows it to others
What does a free user cost?	Support time or API calls you can't ignore	Close to nothing
How fast does a stranger get value?	Needs setup or hand-holding	Minutes, no help (per the SaaStr point above)
How big is the audience?	A small niche you can list	Large enough that a few percent is real money
Is the product dependable today?	Yes, it earns a price	Not yet: free beta, with a date
Do you have a plan for free?	Not applicable	A limit, a metric and a deadline written down

Signs it's time to charge:

People ask to pay (Figma's customers did).
Free users keep hitting your limit.
The same people return.
You've onboarded a few without hand-holding.
The free tier costs more than you expected.
The buyer needs an invoice and some evidence you'll still exist next year.

Signs to stay free for now:

Nobody has reached the core value yet.
The product breaks often.
You can't say what a paid plan would include.
Exposure is your bottleneck and the product spreads through use.
You haven't built billing yet. Segment waited about nine months for that.

Whichever you pick, put a date on it.

Two invented examples of the scorecard at work

Two invented examples to show the scorecard at work. A solo developer builds a $12/month browser extension that costs $0.30 per active user per month in API calls, used by individuals who never invite anyone. Most rows lean toward charging, so a short trial and a price from the start beat a free tier. Now a design tool where every shared link shows the product to a teammate and a free user costs almost nothing. That one leans toward a free plan with a limit, a conversion metric and a review date.

Two weeks of testing before you commit 🧪

Put a real price on the page. A real checkout or payment link, with honest wording about what exists and what doesn't. (A pricing-page click without a payment is weak evidence, as Article 2 noted.)
Show it to strangers who already have the problem, not friends. People who described the problem publicly or in conversation count. Compliments don't.
Ask five of them for a specific commitment: a paid pilot, a founding-member price, or a pre-order with refund terms.
Run the four-question price survey on everyone else. It's called the Van Westendorp survey. Both Segment and Superhuman used it. The questions:

- At what price would this be so expensive you wouldn't buy it?
- So cheap you'd doubt its quality?
- Expensive, but you'd still consider it?
- A bargain?

Vohra's caution is not to stare only at the bargain number. Positioning comes first.

Before you start, write down what result would change your mind. If nothing would, you're not testing, you're decorating.

Mistakes to avoid when pricing shows up 🙈

Staying free out of fear. The YC partners' worry is founders who avoid charging because they dread the reaction, or because they think there are no redos. There are redos.

Free "for now" with no date or metric. "We'll see how it goes" isn't a plan. A limit, a conversion number and a review date are.

Counting a logo as a customer. A famous name using your free pilot is a conversation, not revenue.

Judging a pricing change on too short a window. Basecamp's six-month test looked right. The cost showed up over years. Decide in advance how long you'll watch, and which numbers matter beyond this quarter.

Treating a payment as proof of fit. Someone paying you tells you the offer landed. Whether they'd miss the product is a separate question, and Article 3's survey is one way to ask it.

Surprising existing users. If you change pricing, grandfather the people who trusted you early. YC points out that early users on old plans barely matter to your future bottom line, and being generous to them costs very little.

So, should you charge from day one?

Mostly, ask for something sooner than feels comfortable, but not for the reason the slogans give.

If you can name a buyer and reach them, charge before you build more. It can be small. A paid pilot, a founding-member price or a trial with a card on file all count, because they give you the one thing a signup can't: a real reaction to a real number.

If the product spreads through use, costs almost nothing per free user, and you have a limit, a metric and a date for the free tier, free can be the right call. Slack, Figma and Basecamp are all evidence for that. They're also evidence that free has to be doing a job, and that the job changes as the company does.

If you can't say which of those two situations you're in, that's the thing to find out first. Neither choice proves product-market fit. A payment proves someone valued this offer at this price. Usage proves someone came back. Fit shows up in whether they'd miss it.

And if you pick wrong? That's allowed. You can change a price. Just be honest with people when you do, and be kind to the ones who showed up early.

Over to you: if you've done it both ways, free first then charging, or charging from the start, what changed about who wrote to you and what they asked for? The failures are usually the most useful ones. Tell me in the comments 👇

Earlier in this series

Unpacks four distinct tactics behind the hype

Hanzla Baig for The Startup Café

Oct 22

"Build in Public" Is Everywhere. Does It Actually Get You Customers? 🤔

#ai #webdev #programming #productivity

9 min read

Buffer and Figma case studies compared

Hanzla Baig for The Startup Café

Oct 25

Should You Build an MVP Before Your First Customer?

#discuss #webdev #programming #startup

9 min read

Real builders share how they survived zero traffic

Hanzla Baig for The Startup Café

Oct 26

Getting Your First 10 Users Is Harder Than Building the Product (Or Is It?)

#discuss #career #webdev #javascript

14 min read

Hanzla Baig for The Startup Café

Nov 2

Product Hunt Launches Look Impressive. But Do They Bring Paying Customers?

#discuss #programming #startup #productivity

16 min read

Follow The Startup Café for the next article

The Startup Café: Real Startup Lessons. Beyond the Hype.

A Phantomatic Nightshift — Version 4 Fixes & Updates

MT Indie Dev — Fri, 06 Nov 2026 04:01:33 +0000

Welcome to A Phantomatic Nightshift, where the dead have paperwork and you have a shift to finish.

A short first-person paranormal comedy about bureaucracy, bad decisions, and ghosts who desperately need a hobby.

🆕📢Version 4 Fixes & Updates:

Prevented ghost clutter the Crossing Office by moving the surgeon in the lobby room

Added splash intro

Added CRT material to the Lobby TV

Made the non-quest interactables more visible

Added Crossed names on the Crossing List after each Phantom Pass

Added Lobby Ticket No. incrementation after each Phantom pass

Changed the portal material due to eye comfort

Added intractability to the rules poster. Press E to better see the rules poster

Added Main Menu button functionality in the credits level

Become a Medium member
Subscribe to Pro Writer Tools to remove upgrade prompts from your unlocked stories.

Added on-level Radio Ghost

Enabled VSync to prevent screen tear

🆕📢Version 3 Fixes & Updates:

Camera twitching and sudden rotation

Finished the highlighting system for interactable objects

Changed the menu background

Added a Main Menu button in the credits level

Fixed the prompts appearing after objects are no longer interactable

Changed some wall and ground textures to ones more decent

Fixed several aesthetic bugs

fixed audio lined playing on top of one another

Shortened the Exorcism prayer

Quest Widget fades with the ending fade

https://gamejolt.com/games/a-phantomatic-nightshift/1115136
https://mt-indie-dev.itch.io/a-phantomatic-nightshift

A Phantomatic Nightshift - Game Updates

MT Indie Dev — Wed, 04 Nov 2026 12:08:25 +0000

🆕📢Version 3 Fixes & Updates:

-Camera twitching and sudden rotation
-Finished the highlighting system for interactable objects
-Changed the menu background
-Added a Main Menu button in the credits level
-Fixed the prompts appearing after objects are no longer interactable
-Changed some wall and ground textures to ones more decent
-Fixed several aesthetic bugs
-fixed audio lined playing on top of one another
-Shortened the Exorcism prayer
-Quest Widget fades with the ending fade
-Available on both itch.io and Game Jolt

https://mt-indie-dev.itch.io/a-phantomatic-nightshift
https://gamejolt.com/games/a-phantomatic-nightshift/1115136

Product Hunt Launches Look Impressive. But Do They Bring Paying Customers?

Hanzla Baig — Mon, 02 Nov 2026 17:21:28 +0000

TL;DR

Public founder accounts of Product Hunt launches swing from zero paying customers to hundreds. Anyone quoting you a clean "average conversion rate" is guessing.
The only large dataset I found ties launches to Series A funding, not to revenue, and even that link is modest.
A launch is a one-day discovery channel. It turns into a customer strategy only when you add targeting and follow-up.
Don't judge a launch by its rank. Judge it with a scorecard you write before launch day. There's one at the bottom.

One of the most useful Product Hunt write-ups I've read has no victory lap in it. A founder launched BrandingStudio.ai and finished the day at #6 with 168 upvotes. Four days later he wrote up the aftermath: more than 400 signups, 360 brands created, and $237 in total revenue, all from a single paying customer.

He did the math himself. That's a 0.25 percent conversion rate. His conclusion was refreshingly sober: people were curious enough to try the product, but not sure enough to pay for it.

Most launch screenshots stop at the rank. This one kept going, and the second half is where the interesting stuff is.

So here's the question I want to dig into. Does a Product Hunt launch help startups find paying customers, or does it mostly hand you a day of attention that looks like traction? I can't give you a universal answer, and by the end you'll see why nobody can. What I can do is show what the public evidence supports, where it runs out, and how to judge your own launch by what it did for the business instead of where it landed on a leaderboard.

First, a word on where the numbers come from

I sorted everything I used into four buckets: firsthand founder accounts (self-reported, nobody audited them), third-party compilations, published research, and my own analysis. Hypothetical examples are labeled as hypothetical. And when a company never shared its revenue or customer numbers, I say so instead of filling the gap with a guess.

Keep that in mind as we go. Most of what follows is founders telling their own stories, and founders are human.

Why everyone wants the badge

Product Hunt's own launch guide pitches the site as a place to build momentum and reach your first wave of users. It points at Loom, Cursor and Clubhouse as products that used it as a launch pad. Launches go live at 12:01 AM Pacific on the scheduled day, and the guide says you can launch again when you ship a major update.

And honestly, that's useful for a small team. A launch is a dated, public event with a leaderboard attached. It gives you a deadline, a reason to finish the thing, a link to send around, and a badge for your homepage.

The catch: you can collect every one of those benefits without a single person paying you. That's why I like to keep them in a separate pile from what most founders say they actually want, which is customers.

What the leaderboard is really measuring

Product Hunt doesn't publish its ranking formula. Its CTO has said in a community post that launches are ranked by points rather than raw upvotes, that votes from verified users tend to carry more weight, and that a launch with strong evidence of paid votes gets un-featured. A third-party summary of the help center describes points as a blend of upvotes and meaningful engagement, and says the official advice is not to ask people outright for upvotes.

The homepage is curated by humans. According to the featuring guidelines as summarized by Syften, editors look for live products that are useful, novel, well made or creative. Some formats, like waitlist-only launches, lists, templates and courses, don't get featured on the homepage. These rules change, so read the current versions before you plan around them.

Here's my own reading of all this, and it's an opinion, not a fact from any source. A rank measures how many of the right accounts engaged with your launch during one day, compared with everyone else who launched that day. Product appeal matters. So do your existing network, your timing and your competition. None of those is the same thing as someone wanting to buy.

There's also the price of getting there. In a small roundup of May 2026 launches, the three founders who reported prep time put it at roughly 40 to 65 hours, and a few said they were awake for 20 to 24 hours on launch day. One of them warned that asking friends and family to vote can backfire, because a lot of them don't have accounts, and freshly created ones may not count.

To be clear, nothing in these accounts shows founders neglecting their product to chase votes, and I'm not accusing anyone of gaming anything. The narrower point is just that a launch eats a lot of hours, and every hour spent rounding up supporters is an hour you're not spending talking to potential customers.

What founders actually report

The public record is a scattering of self-reported stories. Here are the ones I found, with the source type noted, because it matters.

Launch	What the founder reported	Source type
BrandingStudio.ai	#6 of the day, 168 upvotes. After four days: 400+ signups, 360 brands created, 1 paying customer, $237 revenue	Founder post, Indie Hackers
Roly AI	#13, 110 upvotes. After three days: 323 site visitors, 26 signups, 0 paying customers	Founder post, Product Hunt forum
Website Rooms	Fewer than 20 upvotes, a few signups, 0 paid users	Founder newsletter
Buttondown	Front page of Product Hunt and Hacker News. About 30,000 unique visitors, about 500 registered users, maybe 10 paying customers	Founder interview, Starter Story
Stock Market GPT	69 upvotes, 4 sales (revenue not stated)	Founder post, Indie Hackers
gptengineer.app	500k+ impressions, 16k signups, 850 paying users (5 percent), from launches plus Hacker News and Twitter posts	Founder write-up, Product Hunt
Reply.io	About 10,000 visitors in two days, 600 signups, about 60 paying customers	Founder statement compiled by Founderpath (secondary)

Read them side by side and a few things jump out.

The range is huge. The same platform gave some founders zero paying customers and another one hundreds. The products, prices, audiences and surrounding effort are so different that the platform can't be the main explanation. That's the first honest conclusion I can offer: Product Hunt is a venue, and venues don't produce uniform results.

The funnel ratios are all over the place. From the figures above, Buttondown's founder saw roughly 1.7 percent of unique visitors become registered users (500 of 30,000), and about 2 percent of those become paying customers. Roly AI saw about 8 percent of visitors sign up (26 of 323). Reply.io's numbers work out to around 6 percent of visitors signing up and 10 percent of signups paying, while gptengineer reports 5 percent of signups paying.

But the products, prices and even the definition of "signup" differ, so none of these is a benchmark. The spread itself is the lesson. If you see a confident "average Product Hunt conversion rate" somewhere, ask where it came from.

The spike fades fast. Roly AI's founder logged 229 visitors on day one (68 of them from Product Hunt), 64 on day two (20 from Product Hunt), and 33 on day three (none from Product Hunt). That's one small product with no existing audience, but it lines up with how Buttondown's founder is described in the Founderpath compilation, which mentions a very prominent spike in the signup graph.

The good outcomes are real, and they're messier than the rank. gptengineer has the best numbers in the table. But the write-up says the launch only went from flailing to successful after some mid-day decisions: dropping the waitlist, posting on Hacker News, and shortening the launch post for Twitter. The founder also says the user interviews after launch were the most valuable part. Founderpath's compilation lists several other founders who credit a launch for their first customers.

Did the launch cause those customers, or did it just happen to coincide with founders who were doing a lot of other things right? None of these accounts can settle that.

The sample is biased both ways. Founders publish their best and their worst results, and compilations with titles like "29 strategies" lean toward success stories. Nobody has sampled all launches, so the share of launches that end in revenue is simply unknown. If someone hands you that number with a straight face, they're quoting a tiny sample or making it up.

One more data point deserves its own paragraph. In that May 2026 roundup, a software vendor asked five founders the same questions and published results for four of them. It's self-reported, tiny, and the author calls the figures directional. Still, all four launches finished in the top six that day. The highest-ranked one reported 0 percent paid conversion so far (usage-based pricing, early days), while a launch in the middle of the pack reported around 20 percent of signups paying.

That founder's explanation was about the audience. The product serves founders who are actively raising money, and they tend to convert 7 to 10 days after signing up. Four launches prove nothing statistically. But they show how a rank and a revenue number can drift apart, and why the window you measure over matters.

The one big dataset, and what it can't tell you

The only large-scale analysis I found that links Product Hunt launches to a business outcome is about funding, not sales. A preprint (not peer reviewed, as far as I can tell) matched 67,292 featured launches from 2019 to 2025 against Crunchbase records. It found 528 that announced a Series A within 18 months, which is 0.78 percent. Launches that did tended to have more upvotes, better daily ranks, bigger maker teams and B2B topics. A #1 daily rank went with a 2.22 percent rate, compared with 0.51 percent for launches ranked 11th or lower.

So rank does carry a little information about later funding. But four limits stop me from turning that into advice.

Funding isn't revenue. The paper says nothing about paying customers.
It's an association. The authors' own reading is that the strongest signals combine team size with votes, which hints that the launch mostly records how well-connected a team already was. My take is that a launch may reflect strength more than it creates it, though the data can't separate the two.
Crunchbase covers US, institutionally backed companies better than bootstrapped or international ones. So the dataset is thinnest exactly where a lot of indie founders live.
The predictive power is modest. The authors' best model, tested on held-out data, was about 4.7 times better than chance on a base rate under 1 percent. That still leaves most of its picks wrong.

"The launch went well" is hiding a whole funnel

When a founder says the launch went well, they usually mean something from the very top of a long chain. It helps to name every link, because each one breaks for a different reason.

Stage	The question it answers	Where you see it
Impressions and visibility	Did people see the listing?	Product Hunt page, impressions
Visitors	Did they click through?	Your analytics
Signups	Did anyone raise a hand?	Your database
Activated users	Did they reach a first useful result?	Product events
Returning users	Did they come back?	Day 7 and day 30 cohorts
Free-to-paid conversion	Did someone decide it was worth money?	Billing
Paying customers	Who, and at what price?	Billing and CRM
Retained, profitable customers	Do they stay, and do they cost less to serve than they pay?	Cohort revenue against cost

Upvotes live outside this chain entirely. They're a social signal about the listing, and they can go up while nothing downstream moves.

BrandingStudio is a good example of why the stages matter. By the founder's own count, nearly every signup went on to create a brand, so activation was strong. Payment is where the chain snapped. His diagnosis was a gap between "this looks useful" and "I know exactly what to do next." That's a pricing and offer problem, not a traffic problem.

A founder who only watched signups would have thrown a party. A founder who only watched revenue wouldn't have known where to look. The stage where people drop out tells you what to fix.

Why launches sometimes don't turn into customers

These reasons come from individual accounts plus my own analysis, and none of them applies to every product.

Curiosity can outnumber intent. People on Product Hunt are browsing a feed of new things. If your product is something people only need when a specific problem hits, browsers may sign up and drift off, or convert days later like the founder in the roundup described. I couldn't find any public data on what share of Product Hunt visitors match a particular buyer profile, so test it yourself: compare your signups against the customer you described before launch.

The audience you bring can matter more than the platform. In the roundup, signup counts ranged from 71 to roughly 450, and the highest figure bundled Product Hunt together with LinkedIn activity the founder had built around the launch. The founders pointed to owned audiences, like email lists and networks, as the thing they'd keep. If you have none, a launch has less to amplify.

Value that takes effort to see. If your product needs setup before it shows its worth, launch-day visitors may leave before they find out. If it works inside a minute, a high-traffic day suits it much better.

Distribution as an afterthought. The Website Rooms founder wrote that he spent three weeks building and one day preparing distribution, and decided he'd fallen into the trap of treating "distribution" as "launch on Product Hunt and Hacker News." That's a planning lesson. It says nothing bad about the platform.

No follow-up. A day-three traffic number near zero is normal. What you can still recover are the people who signed up. The founders who reported real value, like gptengineer's, point to conversations after launch day.

Two made-up startups, to make this concrete

Startup A and Startup B below are invented for illustration. Their numbers aren't benchmarks and don't describe any real company.

Startup A sells a general productivity tool at $12 a month. It finishes second for the day with 1,100 upvotes. Nine thousand people visit, 700 sign up, 85 reach the first useful result, and 6 start paying. By day 60, two of the six have cancelled, which leaves $48 in monthly revenue. The founder's follow-up emails to the people who never activated get almost no replies, because most of them were just curious and never had the problem the product solves.

Startup B sells a $49 monthly tool for one narrow job: reconciling payouts for small online shops. It finishes ninth with 90 upvotes. Six hundred people visit, 45 sign up, and 20 reach the first useful result (the signup form asked which platform they use, and onboarding was built around the answer). Five start paying. At day 60, four are still around, which is $196 a month. The founder has also talked to a dozen shop owners and knows three features they'd pay for.

On the leaderboard, A wins by a mile. On revenue, retention and learning, B is ahead, and B's next ten customers will probably look a lot like its first five.

This isn't a rule that small launches beat big ones. If A tightened its positioning and fixed onboarding, its bigger funnel could easily overtake B. The point is that the leaderboard can't tell you which situation you're in. Only the later stages of the funnel can.

Where Product Hunt genuinely helps

Several benefits show up across the accounts above, and they deserve to be taken seriously.

First stranger traffic. Roly AI launched with no social media presence and still got 68 visits from the site on day one. It's modest, but it's more than zero, and zero is where most products start.
Feedback and positioning lessons. gptengineer's founder valued the post-launch interviews most. The Stock Market GPT founder reports making four sales and learning more about what customers wanted.
Early adopters. Buttondown's founder reported around ten paying customers from a launch that, by his own description, wasn't meteoric. For an early product, that first handful can be exactly what's needed.
Conversations. In the May 2026 roundup, two of five founders reported unprompted investor interest, and another reactivated some cold leads.
Second chances. The official guide encourages launching again when you ship something significant, so a quiet first launch doesn't close the door.

The distinction I keep coming back to is discovery channel versus customer acquisition strategy. A discovery channel puts your product in front of people for a day. A strategy includes who you're trying to reach, what you want them to do, how you'll follow up, and what happens next. Product Hunt can be the first. It doesn't hand you the second.

When a launch probably isn't your next move

A launch tends to be the wrong step in a few situations:

Nobody has told you they'd pay. A launch won't fix that, and visitors who politely click around can hide it. Talk to ten people who have the problem first.
Your buyers are a short list you can name. Think heads of operations at regional logistics firms. Direct outreach will teach you more per hour than a public leaderboard.
The product can't be tried today. The featuring guidelines I mentioned earlier leave waitlist-only launches off the homepage, so you'd be preparing for a launch that can't get its best exposure.
You have no way to follow up. Launch traffic evaporates. The only durable thing you keep is whatever you captured: an email, a conversation, a note about what someone tried to do.
The real bottleneck is something else. If it's pricing, onboarding or positioning, extra traffic just makes the problem more expensive to observe.

What to try instead, or alongside

None of this replaces Product Hunt in general. Each option wins under particular conditions, and this whole section is my analysis, not research.

Direct outreach makes sense when you can name your buyers and find them. A founder selling to small accounting firms can email fifty of them this week, and each reply will probably teach more than a hundred upvotes. Relevant communities work when you already take part in them, and they flop when you only show up to announce something. Founder-led content suits products with a point of view and compounds slowly. Search-intent content fits problems people already google, but its slow payoff makes it a poor stand-in if you need a signal this month. Partnerships make sense when another product's users hit your problem right after using theirs. Referrals need customers first, which is a good reason to find your first ones another way.

Whichever you pick, run it as a small experiment: one channel, a time limit, one number to beat.

A scorecard for deciding whether your launch worked

This is a framework I put together for this article. It isn't an established model, and it has no universal thresholds. Every target in it is yours, and you set it before launch day.

Before launch

Is the product ready for real users? A stranger should be able to sign up and reach a first useful result without your help. Watch three people you don't know try it. Make the price visible.
Who exactly should find it? Write the buyer in one sentence: role, situation, the problem in their words. Then ask whether those people actually browse Product Hunt. If you can't answer, that's a finding.
What specific outcome do you want? Pick one primary outcome and put a number on it, like ten activated users who match your buyer profile, five booked customer conversations, or three paying customers. Upvotes can be a side note.
How will you measure beyond upvotes? Define the activation event (the first useful thing a user does), tag Product Hunt traffic with its own source parameter, and record your baseline.
Can you follow up? Have a welcome email ready, a way to reach people who didn't activate, and a link for booking a call.

During the launch

What to track: visitors by source, signups, activation events, and the questions people ask. Sort comments into use questions, objections, feature requests and plain praise.
How to collect feedback: answer every comment, and add one open question to the signup or welcome email, like what the person hoped to do.
Real interest or casual curiosity? Look for signups who match your buyer profile, activate within a day, reply to your welcome email, or ask about pricing. Curiosity tends to leave no trace after the click.
Learning from people who don't sign up: check where they leave, how many viewed pricing, and, if you have the tools, watch session recordings. A short on-site question can explain a lot.

After the launch

At day 7, fill in the scorecard below with your real numbers, then reach out to every activated user and every high-fit signup who didn't activate. At day 30, check who came back, who paid, which conversations are still alive, and how many hours the whole thing cost you.

Measure	What to record	Your target	Day 7	Day 30
Fit	Share of signups matching your buyer profile
Activation	Share reaching the first useful result
Return	Users active again after a week, after a month
Revenue signal	Paying customers, plus qualified conversations
Learning	Feedback that changed a decision
Cost	Hours spent on prep, launch day and follow-up

Then read the card by where it breaks:

Low fit means you attracted the wrong audience. Change who you aim at before you touch the product.
Good fit but low activation points at onboarding or positioning.
Good activation but little return points at value.
Return without payment points at pricing or the offer. That was the BrandingStudio pattern.
Fit, activation and return all healthy but volume small? Distribution is your constraint, and relaunching with a meaningful update is a reasonable experiment.

What would justify spending more time on this channel? Your own pre-written targets getting met, with customers or serious conversations coming from people who match your buyer profile. A few paying users who fit and stay beat a giant pile of signups that never activate. And if the evidence isn't there, the next month is better spent talking to customers directly.

The decision underneath all of this

A leaderboard position is a fact about one day. A customer is a fact about your business. Product Hunt can help with the first and sometimes contributes to the second, and the evidence we have doesn't say how often.

What it does say is that a launch is a way to get attention, and a startup survives on what happens to that attention afterward.

So treat your launch as an experiment. Write down who you want to reach, what you want them to do, and what result would make you do it again. Then judge it by those answers, not by the badge.

I'd love to hear real numbers in the comments. If you've launched on Product Hunt, what did your day-7 and day-30 picture look like compared with your launch-day rank? Failures count too, and they're usually the more useful ones.

The Startup Café: Real Startup Lessons. Beyond the Hype.

The Startup Café Follow

A community for startup founders, indie hackers, and developers to share projects, get feedback, find co-founders, and grow together. Grab a coffee and let's build something great!

Hanzla BaigFollow

👨‍💻 I turn coffee-free ideas into bugs 🐛 🚀 Co-founder @ TheBitForge ✍️ Sharing dev adventures, wins & fails 🇵🇰 Building, breaking & learning daily 😅

TheBitForgeFollow

Founder @thebitforge.dev • Software & AI Product Agency • 181K+ readers & 7K+ followers • We turn ideas into digital products people 💙 to use | visit us also on insta @thebitforge.dev

A Phantomatic Nightshift

MT Indie Dev — Sat, 31 Oct 2026 22:42:44 +0000

The dead have paperwork. You have a night shift to survive.

A Phantomatic Nightshift is a short first-person paranormal comedy set in the Romanian Bureau of Phantomatic Crossing. Help peaceful ghosts reach purgatory while dealing with possessed office equipment, mischievous spirits, and a growing suspicion that declining professional backup was a terrible idea.

It’s a night of bureaucracy, supernatural nonsense, and ghosts who clearly haven’t read the office rules.

👻 Play it on Windows: https://mt-indie-dev.itch.io/a-phantomatic-nightshift

DEV.to Organizations: You Can Now Pin Up to 5 Posts to Your Profile!

Hanzla Baig — Sat, 31 Oct 2026 14:16:34 +0000

Did you know you can pin up to 5 posts on your DEV.to Organization profile?

If you run a company, startup, open-source project, or developer community on DEV.to, this feature can help you highlight the content you want visitors to see first.

Instead of letting important posts get buried under newer publications, you can keep them visible in a dedicated Pinned section above your regular organization feed.

What can you pin?

Your organization's introduction or welcome post.
Important announcements and updates.
Your best technical articles and tutorials.
Product launches and project updates.
Useful resources for your community.

How to pin a post

Open your DEV.to dashboard.
Find a post published under your organization.
Open its Manage page.
Look for the Pin to Organization option.
Click it!

That's it. Your post will appear in the Pinned section on your organization's profile.

You can pin up to 5 posts and unpin them whenever you want.

If you manage a DEV.to Organization, give this feature a try!

DEV Community: The Startup Café

When a Company Becomes Too Dependent on One Person

The problem with making a CEO bigger than the company

The internet's reaction says something about us, too

Where was the board?

The real lesson is bigger than Jensen Huang

Questions worth discussing

Your Startup Doesn't Need Everyone. It Needs the Right Niche

What "everyone" costs you

What PayPal and Facebook actually had

The niche that wasn't enough

Four checks before you commit

Finding the group, and testing it before you build

When to stay narrow and when to widen

So

PB&J: The Story of the Three People Behind DEV

Let me tell you a story about a sandwich 🥪

The rules I am following

Who is who (so you do not get lost)

Table of Contents

Chapter 1: A guy with a second Twitter account 🐦

Where does the Twitter account come in?

When did this start?

Chapter 2: The business partner who started young

Texts.com and then Ben

The "least technical" co-founder

Chapter 3: The person who did not know what a startup was

Loneliness is the origin story

So now we have three

Chapter 4: From a joke account to an actual website

The first article was an interview with DHH

The login button nobody could find

The worry that almost stopped it

How big was it, at the very start?

Chapter 5: The decision, and the date that cannot be right 🕵️

Wait. January 2016?

A coincidence I cannot explain

Chapter 6: The year everything grew 17 times

What the team shipped that year

How the team ran in those days

The monthly report, as a habit

Chapter 7: The day the code went public 🔓

"A starting line"

forem / forem

For empowering community 🌱

Forem 🌱

What is Forem?

Ben's one regret

Did anyone actually contribute?

Chapter 8: Money arrives, and the office disappears

Friends and family, then about $950,000

The $11.5 million round

Who controls what?

How DEV said it would make money

The office that went away

Chapter 9: DEV gets a big sibling called Forem 🌍

Self-hosting

What a "Forem" looked like in practice

The one sentence that clears this up

Interlude: how DEV actually felt to run

The community was the point

Moderation, in their own words

Not everyone is a fan

Who does what, in plain English

Chapter 10: February 18, 2026 🚀

What the companies confirmed

The community's first reaction

How Jess described it

Where the three are now

Ben HalpernFollow

Jess LeeFollow

Peter Kim FrankFollow

Epilogue: the ten-year promise

What the story shows

The timeline, on one page

Your turn 🙂

Let's Talk About Ideas! 💡 — Share Your Startup Ideas, Products & Experiments

What can you share?

Have a product ready for testing?

Let's get the discussion started!