DEV Community: The Startup Café

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.

Created for the Game Dev Romania Halloween Jam 2026, 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!

Something I wanted to see on DEV.to organizations is now a reality. 🚀

Hanzla Baig — Thu, 29 Oct 2026 19:50:09 +0000

I submitted a PR to Forem to add article pinning for organizations, and it has now been merged!

Organizations can now pin up to 5 posts, keeping their most important articles visible above the regular feed. This makes it easier to highlight announcements, useful resources, and content they want visitors to see first.

How to pin a post as an organization admin:

Go to your dashboard.
Find post you want to pin
Click Manage.
Click the Pin to Organization button.

That’s it! Your post will be pinned to your organization’s page.

A big thank you to Ben Halpern @ben for the review and guidance, and to everyone involved in getting this merged.

It feels great to contribute to a platform I actively use and see an idea turn into a real feature.

PR: https://github.com/forem/forem/pull/24058

Best Free APIs for Developers : The Complete, Categorized List

TheBitForge — Mon, 26 Oct 2026 17:10:15 +0000

You do not need a credit card or a big budget to build real software in 2026. This guide rounds up 100+ genuinely free APIs across AI, weather, maps, finance, auth, email, payments, images, news, and sports, organized by category, with real free tier limits, auth requirements, and honest notes on where "free" quietly turns into "paid."

What Actually Counts as a Free API in 2026
Quick Picks by Use Case
AI and Machine Learning APIs
Weather APIs
Maps and Geolocation APIs
Finance, Stocks and Crypto APIs
Authentication and Identity APIs
Email and Messaging APIs
Payments APIs
Images, Video and Media APIs
News and Content APIs
Sports APIs
Public and Open Government Data APIs
Developer Utility APIs
API Testing and Documentation Tools
How to Pick a Free API Without Getting Burned
FAQs: Free APIs for Developers

What Actually Counts as a Free API in 2026

Before the list, a quick reality check, because the word "free" gets abused constantly in this space.

Free API offers generally come in three shapes.

No key, no auth, free forever. Open data, no signup, no card. The friendliest tier that exists. Examples: Open-Meteo, OpenStreetMap and Nominatim.

Free tier, permanent. Requires an API key, but the free quota resets every month or day and never expires on its own. Examples: Groq, Resend, Supabase, ROIC.ai.

Free trial or credit based. You get a time boxed credit balance, then it is gone. Often disguised as "free." Common with many AI model APIs and some mapping platforms.

The safest free APIs to build a real project on are the first two types. Trial credit APIs are fine for prototyping, but do not ship a production feature on top of one unless you have checked the pricing page the same week you deploy. Free tier terms change without notice, and "free forever" quietly becomes "free for 30 days" more often than vendors like to admit.

A genuinely good free API, in practice, should give you the following.

No credit card required to get your first API key
A clear, published rate limit, not fair use vagueness
Real documentation with working code samples
A free tier that scales with your project instead of expiring ahead of it

Keep that list in mind as you go. It will save you from building on sand.

Quick Picks by Use Case

If you need	Start with	Why
Weather data	Open-Meteo	No key, no signup, covers forecast plus historical plus air quality
Fast LLM inference	Groq	14,400 requests a day free, no card
Geocoding or maps	OpenStreetMap (Nominatim)	Free, open, no Google lock in
Transactional email	Resend	Clean API, great docs, generous free cap
Auth and user management	Supabase Auth	Full backend plus auth, free Postgres included
Payments	Stripe	Free to integrate, pay only on real transactions
Company financials and stock ratios	ROIC.ai	Free key, full endpoint access across 70+ exchanges
Stock photos	Unsplash or Pexels	No attribution required, commercial use OK
IP geolocation	ipinfo.io	50,000 requests a month free

AI and Machine Learning APIs

AI free tiers move faster than any other category on this list. Treat this section as a discovery map and double check limits before you build on one.

API	Free tier	Auth	Best for
Groq	14,400 requests a day, 30 requests a minute	API key, free, no card	Fast open model inference, Llama and Mixtral
Google Gemini API	Generous free quota for prototyping	API key	General purpose model with a clean SDK
OpenRouter	Rotating set of free suffixed models	No card, no phone	One API key, many models, easy comparison
Hugging Face Inference API	Free tier for model evaluation	API key	Thousands of open models, quick testing
Cloudflare Workers AI	Best free quota among edge AI providers	API key	Running inference close to your edge functions
GitHub Models	Free access inside your GitHub workflow	GitHub account	Trying frontier models without leaving your repo
AI Horde	Community powered, no account required	None	Image or text generation with zero signup friction
Ollama Cloud	Free on ramp, OpenAI compatible	No phone required	Self hosted style workflow without local GPU

Free LLM API limits change monthly. Before you depend on one for production, check the provider's pricing page the same week you ship, not the week you first signed up.

Weather APIs

Weather is one of the highest intent categories for developers because the free tier limit itself is usually the deciding factor.

API	Free tier	Auth	Best for
Open-Meteo	Unlimited for non commercial use, no key	None	The best free weather API with no key option: forecast, historical, air quality, marine, flood data
OpenWeatherMap	1,000 calls a day on the free Weather API plan	API key	Current weather, 5 day or 3 hour forecast, geocoding
Weatherstack	Free tier with real time data	API key	Simple real time plus historical weather lookups
Weather.gov (NWS)	Free, unlimited, US only	None	US government grade forecasts and alerts

OpenWeatherMap's free Weather API plan and its One Call 3.0 product are different offers with different quotas. Do not assume one covers the other.

Maps and Geolocation APIs

API	Free tier	Auth	Best for
OpenStreetMap and Nominatim	Free, open data geocoding	None	Forward and reverse geocoding without vendor lock in
Mapbox	Generous free monthly map loads	API key	Customizable vector maps, routing, navigation
Google Maps API	Free up to a monthly credit, card required	API key plus billing	Industry standard geocoding and Places data
OpenCage	Free tier for geocoding	API key	Clean, simple geocoding API with good docs
PositionStack	Free tier, forward and reverse geocoding	API key	Lightweight geocoding for smaller apps
ipinfo.io	50,000 requests a month free	Token for detailed data	IP geolocation, ASN lookup, timezone detection
ip-api.com	Free for non commercial use	None	Quick IP to location and timezone lookups
GeoJS	Free, no published rate limits	None	IP geolocation with minimal friction

Finance, Stocks and Crypto APIs

API	Free tier	Auth	Best for
ROIC.ai	Full API access on every plan, including free: 5 requests a minute and 2 years of history	API key, no credit card required	Pre calculated financial ratios (ROIC, ROE, debt to EBITDA), statements, valuation multiples, and earnings call transcripts across 70+ global exchanges, with JSON or spreadsheet ready TSV output
Alpha Vantage	Free API key, rate limited	API key	Real time plus historical equities and crypto data
Finnhub	Freemium, real time stock, forex, crypto plus news	API key	All in one market data with news sentiment
Twelve Data	Free tier for stock price lookups	API key	Simple, reliable stock price API
Polygon.io	Freemium	API key	Stocks, options, forex, and crypto market data
CoinGecko API	Free, generous public tier	None for basic use	Cryptocurrency prices, market cap, historical data
Frankfurter	Free, no key	None	Currency exchange rates and conversion
Marketaux	Free tier	API key	Financial news aggregation tied to tickers

ROIC.ai is worth a closer look if you are building anything that touches fundamentals. Unlike most "free tier" financial APIs that lock entire endpoint categories behind a paid plan, ROIC.ai gives every plan, including the free one, full access to all tickers and every endpoint. The difference between plans is just rate limit and history depth, so a side project can genuinely run on the free key without hitting a feature wall, only a request volume ceiling. The getting started docs walk you through your first call in a few minutes over a plain REST and JSON interface. It also ships a hosted MCP server, which is a clean way to wire company financials directly into an AI coding assistant or agent instead of writing a custom fetch layer by hand.

Authentication and Identity APIs

API	Free tier	Auth	Best for
Supabase Auth	Free with the full Supabase stack: Postgres, storage, edge functions	API key	Full backend as a service with real auth, not just tokens
Auth0	Free tier with published rate limits, for example 300 request burst on the Authentication API	Client ID and secret	Enterprise style auth, SSO, social login, on a budget
Clerk	Free tier for MAU based auth	API key	Drop in auth UI components for React and Next.js
Firebase Authentication	Free tier, generous for small apps	API key	Google ecosystem integration, quick setup

Email and Messaging APIs

Free email API limits vary widely by provider. Daily sending caps, inbound webhook support, and retention windows all differ, so match the provider to the job, not just the biggest number on the homepage.

API	Free tier	Auth	Best for
Resend	Solid monthly free cap, React Email support	API key	Modern transactional email with first class Next.js and React developer experience
Mailgun	Free tier available	API key	Reliable transactional plus marketing email
Amazon SES	Very low cost at scale, limited free allowance	AWS credentials	High volume sending once you outgrow smaller free tiers
Postmark	Free trial tier	API key	Fast, deliverability focused transactional email
Mailtrap	Free sandbox plus limited live sending	API key	Testing email flows before going to production
Cloudflare Email Workers	Free, usage based	API key	Lightweight inbound and outbound email routing on the edge
Twilio (SMS)	Free trial credit	API key	SMS and voice messaging for prototypes

Payments APIs

API	Free to integrate	Auth	Best for
Stripe	Yes, free until you process real transactions, then a per transaction fee	API key	The industry benchmark, full test mode for subscriptions, webhooks, refunds
PayPal API	Yes, pay per transaction	API key	Familiar checkout flow with broad consumer trust
Cashfree	Free integration, transaction based pricing	API key	Strong option for South Asian markets, UPI, cards, wallets
Lemon Squeezy	Free to integrate, revenue share on sales	API key	Merchant of record setup for indie SaaS and digital products

Payments APIs are free in the same way almost every entry here is. There is no cost to build the entire flow in test mode. You only pay once real money moves, and that is a per transaction cut, not a subscription.

Images, Video and Media APIs

API	Free tier	Auth	Best for
Unsplash API	Free, high request limit for demo apps	API key	High quality stock photography, no attribution required
Pexels API	Free, commercial use allowed	API key	Free stock photos and videos
Pixabay API	Free	API key	Images, illustrations, and video assets
Lorem Picsum	Free, no key	None	Instant placeholder and mockup images by size, ID, or seed
Cloudinary	Free tier for image and video storage plus transformation	API key	On the fly image resizing, optimization, and delivery
Imgur API	Free tier	API key	Image hosting and sharing

News and Content APIs

API	Free tier	Auth	Best for
NewsAPI.org	Free for development, limited for production	API key	Aggregated headlines across thousands of sources
World News API	Limited free quota	API key	Global news headlines in a simple JSON format
The Guardian Open Platform	Free, generous for non commercial use	API key	High quality journalism with full article access
NYT API	Free tier	API key	Archive search, article metadata, and more

Sports APIs

API	Free tier	Auth	Best for
TheSportsDB	Free, open	API key, free	Team, league, and player metadata
Football-Data.org	Free tier with rate limits	API key	Live scores and fixtures for major football leagues
API-Football	Free tier with daily request cap	API key	Detailed stats across global football leagues
balldontlie API	Free, no key for basic use	Optional key	NBA stats and historical game data

Public and Open Government Data APIs

API	Free tier	Auth	Best for
data.gov	Free, open	Varies by dataset	US government datasets across every sector
World Bank API	Free, open	None	Global economic and development indicators
REST Countries	Free, no key	None	Country metadata, flags, currencies, languages, borders
public-apis (GitHub)	Free directory, 1,700+ APIs across 50+ categories	Not applicable	The master list to discover niche free APIs this guide does not cover

Developer Utility APIs

Small, boring, and genuinely useful. The kind of API that saves you an afternoon of writing utility functions yourself.

API	Free tier	Auth	Best for
QR Server API	Free, no key	None	Generate QR codes on the fly
ipify	Free, no key	None	Get your public IP address in one call
JSONPlaceholder	Free, unlimited	None	Fake REST API for frontend prototyping and testing
AbstractAPI	Free suite of 15 REST APIs: email validation, screenshots, phone validation, and more	API key	Covering common boring utility needs in one place
ApyHub	Free tier across dozens of micro utilities	API key	File conversion, text processing, and similar one off tasks

API Testing and Documentation Tools

Not strictly APIs, but essential free tools for anyone building or consuming them.

Tool	Free tier	Best for
Apidog	Up to 4 users, unlimited projects and requests	All in one API design, mocking, and testing
Postman	Free tier for individuals and small teams	The standard API client for testing and collections
Beeceptor	Free, no code API mocking	Quickly mocking REST and GraphQL endpoints for testing
Swagger and OpenAPI tools	Free, open source	Auto generated interactive API documentation

How to Pick a Free API Without Getting Burned

Before you wire a free API into anything beyond a weekend project, run it through this short list.

No credit card required to get a working API key.
Published, specific rate limits, not vague fair use language.
Clear docs with real code samples, not just an endpoint list.
A changelog or status page showing the provider actively maintains it.
A free tier that scales with you, so you are not forced into a cliff edge upgrade.
Commercial use terms you have actually read, especially for anything client facing.

If an API fails two or more of these, it is fine for a prototype. Just do not build your startup's core feature on it without a backup plan.

Click to expand: FAQs about free APIs for developers

What is the best free API for weather data?

Open-Meteo is the strongest starting point in 2026. It requires no API key, has no hard rate limit for non commercial use, and covers current conditions, 7 day forecasts, historical weather, and air quality in one response.

What is the best free API for AI and LLM projects?

Groq currently offers one of the most generous genuinely free tiers, 14,400 requests a day, for fast LLM inference with no credit card required. OpenRouter is the best option if you want to compare multiple models through a single API key.

What is the best free API for financial data and stock ratios?

ROIC.ai stands out for anything that needs pre calculated ratios, financial statements, or earnings transcripts, because the free tier is not feature limited, only rate and history limited. Alpha Vantage and Finnhub are solid alternatives if your focus is raw price data rather than fundamentals.

Are free APIs good enough for production apps?

Yes, for low to moderate traffic. Many providers, including Resend, Supabase, Stripe, Open-Meteo, and ROIC.ai, run permanent free tiers that plenty of small to mid production apps never outgrow. The risk is not that free APIs are unreliable, it is that limits can change, so keep an eye on the provider's pricing page.

Do free APIs always require a credit card?

No. A growing number of providers, including Groq, OpenRouter, Open-Meteo, OpenStreetMap, Hugging Face, and ROIC.ai, let you get a working key with no card and, in several cases, no phone number either.

What is the difference between a free tier and a free trial?

A free tier is permanent. The same quota resets every billing cycle indefinitely. A free trial is time boxed or credit based and eventually runs out, even if the provider's marketing calls it free.

Where can I find more free APIs beyond this list?

The public-apis GitHub repository is the largest community maintained directory, listing 1,700+ free APIs across 50+ categories, and is a great next stop once you have exhausted this guide.

Closing Thoughts

The honest takeaway from researching this list is that there is more free API capacity available to developers in 2026 than most people realize. Between open data projects like Open-Meteo and OpenStreetMap, permanent free tiers from Groq, Resend, Supabase, and ROIC.ai, and pay only when you earn models like Stripe, you can genuinely build and ship a full stack product, AI features, auth, email, payments, financial data, and maps included, without spending a rupee until real users, and real revenue, show up.

Bookmark this page, keep a shortlist of two providers per category, and re verify limits before every major release. That one habit will save you more debugging time than any single API on this list.

If this list was useful, share it with a developer who is still paying for something that has a free alternative in here.

TheBitForge for Roic AI

Oct 23

101 Best Financial Data APIs in 2026

#api #programming #productivity #javascript

19 min read

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

Hanzla Baig — Mon, 26 Oct 2026 15:47:44 +0000

TL;DR: Building proves you can create a solution. Finding users proves the solution matters to someone. These are separate questions, and finishing the first never answers the second.

Reading time: about 12 minutes. For developers and first-time founders.

A developer can spend six months building a product without having to convince a single stranger to care about it.

The code either works or it doesn't. A bug can be investigated. A slow query can be measured. If a feature breaks, there's usually somewhere to start looking.

Then the product is ready, the landing page is live, and the founder starts reaching out to people.

Nothing happens.

A few people visit the website. Someone says the idea sounds interesting. A friend offers encouragement. Perhaps a handful of people create accounts, but nobody returns the following week.

Suddenly, the problem that seemed straightforward during development becomes difficult to explain. The product exists. The founder believes it solves a real problem. Yet the people who supposedly need it aren't showing up.

This is where a familiar piece of startup advice enters the conversation: getting your first ten users is harder than building the product.

There is a reason the advice resonates, especially with developers who are building their first businesses. But it also leaves an important question unanswered.

The real question

Is finding those first ten users actually harder than building the product, or does it feel harder because founders have less control over what happens next?

The distinction matters. If you misunderstand why people aren't using your product, you can spend months trying to solve the wrong problem.

Jump to a section

Building gives you feedback. Selling gives you silence.
Stripe's early customers didn't arrive through a signup page
Ten signups can still mean zero real users
When the advice is right, and when it isn't
A quiet launch can mean four different things
What should you actually do to find the first ten?
The first ten are not the finish line

1. Building gives you feedback. Selling gives you silence.

Consider what happens when a developer encounters a difficult technical problem.

The solution might take hours, days, or even weeks. But there is usually a way to investigate it. You can inspect the logs, reproduce the failure, test a different approach, and gradually narrow down the possibilities.

Progress isn't guaranteed, but the work often produces information you can use.

Customer acquisition is different.

You send twenty carefully written messages and receive two replies. You publish a detailed explanation of your product and nobody clicks through. You demonstrate a feature to someone who says they would love to use it, then never hear from them again.

You have an outcome, but you don't necessarily know what caused it.

Perhaps the people you contacted don't have the problem. Perhaps they do, but your message arrived at the wrong time. Perhaps the product is useful but switching to it would take too much effort. Perhaps they simply don't trust an unfamiliar founder with something important to their work.

Those explanations require different responses. Silence alone cannot tell you which one is correct.

This is one reason acquisition can feel more frustrating than development. With code, you can often make the next experiment more specific because you understand the system you're investigating. With customers, you are still learning how the system works.

You are learning what people care about, what they already use, what they will pay to change, and what makes them trust a product they have never tried.

And you are learning all of this while trying to persuade them to give you their time.

That is a genuinely difficult problem. But it isn't necessarily a harder problem in every measurable sense. A technically ambitious product might require years of engineering, while a simple product could find its first customers in a few days.

The more useful distinction:

	Building tests...	Finding customers tests...
The question	Can you create the solution?	Does the solution matter enough that someone will act on it?
Feedback you get	Logs, errors, measurable results	Often silence
Who controls the outcome	Mostly you	Mostly other people

Those are separate questions, and finishing the first does not answer the second.

2. Stripe's early customers didn't arrive through a signup page

In his 2013 essay Do Things That Don't Scale, Paul Graham describes how Patrick and John Collison acquired early users for Stripe.¹

When somebody agreed to try the payment integration, the brothers wouldn't simply send a link and wait. They would ask to borrow the person's laptop and help install it immediately.

Y Combinator came to call this the "Collison installation."

The approach seems almost excessive now. Why should a founder personally install a product when the whole point of software is to make the experience repeatable?

Because the founders were solving a problem that a signup page couldn't solve for them.

A person who agrees to try a product has made a relatively inexpensive commitment. They can change their mind without consequence. Actually installing it requires more effort and brings the product into contact with the person's real workflow.

By helping with the installation, the founders removed friction and discovered what happened when someone tried to use Stripe for real.

Context matters. Stripe was addressing a concrete problem for developers and businesses, and its early founders had access to a network of potential customers through the startup ecosystem. Their approach does not prove that every product can acquire customers by offering personal onboarding.

It does show something more practical: sometimes the obstacle between interest and usage is not a lack of awareness. It is the work required to get started.

What that looks like in practice:

Developer tool: help someone integrate it
Software for accountants: import a customer's existing data
A service: deliver the first result personally before asking for a longer commitment

These approaches do not scale indefinitely. That is precisely why they can be valuable at the beginning.

Before automating an onboarding process, a founder needs to understand where people struggle with it. Before spending heavily on marketing, they need to know what happens after somebody responds.

The first ten customers can be valuable for the revenue they bring in. They can also reveal problems that a founder working alone would never have discovered.

3. Ten signups can still mean zero real users

There is another problem with the way founders talk about their first users: the word user can describe several very different situations.

Someone visits the landing page.
Someone else joins the waitlist.
A third person creates an account, opens the dashboard, and leaves.

All three might appear in a growth report. None necessarily demonstrates that the product is delivering its promised value.

This distinction is more than a matter of terminology.

In his account of Superhuman's product-market-fit process, founder Rahul Vohra described a company that had spent years building its email product but still needed a clearer way to measure whether users genuinely valued it.²

Superhuman surveyed people who had used the product at least twice in the preceding two weeks. It asked how they would feel if they could no longer use it.

Only 22% said they would be very disappointed.

That result mattered because these weren't simply people who had heard about Superhuman. They had already experienced the product. Yet most did not consider it indispensable.

The team used the survey responses to identify the people who valued the product most, understand what those people appreciated, and make improvements intended to strengthen product-market fit. Vohra subsequently reported that the score rose from 22% to 58%.

- 22%  "very disappointed"  (before)
+ 58%  "very disappointed"  (after)

58% - 22% = 36 percentage points

What this example does and doesn't establish

There are limits to what this example establishes. The survey is a useful diagnostic, not a universal scientific test that can independently prove product-market fit. The results came from Superhuman's particular audience and product, and a high score does not guarantee a sustainable business.

Still, the underlying problem is important.

Getting somebody to sign up and getting somebody to care whether your product disappears are not the same achievement.

For a founder trying to find ten users, this means the milestone needs a definition.

Ten registered accounts might be an appropriate early milestone for testing whether people will respond to an offer. Ten people who repeatedly use a core feature tell you something different. Ten paying customers tell you something different again.

None of those numbers is automatically the right target. The right target depends on what the product is supposed to accomplish.

Product type	A meaningful signal might be
Tool used every morning	Returning frequently
Quarterly accounting software	Completing the quarterly task (daily usage would be a strange expectation)
One-time service	Successful completion and willingness to recommend the provider

A founder should measure the behaviour that demonstrates value, rather than assume every product needs the same pattern of engagement.

Read the Superhuman product-market-fit story

4. When the advice is right, and when it isn't

The claim that customer acquisition is harder than building is most convincing when a founder has a working product but no reliable way to reach people who need it.

Imagine a developer who builds a scheduling tool for freelance designers. The technical work is manageable. The product works. But the developer has no existing audience among designers, no relationships with design agencies, and no idea where these freelancers look for tools.

The product might be finished in a month. Finding a group of people willing to try it, learning what they actually need, and discovering whether any of them will pay could take much longer.

The developer isn't necessarily struggling because the product is bad. They are trying to solve a problem for a group of people they don't yet understand well enough.

Now consider a different founder: an accountant who builds a small tool to automate a tedious task that several existing clients already complain about. The founder knows the workflow, has access to the intended users, and can test the tool with people who experience the problem every week.

The technical challenge could be the hardest part of that business. Finding the first few users might be comparatively straightforward.

	Developer building for designers	Accountant building for own clients
Existing audience	No	Yes
Knows the workflow	No	Yes
Likely hardest part	Finding users	Building the tool

Neither example is unusual enough to support a universal rule. Together, they show why the headline depends on the founder, the market, and the product.

Existing distribution changes the equation, too. Someone with an established audience, a respected reputation in a niche, or a network of potential buyers isn't starting from the same position as someone nobody knows.

That advantage is real. It doesn't mean their product is better, or that their acquisition strategy is automatically repeatable. It means some of the work required to earn attention happened before the product was launched.

The same qualification applies to technically novel products. If a founder doesn't yet know whether a proposed system can work at an acceptable cost, speed, or level of reliability, engineering experiments may need to come first. Talking to potential customers cannot resolve every question about technical feasibility.

The mistake is treating either building or customer acquisition as the correct first step for every startup.

Sometimes the founder needs to write more code. Sometimes they need to speak to potential customers before writing another line. Often, they need to do both, using what they learn from one to inform the other.

5. A quiet launch can mean four different things

Suppose you launch your product and, after several weeks, you still haven't found ten meaningful users.

The tempting response is to do more marketing. Post in more communities. Send more messages. Try another launch platform.

That might help. But first, consider where the process is breaking.

flowchart LR
    A[Launch] --> B{Right people<br/>seeing it?}
    B -- No --> C[1. Reach problem]
    B -- Yes --> D{Taking the<br/>next step?}
    D -- No --> E[2. Offer problem]
    D -- Yes --> F{Reaching the<br/>main benefit?}
    F -- No --> G[3. Activation problem]
    F -- Yes --> H{Returning<br/>or paying?}
    H -- No --> I[4. Retention problem]
    H -- Yes --> J[Keep going]

1. The right people aren't seeing the product

Perhaps the product solves a genuine problem, but your potential customers don't spend time on the channels you're using. Or perhaps you're targeting such a broad audience that your message never feels relevant to anyone in particular.

In this case, changing the product may accomplish very little. You need to understand where the intended customers already look for solutions and how to reach them.

2. People see the product but don't take the next step

This could mean the value proposition is unclear. It could also mean the problem isn't urgent, the price is too high, the proposed solution feels risky, or the person reading your message doesn't have the authority to make a purchase.

It is worth asking what your offer requires someone to believe before they act. An unfamiliar product asking for access to sensitive business data has a much larger trust problem than a free tool that works entirely in the browser.

3. People try the product but never reach its main benefit

Perhaps setup takes too long. Maybe the first screen asks users to configure five things before they can accomplish anything useful. The product might even work exactly as intended, but the value isn't apparent to a new user.

This is where watching someone use the product can reveal more than another round of promotional posts.

4. People get value once but don't return or pay

This is the most uncomfortable possibility because the founder has evidence that the product can work for someone, yet the behaviour isn't continuing.

The problem might be retention, pricing, a low-frequency need, or a mismatch between the person using the product and the person expected to pay. It could also mean the product is useful but not important enough to replace an existing habit.

Not a complete diagnosis. These four categories aren't exhaustive, and the boundaries between them aren't always clean. A confusing product can look like a marketing problem. A weak offer can look like a distribution problem. Low retention can reflect a product that works perfectly but solves a problem people rarely encounter.

The point is not to label every failure immediately.

It is to stop treating every failure as the same failure.

6. What should you actually do to find the first ten?

The best starting point is smaller than a launch campaign.

Choose a specific group of people who already experience the problem your product is intended to solve. Be precise enough that you can identify actual individuals, rather than an enormous category of potential customers.

Then investigate what they do today.

If you're building invoice software for freelancers, find out how those freelancers currently create invoices, follow up on unpaid bills, and keep track of their income. Ask what happens when the process goes wrong. Look for examples of real frustration, time lost, money lost, or workarounds people have already built.

Steve Blank's writing on customer development makes a useful distinction here: founders begin with hypotheses about customers and their needs, then test those hypotheses through conversations and experiments.³ The goal is to discover what is true, not simply to collect encouraging responses.

That means asking about actual behaviour is usually more informative than asking whether somebody likes your idea.

Example: weak evidence vs. strong evidence

A person may tell you they would happily use an invoicing tool. That costs them nothing.

Finding out what they currently use, whether they have paid for alternatives, and whether they'll try your product with a real invoice gives you stronger evidence.

Once you understand the problem, offer a small, concrete next step.

Don't necessarily ask someone to adopt your entire product. Ask whether they'll try one feature, bring one real task into it, or spend twenty minutes showing you how they currently handle the problem.

If the product is ready, help them use it. If it isn't, a prototype or a manually delivered version of the service might be enough to test the underlying assumption, provided you don't misrepresent what you've built.

Track what happens next

Stage	What to record
Reached	Did the intended person actually see the offer?
Responded	Did they reply or ask a meaningful question?
Tried	Did they attempt the real task?
Activated	Did they reach the product's core value?
Returned	Did they use it again when the need arose?
Committed	Did they pay, renew, recommend it, or make another meaningful commitment?

Not every product needs all six stages, and not every commitment looks like a payment. The table is a way to make the process observable, not a universal funnel that every business must follow.

Keep notes on why people stop, preferably in their own words. A polite refusal and a detailed objection are not equivalent. Neither is the same as someone who tries the product, gets value from it, and simply doesn't need it again until next month.

Then choose the next experiment based on what you learned:

[ ] The wrong people are seeing the offer: change the audience or channel
[ ] The right people understand the offer but don't care enough to try it: investigate the problem and the value proposition
[ ] They try the product but fail to reach its main benefit: work on that experience
[ ] They get value but don't return or pay: investigate the frequency, importance, and economics of the problem

Two weeks can be enough to uncover useful patterns when the target customers are accessible and the product delivers value quickly. It may be nowhere near enough for a business with a long sales cycle or a problem that occurs only a few times a year.

The objective isn't to promise ten users within fourteen days. It is to finish the experiment knowing more than you did when you started.

7. The first ten are not the finish line

There is a reason founders remember their first users. Each one represents a decision that happened outside the codebase: somebody noticed the product, considered it relevant, decided to try it, and perhaps found enough value to return.

But the number ten can be misleading.

Ten users who...	...might tell you
signed up because a friend asked	Very little about whether strangers will pay
independently share the same painful problem and pay to solve it	A great deal
never return	A product problem that another hundred signups would only make harder to ignore

The work isn't finished when the tenth person arrives. That's often when the next question becomes possible.

Can you find another ten people with the same problem?
Can you reach them through a process you understand?
Do they experience enough value to keep using the product?
Does acquiring and serving them make economic sense?

Those questions are harder to answer than whether a product can attract ten signups, and they matter more to the future of the business.

So, is getting your first ten users harder than building the product?

Sometimes. Especially when the founder understands the technology but knows very little about the people who might buy it. But the comparison becomes less useful when it turns into a universal rule, or when it encourages founders to treat engineering and customer discovery as competing activities.

A product can be technically excellent and commercially irrelevant. It can also be commercially promising before its engineering is finished. The difficult work is finding out which situation you're in while there is still time to change direction.

That begins with a more useful question than how to get ten users.

Your next question

What would you need to learn from the next person who tries your product to know what to do next?

Share your answer in the comments.

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

Paul Graham, "Do Things That Don't Scale," 2013. The essay is where the Collison installation story comes from. ↩
Rahul Vohra's account on the First Round Review. The 22% and 58% figures come from Superhuman's own survey of its own users, so treat them as one company's data point. ↩
Steve Blank's customer development writing is a collection of posts, so start with the ones on customer discovery and hypothesis testing. ↩

Should You Build an MVP Before Your First Customer?

Hanzla Baig — Sun, 25 Oct 2026 12:52:03 +0000

Some questions about a startup idea can be answered with a conversation or a cheap web page. Others need a working product. A lot of wasted effort comes from mixing the two up.

Joel Gascoigne started coding Buffer before he'd checked that anyone wanted it. He says so himself, in a February 2011 post about getting from idea to paying customers. Partway in he stopped and put up a two-page site instead. Then he wedged a pricing page between the two pages, so a visitor had to click a plan before leaving an email address for a launch notice. A small number of people clicked paid plans, and that was enough to send him back to the code. Seven weeks of evenings and weekends later he launched, on 30 November, and by his account the first paying customer turned up within four days.

Figma went the other way. Its launch post talks about three years of silence. Dylan Field has said that when Figma raised its first round, it had no user metrics and the product was still in stealth.

People cite both stories as proof of opposite rules: test first, or build first and let the market judge the finished thing. Both founders ran companies that survived, so neither story tells you much about the odds. Put side by side, though, they show two founders stuck on different questions. This article is about working out which question you're stuck on, and what the cheapest test of it would be.

Two risks under one label

Rob Fitzpatrick's The Mom Test splits risk in two, at least as summarised by study guides. Customer risk asks whether people want this and will pay. Product risk asks whether it can be built. When most of the risk sits in the product, those summaries say, no amount of customer conversation settles it. His examples include video games and a farm fertility monitor.

Buffer was mostly customer risk. Queuing tweets wasn't technically scary; the open question was whether anyone cared. Figma's early browser-based design tool is a simplified example of the opposite. People could picture wanting it, and nobody knew whether a browser could do the job. That contrast is mine, not something any of the sources says. Real ideas usually carry some of each, so the practical question is which one is the bigger unknown right now.

Not all evidence weighs the same

Here is what common signals can and can't tell you.

What you got	What it tells you	What it doesn't
A compliment	Goodwill, maybe real interest	Behaviour, or intent to buy
An interview about what they do today	This person has the problem and how they cope	That the market is big, or that they'd switch to you
A signup or waitlist	Your message landed in that channel	That they'd use it or pay
A pricing-page click	Which plan caught their eye	That anyone would pay. Nobody did
A signed pilot or letter of intent	Commitment, as strong as its terms (scope, date, price). Some letters are non-binding	That it holds up beyond the pilot
A payment	Willingness to pay for this offer, under these conditions	Renewal, or whether a discount, a friendship or a one-off need did it

Repeat usage belongs on that list too. It's strong evidence for a product people are meant to use often, and you need a product before you can see it.

Fitzpatrick's own test, again via summaries, is whether a conversation ends in commitment or advancement: the other person gives up time, reputation or money, or agrees to a next step. A compliment costs nothing to give. Treat it as a weak signal until behaviour backs it up.

Don't read the table as a ladder. A payment for a service you deliver by hand says a lot about willingness to pay and very little about whether people will put up with your software. The strongest evidence is whichever kind matches the claim you're testing.

What you can test without a product

Interviews about past behaviour tell you whether the problem is real and how people cope. They're poor at predicting what someone will do with something new, and they're easy to steer without meaning to. A landing or pricing page tests whether a message pulls attention in one channel, and it tests willingness to pay only if money changes hands. A manual or concierge service shows what the job really involves and gives you honest data on price, but it hides everything about scale. A demo video or clickable prototype helps when an idea is hard to explain and says nothing about retention. A scoped paid pilot, a pre-order (with explicit delivery and refund terms) or a letter of intent gets you commitment from a specific buyer, though early buyers often differ from later ones. A technical spike tells you whether the hard part is possible and nothing about demand.

Look at Buffer with that in mind. The pricing-page click wasn't a payment, and the product had little technical risk. Gascoigne is open that his early "validated" was a handful of emails and some feedback. The better evidence, a paying customer, arrived after he'd built and launched. So the sequence wasn't "validate, then build." He ran a cheap test for customer risk, then built the smallest thing that could produce stronger evidence.

Food on the Table shows the manual route. In accounts of the Lean Startup method, an early customer got weekly personal service in place of software. Manuel Rosso's talk on concierge MVPs frames that service as a way to learn rather than to scale, and advises writing code only when it makes learning cheaper. The takeaway is narrow. Manual delivery shows what the job involves and whether people accept a high-touch version. It can't tell you whether software will do the job.

One rule covers every test before a product exists: say what doesn't exist yet. A landing page should describe what customers will get and when, and if you take money, the refund terms should be plain. Buffer's pricing page collected emails for a launch notice, which is a long way from pretending the product was live.

When building is the experiment

Some questions don't yield to conversation. Two cases show how, and both come with the usual survivor caveat.

Dropbox is awkward to describe and obvious once you see it. Drew Houston's own slide deck lists a three-minute screencast on Hacker News in April 2007 that brought "lots of immediate, high-quality feedback", then a private-beta video in March 2008 after which the waitlist jumped from 5,000 to 75,000 in a day. In a 2011 interview he said they'd expected 15,000 at most, and that they used a closed beta because they didn't want to risk a buggy product on all 75,000. One secondary account says a working prototype sat behind the first video. I couldn't confirm that from Houston himself. What the evidence supports is narrower: a demo helped communicate a hard-to-explain product and showed interest among early adopters. It doesn't show willingness to pay, retention, or that the audience generalised. A waitlist is interest, not commitment.

Figma is the cleaner case. The open question was whether a professional design tool could run in a browser at acceptable speed. Field says people who had tried WebGL before warned them off. According to Sequoia's profile, the closed beta came in December 2015 and the first dollar was charged in summer 2017. Interviews couldn't settle feasibility. That took technical experiments and a working prototype, whatever customer learning went on alongside. It was also affordable only because of a founding pair with deep graphics skills and investors willing to fund years in stealth. Few solo founders have both.

What the two cases share, and this is my inference, is that building was justified by one specific unanswered question. If your riskiest assumption can't be tested credibly without a working prototype, build, and build only the part that tests it.

How much validation is enough?

There's no credible number. The nearest research is a line of randomised trials by Camuffo, Gambardella, Spina and colleagues. In the 2020 trial (Management Science, 116 Italian startups in the paper's panel sample), some founders were trained to treat their idea as a theory, form hypotheses and test them, while a control group followed its instincts. The authors report that the treated group pivoted more and earned more revenue.

The 2024 replication in the Strategic Management Journal pooled four randomised trials covering 759 firms. Its abstract reports a positive effect on idea termination and a nonlinear effect on radical pivots: treated firms ran a few pivots rather than none or many. The authors read this as more efficient search plus more "methodic doubt". So the 2020 headline, more pivoting, didn't hold up as stated. The clearer result is more decisive stopping and more deliberate changes.

Both are training programmes for early-stage founders, and neither compares interview-first with MVP-first. They support something narrower: tests built to be able to say no seem to help founders decide. That reading is mine, not a conclusion the authors draw about MVPs.

In practice four things move the answer: what a wrong build would cost, how easily you could undo it, how reachable your customers are, and how much is still unknown. A weekend project you can bin needs very little evidence. Six months of work for buyers you can't easily reach needs a lot more.

A way to decide (my synthesis, not an established method)

Five questions, in order. Skip any you can already answer with evidence.

Which assumption is riskiest? That the problem exists, that a specific group cares, that your solution works, that it's feasible, or that they'll pay.
What's the cheapest test that could come back negative? A conversation, a manual service, a prototype, a technical spike, a pilot, a payment.
What result would change your mind? Write it down before you run the test. If no result would make you stop or change course, you aren't testing anything.
What's still unknown afterwards? Three paid pilots say nothing about what the fourth customer costs to find.
What's the next smallest step? Keep learning, build a limited version, run a paid pilot, change the customer, or stop.

A rough rule for interview versus experiment: when several people independently describe the same recent problem and workaround, consider moving from broad discovery to a more specific test. More interviews can still help if you're exploring a different segment or an unresolved objection. Otherwise the next useful question may be whether someone will commit to a concrete step.

An experiment for a solo founder: the scoped pilot ask

This suits a B2B or prosumer idea.

Hypothesis: People in one narrow segment who already spend time or money working around this problem will agree to a specific, paid pilot.
Test: Talk to people who've shown the problem in past behaviour. Describe exactly what they'd get, by when, and what isn't built. Ask for a concrete step: a start date, a price, or a deposit with clear refund terms.
Before you start: Write down how many yeses would make you proceed and how many would make you rethink. Choose a threshold that fits your market, your access to buyers and the cost of being wrong. Don't borrow a universal number.
Record: For each person, their current workaround, what it costs them, what they said (paid, agreed in writing, asked to wait, declined) and why.
Limits: You'll mostly reach people like you, a pilot price isn't a product price, and delivering by hand hides software costs.
Next decision: A yes counts when it's a defined step, such as an accepted scope, timeline and price, not verbal encouragement. Enough of those means deliver by hand and note which steps repeat, since those are what to automate. Repeated "interesting, not now" means urgency or the offer hasn't been shown. Ask why: wrong buyer, unclear offer, budget timing, missing trust, or a problem that isn't pressing. Then narrow the segment, change the offer, or stop.

Back to Buffer and Figma

The two stop looking like opposites once you ask what each founder didn't know. Gascoigne didn't know whether people cared, and a small page could probe that. Field didn't know whether it was possible, and that took building. Both are survivors telling their own stories, so hold the conclusions loosely.

Before your next coffee chat or your next hour in the editor, write down the assumption most likely to sink you, and pick the cheapest test that could prove it wrong.

What's your counterexample? Have you built first and been right to, or run a validation test that said yes while the product still failed? What did you measure, and what would you do differently?

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 😅

Free Assets and the Stigma people enforce behind them

MT Indie Dev — Fri, 23 Oct 2026 19:00:28 +0000

Would you use free assets in your games?

I would, and I don’t think there’s any shame in it.

I’ve never really understood the stigma around using free assets in game development. Sometimes, people talk about them as if downloading a free model or sound somehow makes the rest of your work less valuable.

But why?

For anyone unfamiliar with the term, assets are the individual things that go into a game: trees, buildings, characters, sounds, animations, textures, and so on. Making all of those takes time, and creating a game involves much more than making its individual parts.

If someone offers a useful asset for free and allows others to use it, I see that as an opportunity.

Free doesn’t mean bad.

The price of an asset doesn’t tell you whether it looks good, works properly, or fits your game. A paid model can be unsuitable for your project, while a free one can be exactly what you need.

Some creators choose to share their work because they want to help other developers. Kenney, for example, makes its game assets available under CC0, allowing people to use them without requiring credit. These resources are offered for a reason: so people can build with them.

There’s nothing embarrassing about accepting that help.

Your time matters, too.

Imagine you need a simple chair for a room in your game. You could spend days learning how to model it, give it the right surface details, and get it working in the engine. Or you could find a suitable free chair and spend that time improving something the player will actually do.

Neither choice is automatically wrong. If you want to learn how to make furniture, creating the chair yourself makes sense. If your goal is to finish a playable game, using an existing one might make more sense.

Personally, I don’t think developers should feel pressured to spend days proving they can make an ordinary chair when their game needs attention elsewhere.

That time could go towards a better mission, smoother movement, clearer menus, or fixing an annoying bug.

A downloaded asset doesn’t build the game for you.

This is probably the part that gets overlooked most often.

Downloading a door doesn’t make it open. You still need to decide how the player interacts with it, whether it needs a key, what happens when it’s locked, and how it connects to the rest of the game.

Downloading trees doesn’t create an interesting forest. You still have to build the space, create paths, place things thoughtfully, adjust the lighting, and make sure the game runs well.

The person who made the asset did valuable work. The person who turns it into part of a playable experience also does valuable work.

Using someone else’s model doesn’t erase everything you built around it.

You can use the same pieces and create something different.

Two people can cook with the same ingredients and make very different meals. I think game assets work in a similar way.

The same house model could become a peaceful home in one game and an abandoned building in another. Different lighting, sounds, surroundings, and events can completely change how that place feels.

Custom artwork can certainly help a game stand out. But a game’s identity also comes from its ideas, its atmosphere, its story, and the way it plays.

Every rock and table doesn’t need to be exclusive for the overall experience to feel personal.

Free assets help you find out whether an idea actually works.

An idea can sound amazing when you write it down and feel completely different once you try to play it.

Having models, sounds, and animations available lets you reach that playable stage sooner. You can test a mechanic, try a different layout, or discover that something needs changing before spending months making everything yourself.

And if a free asset still works well in the finished game, why replace it purely because it was free?

I’d rather replace something because it doesn’t fit or causes problems, not because I feel guilty about how much it cost.

Not everyone has a studio’s budget.

A solo developer might be handling the gameplay, environments, menus, sound, testing, and writing. That’s already a lot for one person.

They may not have the money to hire people for every task, or the years needed to become good at every part of development.

Free assets make it easier for people to learn and give their ideas a real chance. They can also leave room in the budget for things that need special attention: perhaps an original main character, music, or an important location.

Using free resources where they fit can help you afford custom work where it matters most.

Of course, you still need to choose carefully.

Not every free asset belongs in every game.

Some won’t match the look you’re going for. Some might slow the game down or take too much effort to adjust. You also need to check what the creator allows you to do with them and give credit when required.

And you should be honest about your contribution. Using someone’s model is fine when you have permission. Claiming you made that model yourself is a different issue.

Those are fair things to discuss. But none of them makes using free assets shameful.

Judge the result.

If a game looks messy, runs badly, or isn’t enjoyable, those are fair criticisms. Explain what isn’t working.

Simply saying “that’s a free asset” doesn’t tell me what’s wrong with the game. Paying for the same object wouldn’t suddenly make the gameplay better.

For me, the question is simple: does this asset fit what I’m making, and does using it help me move the project forward?

If the answer is yes, I’m happy to use it.

I respect people who create everything themselves. I also respect people who know where to spend their time and use the resources available to them.

So yes, I would use free assets in my game. Why should a useful resource become something to be ashamed of just because it didn’t cost money?

An Indie Solo Gamedev's perspective on Public Building(credits to Hanzla Baig for the ideea)

MT Indie Dev — Thu, 22 Oct 2026 15:57:55 +0000

Indie game development often begins with something deeply personal you really want to build. An atmosphere you want to create. A story you cannot stop thinking about. A mechanic you would love to experience as a player. Before anyone sees a screenshot or watches a devlog, there is already a reason you chose to build this particular game.

Then you start sharing it.

At first, building in public feels exciting. You show a mechanic, someone responds, and suddenly the work you have been doing alone becomes a conversation. A little encouragement can mean a great deal when you are learning, solving problems, and trying to turn an idea into something playable.

But that attention can gradually influence more than what you post. It can begin to influence what you build.

A visually impressive feature receives more interest than a system you spent weeks developing. A funny bug attracts more attention than an important milestone. One particular style of content performs well, so you make more of it. That is understandable. When something connects with people, you naturally want to understand why.

The difficulty begins when that response becomes the main reason behind your next decision.

You start choosing tasks partly because they will make a good upload that people will engage with. You spend time polishing something for a video while another feature, essential to the game, waits unfinished. You feel reluctant to share quieter progress because you already expect it to be ignored. Slowly, the audience’s preferences begin taking up space once occupied by your own intentions.

No one has explicitly asked you to change your game. Yet you find yourself changing its direction to keep people interested.

For a solo developer, this can be especially difficult. You are already responsible for learning, implementation, debugging, design, and countless decisions. Sharing development adds another responsibility: presenting that work in a way people want to watch. Eventually, it can feel as though every development session must also produce something worth posting.

Some progress simply does not work that way.

An evening spent fixing an interaction problem may produce no striking footage. Reworking a confusing interface might look like a small change despite requiring considerable thought. Building a reliable foundation can take weeks before there is anything exciting to demonstrate. Those efforts still matter to the person who will eventually play the game, even when they attract little attention online.

The emotional difficulty comes when you begin using that attention to judge yourself.

It hurts to put care into something and receive almost no response. It can hurt even more when people previously engaged with your work, then lose interest as you return to the direction that makes you happy. You may start questioning your ability, your project, or whether the effort has any value at all.

For some developers, that pressure can contribute to exhaustion, low mood, and eventually the decision to stop. An activity that once offered encouragement becomes another place where they feel they are falling short. A passion once holding you together starts breaking you apart!

That possibility deserves an honest conversation. Building in public can bring connection and useful feedback, but it can also become emotionally draining when every post feels like a verdict on your future.

I still choose to share my development. I have not received all the interaction I hoped for, and I will not pretend that never disappoints me. Of course I want people to care. Sharing something personal usually carries the hope that someone else will find meaning in it.

But I also want to recognize my own game when I look at what I am building.

I want to make decisions because they serve the experience I imagined, while remaining open to feedback that can improve it. Players can reveal confusing mechanics, unclear information, or problems I have overlooked. Listening to them is valuable. I can take those observations seriously and still decide which suggestions belong in my project.

The same applies to posting. I want to share when I have something I feel ready to show. A regular schedule may help some developers, but I do not want mine to become an obligation that makes development feel like feeding a content calendar. Sometimes the work needs time, privacy, and room to be unfinished.

If you enjoy what I share, thank you. Your interest means something to me. If it does not appeal to you, I appreciate you taking a look. There is no formula that will make one game meaningful to everyone, and trying to find it could consume the very enthusiasm that made me start.

For me, continuing means accepting that some updates will receive little attention and some people will move on. I can feel disappointed without allowing that disappointment to choose the next feature.

I started with a game I wanted to create. Sharing the journey should leave enough room for me to keep creating it.

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

Hanzla Baig — Thu, 22 Oct 2026 15:41:56 +0000

What founders report, what that evidence can't prove, and a four-week experiment you can run on your own product.

In 2023, the founders of Senja, a customer-testimonial tool, noticed how much attention revenue screenshots were getting in the build-in-public community. They gave the makers who focused on milestones a nickname: "milestone men." Then they started sharing losses and context alongside their wins.

They weren't skeptics, though. In the same interview, co-founder Olly said one in four of Senja's paying customers came from Twitter and building in public.

So one practice earned applause for some founders and, by one founder's account, paying customers for another. This article is about the gap between those outcomes. The question isn't whether building in public is good or bad. It's what has to be true between a post getting attention and a stranger paying for your software.

We'll look at what attention metrics can and can't tell you, then three documented accounts: a modest success, a spectacular one, and a failure. Then I'll explain why even those are weaker evidence than they look. Finally, we'll turn the patterns into an experiment small enough for a solo founder to run without losing a quarter.

One phrase, four different activities

"Building in public" gets used for at least four things that behave differently.

Progress sharing: changelogs, screenshots, technical decisions. Mostly interesting to people who care about the process.
Metrics sharing: revenue, signups, churn. It builds credibility, and as the Senja founders noticed, it can easily turn into a performance.
Teaching: posts that solve a reader's problem whether or not they ever buy. This is content marketing under a founder's name.
Conversation: asking users for feedback and answering people who have the problem you solve.

This split is my own, not an industry standard. It matters because the activities tend to attract different kinds of attention. Progress and metrics posts often draw people who like following founders. Teaching and conversation tend to draw people with the problem. Those groups sometimes overlap, but often they don't, and the product, audience, and platform all change the picture.

What a like measures

A founder's funnel has more stages than a social feed shows. Treat this table as a simplified model, not a strictly linear customer journey:

Stage	What you can count	What it tells you
Attention	Impressions, likes, followers	People saw it and reacted. Not proof of buying intent.
Interest	Replies and DMs from people who fit your buyer profile, email signups	Someone with the problem wants more
Trial	Signups, then activated users (these are different things)	Someone tried the product, and maybe got value from it
Revenue	Paying customers	Someone valued it enough to pay
Durability	Retention, or repeat purchases for non-subscription products	The value held up

Not everyone who sees a post moves to the next stage, and many never do. How big the drop-off is depends on your audience, your offer, and your channel. A post can do brilliantly at the top while adding nothing at the bottom. If your audience is mostly other founders and you sell to dentists, a viral thread is a pleasant event with no commercial consequence. Your mom will be very proud, though. 🦷

There's a complication in the other direction. Influence doesn't always show up as a click. Olly said far more happens in DMs than people assume, especially around launches. Readers who never click a link may still remember your name later. That's an argument for tracking conversations, not just clicks, and for asking new users how they found you. Self-reported attribution is imperfect, but it beats assuming the answer is "direct."

Three accounts, three different lessons

Senja: customers, with caveats. The interview ran in March 2023, when Senja had reached $4,000 in monthly recurring revenue in under a year. Olly reported that one in three signups and one in four paying customers came from Twitter and building in public, and that he spent about seven hours a week on it. Note that those figures combine Twitter and building in public, so they don't isolate the effect of building in public itself. He called it, along with SEO, the best-return marketing work they did. He also listed conditions that cut against the hype. It's easier if you're making a product for other makers, it can take months to generate sales even then, and he wasn't starting from zero, since he already had a small audience from an earlier project.

RB2B: the spectacular case. Adam Robinson's account is the dramatic one. Interviews, including a ProductLed podcast episode, report that he took RB2B, a website-visitor identification product, to $5 million in annual recurring revenue in about 13 months with a tiny team, using LinkedIn heavily for awareness. A Trueframe write-up of his published figures (Trueframe is a content agency, so read it with that in mind) says he attributed about 75% of site traffic to LinkedIn in an October 2025 snapshot. It also notes that his own launch retrospectives disagree on basics, such as 1,600 waitlist members in one telling versus 3,000 free signups in another, and that meme content drew attention from people outside his buyer group. Now look at what surrounds those numbers. He already ran a larger, established company, his LinkedIn audience was made of SaaS operators, and RB2B sells to SaaS operators. That's less "I posted memes and got rich" and more "I posted to the exact people who buy." Treat all of this as his claims, not audited results.

A six-month failure. A founder wrote on Indie Hackers in September 2025 about posting daily updates, sharing the journey on Reddit, and ending up with 43 signups, 2 paying customers, and $18 in monthly revenue. Their own diagnosis was that the people cheering them on were supporters, not people with the problem. It's a single self-reported anecdote, and the post ends by linking the author's product, so weigh it accordingly. It's also as much a story about weak demand and validation as about building in public. Lots of cheering, very little paying.

What these accounts can't tell us

These stories are interesting, but they don't prove that building in public causes customers. Here's why.

First, every account is self-reported. Nobody audited these numbers, and an interview with a founder is a founder describing their own business.

Second, none of them isolates building in public from everything else. Senja credits SEO alongside Twitter. Robinson had an existing company and a reputation among his buyers. The failed project may simply have lacked a real problem to solve. The strategy might be the cause, a contributor, or just a companion to something else, and a story told after the fact can't separate those.

Third, we mostly hear from the visible. Founders who posted for a year, got nothing, and moved on rarely write retrospectives. That's my inference, not a measured fact. I couldn't find a controlled comparison of founders who build in public and similar founders who don't. If you see a precise "founders who build in public grow X times faster" statistic, ask where the denominator came from.

The three cases don't produce the same outcome, but they share a thread. Where the strategy visibly worked, the audience was close to the buyer. That's suggestive, not conclusive.

When it seems to work, and when it probably doesn't

Treat these as hypotheses consistent with the accounts above, not proven rules.

Audience overlap. Senja said building in public is easier for a product aimed at makers, and Robinson's audience matched his buyers. The failed project's audience was supporters. If your customers aren't on the platforms where founders talk to each other, you may grow a friendly audience that's useless to your revenue.

Content a buyer would value. Senja's "milestone men" and engagement from people who were never going to buy teach the same lesson from two directions: attention from the wrong people, or about the wrong thing, doesn't convert. A revenue screenshot can show that a business exists. On its own, it rarely shows a buyer that you'll solve their problem.

A route from reading to trying. A free tier, a waitlist, and Senja's DM follow-ups all give an interested reader a next step. This one is my inference from the accounts, not something any of them tested. Attention without a path leaves people with nowhere to go.

Time, including yours. Seven hours a week is nearly a full working day for a solo founder. The honest comparison isn't "posting versus nothing." It's posting versus the same hours spent building, or reaching out directly to people who fit your buyer profile.

One more thing the success stories don't dwell on: transparency is a strategic choice, not an obligation to disclose everything. Customer details, security specifics, and anything covered by a contract don't belong in a public update, however good the engagement would be.

A four-week experiment

Four weeks is a proposed starting point, not a proven duration. Senja's experience suggests sales can take months, so this experiment measures leading indicators, not revenue. The question it answers: is public content producing conversations with people who look like buyers?

Baseline (before week 1). Record how many signups you get per week now and where they come from. Note how many hours you can honestly spend. Without a baseline, any result is uninterpretable, and I'm not aware of a defensible benchmark conversion rate to use instead.
Audience. Write one sentence naming who pays you and where they already read or talk. If you can't, you've learned something important before posting a single word.
Hypothesis. Something like "Posting twice a week in [place] will start conversations with at least [N] people who fit my buyer profile." Set N before you start, based on your baseline and your available hours (for example, what the same hours of direct outreach would produce), not after you see the results. Moving the goalposts is a sport, but not this one.
Content. Mix teaching posts that address a buyer's problem, build updates framed around what changed for a user, and replies in existing communities. Treat revenue and milestone screenshots as optional. Log which type of post led to each qualified conversation, so you learn what worked and not just that something did.
Distribution. Pick one or two places where buyers already spend time. Reply and participate more than you broadcast.
Measurement. Leading indicators: replies and DMs from people who fit your buyer profile, and qualified visits to your site. Middle: signups and activation. Lagging: paying customers and retention, which probably won't show up in four weeks, so don't conclude from their absence alone.
Attribution. Use a distinct tracked link per channel and log DMs by hand. Add one free-text "how did you hear about us?" question at signup, and let people name more than one touchpoint, since someone may see a post, come back later, and sign up through a search result. Accept that this undercounts, because readers who see a post and return later will often look like direct traffic.
Review and decision rules. Check in at the end of week two to see whether the routine is sustainable and the content is landing with the right people. At week four, look at the quality of conversations (one qualified chat can beat ten polite likes), whether any turned into trials, how much time you spent, and whether you're reaching the right audience. Then decide whether to continue, change the channel or content, or run another cycle. Don't use four weeks to declare the whole strategy a success or a failure. If attention is high but buyers are absent, that usually points to the wrong venue or topic, not the wrong product. Consider demoting it to an accountability and networking habit if, after two cycles (my suggestion, not a proven threshold), qualified conversations stay near zero.

So, does it get you customers? 🎯

Sometimes. In the documented cases where it did, the audience was already close to the buyer, the content was useful to that buyer, and there was a path from reading to trying. When those conditions are missing, building in public may still help with accountability, feedback, and networking, but its value as a customer-acquisition channel becomes much less certain.

How often it works across all founders, nobody can say from the evidence available. What you can do is test it on your own product, with your own baseline, before spending a year on it.

So here's the question I'd most like to see answered in the comments. If you've built in public for a product whose buyers weren't other builders (dentists, accountants, game studios, anyone), where did your first ten paying customers actually come from, and could you trace any of them back to a public post?

Tea House Area - Fencing, Pathways, Pond Area | UE5 Devlog

MT Indie Dev — Wed, 21 Oct 2026 22:42:19 +0000

In this Life of Alex devlog, I continue building the tea house area at Kazuhara Resort in Unreal Engine 5. This update focuses on defining the space with fencing, adding stones along the pathways, and introducing a pond with a bridge and fencing around its edges.

Piece by piece, the area is taking shape, with clearer routes through the garden and more detail surrounding the tea house. Join me as I bring these elements together and continue shaping a peaceful setting to explore.

Landscape creation and terracing process for Kazuhara Resort | UE5 Devlog

MT Indie Dev — Wed, 21 Oct 2026 17:48:55 +0000

In this devlog, I showcase the landscape creation and terracing process for Kazuhara resort in Unreal Engine 5. Using Landscape Mode’s Sculpt, Flatten, and Smooth tools, I shape the terrain, create distinct terraces, and soften the transitions between elevations.

The focus is on building a foundation for the resort, balancing usable flat areas with the natural slopes of the surrounding landscape. It’s a look at the work behind shaping the environment before the finer details bring it to life.

Evening the Terrain & the construction of Road Infrastructure | UE5 Devlog

MT Indie Dev — Wed, 21 Oct 2026 17:43:28 +0000

In this devlog, I continue shaping Kazuhara Resort by evening out the terrain and building its road infrastructure in Unreal Engine 5. The focus is on preparing the ground and creating routes that connect the resort’s different areas.

I showcase the Flatten and Smooth tools to level uneven surfaces and soften transitions, the Ramp tool to connect different elevations, and the Landscape Paint tool to define the road surfaces. These changes help establish the resort’s layout and make the terrain more practical for further construction.