---
title: "Building got cheaper. Entrepreneurship did not."
date: "2026-06-24"
description: "A personal read on indie hacking in 2026, from the first cheap-software startup myths to AI wrappers, distribution, trust, runway, and the projects that never reached the market."
category: "Indie Hacking"
readTime: "29 min read"
tags: ["Indie Hacking", "Bootstrapping", "AI Wrappers", "Entrepreneurship", "Building in Public"]
---
I started wanting the indie-hacker thing in 2018.

Eight years later, I am better at almost everything I thought I needed. I can build faster. I understand product better. I can write better. I can use AI as a serious tool instead of as a toy. I know more about distribution, SEO, positioning, open source, technical credibility, and the ugly parts of making software visible.

The game still feels harder.

The part I avoided naming is panic. Not a dramatic panic. The small one that appears when a private project has to become visible and people can judge it without knowing the effort behind it.

On paper, that fear looks stupid. I have been paid to build software for years, both as an employee and in selected freelance/client work. I have worked inside banks, retailers, and financial operations. I have led teams. I have shipped systems where mistakes touched money, customer data, release windows, and people who did not care how elegant the internals were.

Impostor syndrome is not impressed by a CV. It just changes the question. First it asks whether I can build the thing. Then, once I can, it asks who I am to sell it.

That is part of why publishing became harder. The product was one excuse. I was also waiting for a version of myself that felt technically credible, commercially credible, and still recognizably mine.

That sentence bothers me because the obvious answer is that I should have launched more. That answer is true. It is also incomplete. Most of my projects never reached the market with enough force to deserve rejection.

They stayed in the private zone where engineers can feel productive for a long time: architecture, refactors, local demos, new names, better abstractions, another repo, another rewrite, another almost-launch.

That is a different kind of failure. It is more embarrassing because there is no clean external verdict. No customer said no. No market said the price was wrong. No landing page failed to convert after enough traffic. The work just never crossed the line where reality can answer.

I have been thinking about why.

## The 2018 version

The indie-hacker story did not start in 2018. By then it already had a language, heroes, communities, revenue screenshots, and rules for how a serious small builder should behave.

The older startup story came from Silicon Valley: move fast, raise capital, grow hard. [Y Combinator says it developed a new model of startup funding in 2005](https://www.ycombinator.com/), with small seed checks, batches, three months of pressure, Demo Day, and a network that continues after the batch. That model changed what a startup could look like for thousands of founders.

Then software got cheap enough for another story to become believable.

In 2008, Paul Graham wrote about ["ramen profitability"](https://paulgraham.com/ramenprofitable.html): a startup making just enough to pay the founders' living expenses. His point was simple and still sharp. Software had become cheap enough that survival could come before scale. A tiny product could buy time.

That idea mattered. It made a different kind of ambition feel possible. You did not need to build a billion-dollar company from the first day. You could build something small, sell it, pay your bills, and keep going.

The bootstrapped SaaS world grew around that idea. [MicroConf describes itself as the original community for bootstrapped SaaS founders](https://robwalling.com/community). The language was more grounded than the VC story: charge money, talk to customers, control costs, avoid raising if you do not need to.

Then came open startups and building in public.

[Baremetrics launched an Open Startups initiative](https://baremetrics.com/blog/open-startups) around SaaS companies sharing MRR, ARR, churn, LTV, customer counts, and other real metrics. That transparency was useful at first because it replaced fake startup posture with numbers.

In 2014, Pieter Levels wrote about [launching 12 startups in 12 months](https://levels.io/12-startups-12-months). The important part was not the gimmick. It was the fear underneath it. He wrote that doing something exposes you to the world and its market forces.

That is the sentence I should have taken more seriously.

I read it as permission to build small. It was also a warning: the work has to leave the private folder. Otherwise there are no market forces. There is only taste, fear, and another internal standard to satisfy.

[Indie Hackers launched in 2016](https://www.indiehackers.com/about), was acquired by Stripe in 2017, and then [spun back out as an independent business in 2023](https://www.indiehackers.com/product/indie-hackers/indie-hackers-is-indie-again--NSIAlb7LggSjzTavQZb). A community about independent online businesses became valuable to a payments company, then had to become independent again and figure out revenue like everyone else.

By the time I found the dream, the formula felt clear:

- build a small software product
- launch early
- share progress
- be transparent with metrics
- learn from customers
- repeat until something works

That formula still sounds reasonable.

The formula missed the inputs.

## The hidden inputs

The indie-hacker story usually describes the loop. It talks less about the life required to run the loop long enough.

You need time after work. You need enough savings to survive slow feedback. You need low fixed costs. You need the ability to sell. You need English if your market is international. You need a topic where you can reach buyers. You need health. You need a way to handle taxes, invoices, support, privacy, legal risk, and customer trust. You need the emotional tolerance to publish something imperfect in public.

Some people have those inputs. They may not call them privilege. They may call them discipline, taste, consistency, or obsession. Sometimes those words are true. Sometimes they hide the balance sheet.

Building from Spain made that visible to me.

I am not saying Spain has no startup scene. The data says the opposite. The [Spain Tech Ecosystem Report 2026, covered by Cinco Dias](https://cincodias.elpais.com/companias/2026-05-12/el-ecosistema-espanol-de-start-ups-tecnologicas-supera-los-125000-millones-un-14-mas-con-la-revolucion-de-la-ia.html), put the value of Spanish tech startups at 125 billion euros in 2025, up 14% from 2024. Spanish startups raised 3.1 billion euros in venture capital that year, up 63%.

The [GEM Spain 2025/2026 profile](https://www.gemconsortium.org/economy-profiles/spain-2) also shows growth: entrepreneurial intentions rose from 11.2% to 13.8%, early-stage entrepreneurial activity rose from 7.2% to 7.8%, and established business ownership rose from 6.8% to 7.4%.

So the macro story is not collapse. The Spanish startup scene is stronger than it was when I started looking at this seriously.

The individual math can still be brutal.

The [INE salary decile data for 2024](https://www.ine.es/dyngs/Prensa/dsEPA2024.htm) puts the average gross monthly salary in Spain at 2,385.6 euros. The [INE wage structure survey](https://www.ine.es/dyngs/INEbase/en/operacion.htm?c=Estadistica_C&cid=1254736177025&idp=1254735976596) puts the average annual salary at 29,540.26 euros. Those are averages, with regional and gender differences inside them. They do not automatically translate into runway.

Eurostat says the [EU household saving rate was 14.5% in 2024](https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Households_-_statistics_on_income%2C_saving_and_investment), while Spain was at 12.7%. That is an aggregate. It says nothing about a specific person's rent, family situation, debt, immigration history, health, or support network.

This matters because "just build on the side" is not a neutral sentence.

If you are a salaried engineer and you try to build a serious business at night, you are asking one body to carry two jobs: the job that pays the bills and the job that may or may not exist later. If you add freelance work, the pressure gets worse. If you become self-employed too early, you add administration and fixed obligations before the product has earned them.

I lived too much inside that trap.

I wanted the independence story. I also needed the salary. I wanted to build products. I also needed to recover after work. I wanted to launch. I also knew that launching creates support, expectations, security questions, pricing questions, tax questions, and a new identity you have to maintain in public.

The loop became familiar: finish paid work, open the private repo late, clean one more piece of the system, and call that progress because the code was less embarrassing than the product.

So I stayed too long in the engineer's refuge: make it better before it has to be judged.

## What I actually failed at

I have tried many things since 2018.

Some were too early. Some were too vague. Some were technically interesting and commercially lazy. Some had a real problem but no route to buyers. Some were personal tools pretending they could become products. Some were killed by context switching. Some were killed by the need to keep earning a salary. Some were killed by my lack of complementary skills at the time.

The technical skill was there earlier than the business skill.

That is painful to admit because programmers like the world where the difficult thing is implementation. Implementation is hard, but at least it gives you a private enemy. A compiler gives a clear failure. So does a test or deployment log. The market often answers with silence, and silence is harder to parse.

For years I kept sharpening the part of the stack I already respected.

I became better at code, systems, architecture, automation, AI workflows, retrieval, harnesses, content pipelines, observability, and local tools. That work was not wasted. It is probably the reason I feel more complete now. I can do things today that I could not do in 2018.

The missing part was exposure.

I did not expose enough products to people with money, urgency, and a reason to care. I did not repeat enough sales conversations. I did not put enough rough work in front of the market. I waited for internal coherence before external contact. That is a very technical way to avoid embarrassment.

I can dress it up with constraints, and the constraints were real. Spain, Europe, salaries, taxes, timing, exhaustion, English, distribution, mental load. All real.

The harder sentence is still there.

I built too many things that proved I could build.

That is not entrepreneurship. That is a private portfolio with nicer architecture.

[Nahuali](https://github.com/Arakiss/nahuali) is the cleaner example. I have been building it this year as a public project, but mostly in silence. That contradiction matters. I made the work visible on GitHub while still avoiding the louder parts of building in public: positioning, repeated updates, asking who it is for, and letting other people judge whether it deserves attention. Even there, a repo proves work. It does not prove demand.

There are private attempts I am not naming because they were never real enough to deserve a public post-mortem. That is part of the embarrassment.

## Distribution

Distribution is the word I did not understand well enough.

In 2018, I thought distribution meant being visible in the places where indie hackers were visible: Product Hunt, Hacker News, Indie Hackers, Reddit, Twitter, newsletters, small blogs, Slack groups, directories, SEO pages, maybe a few cold emails if the product was B2B. Some people could make that work because they already had an audience, a clear niche, a product that people understood in ten seconds, or the stomach to repeat the same message until the market answered.

For me, distribution was more abstract. I knew I needed it. I did not know how to make it part of the product from the first day.

Exposure and distribution are related, but they are not the same thing. Exposure is the act of making the work visible. Distribution is a path that repeatedly brings the work to people with a reason to care. A blog post is exposure. A site is exposure. A repo is exposure. A launch is exposure. Distribution begins when those things connect to a market, a community, a search intent, a painful workflow, a buyer, a channel, or a loop that can repeat without begging the internet for attention every time.

That distinction explains a lot of my avoidance.

For years I wanted to write a blog or rebuild my site properly. I also avoided it for years. Some reasons were practical: no time, no clear positioning, no product worth pushing, no confidence that the pages would reach anyone. Some reasons were more personal: I did not want to look like I was selling myself, I did not want to sound like a founder character, I did not want to publish in English and then be exposed as someone who still struggles in conversation.

Writing online does not magically create an audience. It creates a public surface that can be ignored.

SEO had that problem in 2018 and has it harder in 2026. Even in the old version, ranking a new site meant technical hygiene, search intent, useful pages, links, time, and trust. [Google's own SEO guide](https://developers.google.com/search/docs/fundamentals/seo-starter-guide) frames SEO as helping search engines understand content and helping users decide whether to visit. Its [guidance on helpful content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) is even more blunt: content should be made for people, show original value, and demonstrate experience or expertise instead of existing only to manipulate rankings.

The 2026 version adds a harsher layer. [SparkToro's 2024 zero-click study](https://sparktoro.com/blog/2024-zero-click-search-study-for-every-1000-us-google-searches-only-374-clicks-go-to-the-open-web-in-the-eu-its-360/) reported that 59.7% of EU Google searches and 58.5% of US Google searches ended without a click. Its [2026 update](https://sparktoro.com/blog/in-2026-less-than-one-third-of-google-searches-still-send-a-click/), using Similarweb data, put the first four months of 2026 at 68.01% of Google searches ending without a click. [Pew also found in 2025](https://www.pewresearch.org/short-reads/2025/10/01/americans-have-mixed-feelings-about-ai-summaries-in-search-results/) that 65% of US adults at least sometimes encounter AI summaries in search results, while only 6% of people who see them trust them a lot. Search is still useful. It is just less generous as a traffic machine.

So "write more" is incomplete advice.

The question is still where a piece of work can earn repeated attention.

I can say that distribution should be designed earlier than I wanted to admit. I cannot pretend that makes it comfortable. Before building, I should at least know who might care, where those people already look for answers, what proof they would trust, why they would believe me, and which artifact can travel without me performing online every day. That is the theory. The hard part is that every answer still leads back to exposure.

In 2026 the discomfort is worse because the public space is crowded with people trying to be seen. Builders, consultants, AI accounts, agencies, founders, investors, tool vendors. Everyone has a launch. Everyone has a lesson. Everyone has something to sell. The audience knows that, so every new post starts under suspicion.

A repo can travel if the docs solve a real developer problem. A post can travel if it is specific enough to be cited. A comparison page can travel if buyers already search for that choice. A small tool can travel if it plugs into a platform where people already browse. None of that removes the awkward part: somebody still has to put the work in front of other people.

For a solo builder in 2026, distribution might mean a very specific SEO page that answers a real problem better than generated content. It might mean a GitHub repo with usage examples and issues from actual users. It might mean a small newsletter, a direct relationship with five people who feel the pain, a serious Hacker News submission, a useful comment in the right community, a comparison page, a demo video, a marketplace listing, an integration, or cold email that starts from a concrete workflow instead of a founder pitch.

My position is smaller than the usual advice. I do not want to become loud. I also cannot stay invisible and call that entrepreneurship.

The only version of distribution I can currently respect is distribution with evidence: build from a problem I understand, publish the artifact, explain the constraint, show the failure modes, ask for specific feedback, and repeat in the few places where the audience is likely to care. Not everywhere. Not every day. Not as a badge of founder identity. Enough times that the work can stop depending only on my private belief in it.

That is not a solved answer. It is the part I still do not know how to do well.

## The launch recipe

The 2018 recipe, as I understood it, was simple enough to write on a wall:

- build a small product
- make a landing page
- launch on Product Hunt, Hacker News, Indie Hackers, Twitter, Reddit, or a niche forum
- write about the process
- show metrics if you had them
- get early users
- iterate until revenue appeared

That recipe was never false. It was incomplete.

It assumed the launch could create enough attention to start the learning loop. Sometimes it did. Sometimes the founder already had an audience, a network, a good niche, a low-cost life, clear English, a strong sense of buyer pain, or an unusually good instinct for where people gathered online. The recipe looked like a sequence of tactics. Underneath, it was a distribution and trust stack.

The 2026 recipe is less romantic, and I still do not know how to execute it cleanly.

For a new product, I think the distribution constraint has to appear before the code. That is different from feeling comfortable with it. Who can I reach without pretending? Where do those people already ask for help? What would they trust from me? What proof can I publish that a generated landing page cannot fake? What can I charge for early enough to learn from money instead of praise?

The problem is that this still requires being seen. It still asks me to interrupt people, to make claims, to ask for attention, to risk sounding like one more person selling a system, a course, a framework, or a dream. I hate that part. I do not have a clean answer for it.

If there is a recipe now, it may be smaller than the big reveal. One event inside a longer loop:

- pick a painful problem from earned context
- define the first ten reachable users or readers
- build the smallest artifact that proves the point
- publish proof: repo, demo, docs, trace, benchmark, comparison, post, or case study
- recruit users manually instead of waiting for traffic
- ask for money, usage, or a concrete rejection
- turn the answers into the next artifact
- repeat in the same few channels until a signal appears or the idea dies

That sounds less exciting because it is closer to work.

It also explains why my previous attempts failed before the market could reject them. I often built the artifact before knowing the path to the first ten serious users. Then I treated lack of distribution as a later problem. In reality, it was part of the product.

This is also where the old Silicon Valley advice still survives. [Paul Graham's "Do things that don't scale"](https://www.ycombinator.com/library/96-do-things-that-don-t-scale) is mostly about manually recruiting users at the start. [YC's advice to launch sooner](https://www.ycombinator.com/library/LG-why-startup-founders-should-launch-companies-sooner-than-they-think) says launches diagnose problems and find early adopters. The words are old. The implication is still uncomfortable: if I am avoiding manual exposure, I am avoiding the work that would teach me whether the thing matters.

So the launch recipe today is not "post everywhere." It is probably closer to this: try to earn one repeatable path to attention, prove something specific, and keep the loop alive long enough for reality to answer. I write "probably" because I have not solved this. I am describing the shape of the problem I avoided.

## What the market says

This is bigger than Spain. The [GEM 2025/2026 Global Report](https://www.gemconsortium.org/reports/latest-global-report) says startup activity is at record levels in many regions, based on more than 160,000 respondents across 53 economies. It also warns about a survival gap, where too few startups become established firms, and an AI readiness gap, where access to AI creates a two-tier entrepreneurial economy.

The United States has its own version. [Kauffman's 2025 report](https://indicators.kauffman.org/report/early-stage-entrepreneurship-national-2025) says the rate of new entrepreneurs was higher than pre-pandemic levels, while startup early survival was slightly lower than the previous year and lower than pre-pandemic levels.

Venture data points in the same direction. [CB Insights reported](https://www.cbinsights.com/research/report/venture-trends-2025/) that global venture funding reached 469 billion dollars in 2025, the highest level since 2022. Deal count still fell 17%. Mega-rounds captured 65% of total funding. The money came back, but it concentrated.

The world can have more startups, more AI tools, more capital, more examples, and still become harsher for a solo builder without distribution.

More supply makes attention less patient.

## 2026

AI made this sharper.

Software is cheaper to produce now. So are landing pages, logos, product videos, copy, demos, pitch decks, fake screenshots, fake authority, and founder content.

That does not make AI bad. I use it every day. Used well, it helps me research, code, translate, test arguments, inspect sources, build faster, and cut through work that used to take too long.

It also makes the costume cheaper.

In [the previous post](/blog/the-cost-of-sounding-human), I wrote that attention is becoming the hardest currency in the small builder internet. This is the entrepreneurship version of the same problem. When everyone can produce a polished artifact, polish stops being proof.

The AI application layer is real. [Menlo Ventures estimated](https://menlovc.com/perspective/2025-the-state-of-generative-ai-in-the-enterprise/) that enterprise generative AI spend reached 37 billion dollars in 2025, up from 11.5 billion in 2024, with 19 billion going to user-facing products and software built on top of underlying models. [Dealroom's AI tracker](https://dealroom.co/guides/ai/) puts AI startup funding at 216.1 billion dollars in 2025 and 256.5 billion in Q1 2026 alone.

There are real companies here.

There is also a flood of thin wrappers.

A thin wrapper can be built quickly because the model does the impressive part. That is fine for a prototype. It is weak as a business unless something else compounds: workflow ownership, private data, distribution, domain trust, integration depth, regulatory access, better UX, support, or a buyer who needs the problem solved inside a specific process.

In 2018, a solo builder could still feel early by shipping a polished niche SaaS. In 2026, the same builder may be competing against:

- a model provider adding the feature next month
- a funded AI startup buying distribution
- an incumbent bundling the workflow
- another solo founder shipping the same idea with better taste
- a hundred generated landing pages testing the same keywords
- readers who ask for proof before they give attention

The opportunity is still there. The required skill stack is wider.

## The wider skill stack

Technical skill remains necessary. It is just no longer enough.

The 2026 solo founder needs product judgment, taste, sales, writing, market selection, pricing, distribution, support, SEO, trust building, AI fluency, legal and privacy awareness, public feedback tolerance, and enough runway to avoid panic decisions.

Nobody has all of that at the start. The old indie-hacker loop was supposed to teach it through repeated exposure to the market.

That is the part I missed.

I tried to become complete before exposure. The market teaches some things only after you bring it something incomplete.

I can see that more clearly now because I finally feel closer to complete. I have stronger technical tools. I have more public writing. I have Nahuali as a visible attempt to build something in public, even if I have kept it too quiet. I understand that a product without distribution is usually an artifact. Writing online is also a trust test. AI should leave evidence, not remove the human residue.

The uncomfortable question is whether I learned this too late.

I do not think the answer is yes.

I think the old dream expired for me.

The version that still works for me is smaller and more concrete.

Do not build another product that only proves technical ability. Do not hide for months inside architecture. Do not publish like a founder character. Do not chase a market because AI made the prototype easy. Do not call something a company before it has customers, usage, or at least repeated external demand.

Pick problems where I have earned context. Ship earlier than my engineering instinct wants. Write in a voice that still sounds like me. Use AI heavily, but keep the evidence attached. Make public claims only where there is code, a shipped page, a source, a customer conversation, a failure, or a number behind them.

## Three routes

There are at least three routes here, and they should not be confused.

The US venture route is the YC-shaped route. It is built around speed, venture scale, investor density, peer pressure, San Francisco, and an expectation that the company can become much larger than a personal business. [YC's current standard deal](https://www.ycombinator.com/deal) is $500,000: $125,000 for 7%, plus $375,000 on an uncapped MFN safe. [The Fall 2026 batch](https://www.ycombinator.com/apply) is in San Francisco, with regular meetups, a dedicated General Partner, an alumni network, and investor introductions near the end of the batch. YC also says it invests in US, Canada, Cayman, and Singapore corporations, and that companies incorporated elsewhere may need to flip into one of those structures.

That route can be rational if the company needs capital, can grow fast, has a market large enough for venture returns, and the founder is willing to accept the legal, geographic, emotional, and dilution cost of that game.

It is a bad default if the goal is independence, €10K MRR, a calm micro-SaaS, a narrow European workflow, or a product that should survive through patient compounding instead of venture acceleration.

The European route is different. There is capital, talent, public support, and serious company building. There is also fragmentation, slower cross-border expansion, more regulatory surface, and a venture market that is selective. The European Commission would not need a Startup and Scaleup Strategy if the single market already behaved like one startup market. KPMG's Q1 2026 report says European VC activity stayed selective and concentrated in large, established companies. OECD's AI VC data says the United States attracted about 75% of global AI VC deal value in 2025, while the EU27 attracted about 6%.

That does not make Europe bad for founders. It changes the search space.

Europe can be better for problems where local trust matters, where regulation is a feature, where privacy is not a decorative checkbox, where language and procurement create barriers, where customers need boring reliability more than a Silicon Valley story. A European solo founder probably should not ask, "How do I look like a YC company?" The better question is, "Which painful problem do I understand here that a funded US company would ignore, misunderstand, or price incorrectly?"

Then there is my route.

I do not think my route is YC. I also do not think it is pure indie-hacker theater. The path that fits my constraints is closer to this: keep salary-funded runway, build from problems I have actually touched, use public open source as trust, use writing to explain the evidence, use freelance or service work to detect repeated pain, and only productize when the same problem comes back with money attached.

That is slower. It is less glamorous. It probably suits me better.

It still does not solve distribution. It only gives me a way to approach it without lying about who I am.

## Starting now from Europe

After that comparison, the practical path is clearer.

The [European Commission's Startup and Scaleup Strategy](https://research-and-innovation.ec.europa.eu/strategy/strategy-research-and-innovation/jobs-and-economy/eu-startup-and-scaleup-strategy_en) exists because the problems are visible at policy level: regulation, financing, market expansion, talent, infrastructure, and fragmentation. The Commission says the strategy has 26 actions across those areas, and in 2026 it also adopted EU-wide definitions and an EU Inc action meant to give innovative companies a more common legal frame.

That is useful context. It does not make a solo founder's distribution problem disappear. It also does not mean every project should start by looking for an accelerator, a grant, or a venture round.

The routes that make more sense to me are less theatrical, though none of them removes the need to be visible:

- keep a salary if it buys runway and avoids desperate product decisions
- use freelance or consulting work to find repeated pain, then productize only what repeats
- build open source where trust can accumulate through code, docs, issues, and real use
- build inside platforms or marketplaces when they already provide search, trust, payments, or a buyer habit
- pick narrow European problems where language, regulation, procurement, privacy, or local workflows are part of the moat
- use grants and accelerators only when the project actually matches them, not as a way to delay customers
- write and publish to create proof around the work, not to cosplay as a founder

The [EIC Accelerator](https://eic.ec.europa.eu/eic-funding-opportunities/eic-accelerator_en) is a good example of the difference. It can offer grants below 2.5 million euros and equity investment for startups and SMEs, but it is aimed at high-risk innovations with the potential to create or disrupt markets. The [2026 EIC work programme](https://eic.ec.europa.eu/eic-funding-opportunities/eic-2026-work-programme_en) puts 634 million euros into the Accelerator. That matters for deep tech. It is not the default path for a quiet solo builder trying to learn demand.

For me, the most credible path is probably a hybrid one: salary-funded runway, public open-source work, a small number of essays that make the work legible, and service-led discovery where the pain is real enough that someone would pay before the product is perfect.

That is not the clean indie-hacker dream. It is closer to how my life actually works.

## What I would tell the 2018 version of me

I would not tell him to stop.

I would tell him to launch uglier things.

I would tell him that code can become a place to hide. A product is not more serious because the internals are elegant. A small paid problem beats a beautiful architecture diagram. Writing about a project is part of building it, because unclear positioning is usually unclear thinking.

I would tell him to separate learning projects from businesses. Learning projects are allowed to be private. Businesses need contact with buyers.

I would tell him to stop waiting for a clean personal brand. Clean English, neat lessons, and smooth confidence are cheap now. Specific constraints cost more. So do real numbers, visible bugs, and awkward sentences that a person actually wrote.

I would tell him to respect money earlier.

Not worship it. Respect it.

Revenue, pricing, failed sales calls, refunds, and silence after launch all carry information. A project that never launches produces almost no market information. It produces self-knowledge, maybe. That has value. It is not the same thing.

## Where I am now

I am tired.

That should stay in the article because it is the least founder-coded sentence here. I am tired of pretending that building more is always the answer. I am tired of people selling the old dream without naming the hidden inputs. I am tired of AI wrappers that treat a prompt as a company. I am also tired of my own pattern of staying too long in the private phase.

I also do not want to quit.

This article is not a universal map for indie hackers. It is the record of my route: the failures, the avoidance, the technical growth, and the things I am still trying to learn as a person and as a professional. Someone else in my position might have moved faster. Someone else might have done worse. I cannot know. I only know that the target has to be defined honestly. It cannot be only the million-dollar number, the screenshot, or the borrowed story.

Failure did not make me an entrepreneur. It did make me a better professional. It taught me constraints, patience, systems, and the difference between proving skill and earning demand.

The future is also too unclear for clean slogans. Nobody knows what happens to small indie businesses, AI wrappers, service companies, or the larger companies that used to win with playbooks that now look old. AI doom is not a strategy. Pretending nothing changed is not one either. The only useful position I can defend is to keep looking, keep shipping smaller, keep learning where reality answers, and stop confusing preparation with progress.

If I never try, I never get to know what would have happened once I actually started trying.

At the same time, I am more prepared than I have ever been.

There is also a present problem I did not have in 2018. Public writing now passes through a fraud filter. I write in English because the market is mostly there. I am not fluent yet. AI can make my written English cleaner than my spoken English. That helps, and it creates a gap I do not like. If the writing gets too smooth, I can look like another AI-bro account: native-sounding, founder-shaped, maybe real, maybe just another mask.

So the constraint is simple. Use AI for research, editing, translation pressure, and checking arguments. Keep the evidence attached. Keep some human residue in the sentence.

I am not early to the indie-hacker myth anymore. I am late to that version. Good. It had too much theater in it anyway.

I do not have a clean answer. I am still learning how to be visible without becoming the kind of person I would block.

The version that still makes sense is quieter, and unfinished.

Build from earned context. Launch before the system feels complete if I can tolerate it. Use AI where it makes the work faster or sharper. Refuse the parts where it turns me into a mask. Treat distribution as part of the product, even when I still do not know how to do it well. Treat trust as a scarce asset. Keep the salary if the salary keeps the experiment alive. Stop copying stories whose inputs I do not have.

I no longer want to become the person I imagined in 2018.

I want to stop wasting what I learned while avoiding the market.