What happens when most human labor is no longer needed?

Not the soft version, where tools make people a bit more productive. I mean the harder version. Machines and models run factories, logistics, back offices, customer support, large parts of software, and eventually much of the physical world too. Output is abundant. Human effort is optional in more and more domains.

Most discussions about this future stay stuck on jobs. Which jobs will survive? Which skills will still matter? Which professions are “safe” from AI?

That is the wrong center of gravity.

If labor stops being the main way people earn a living, the real questions are different. Who owns the machines? Who captures the rents? Who decides what automated systems are allowed to do? What happens to money, school, and meaning when work is no longer the organizing principle of life?

That is the conversation worth having.

The real problem is not production

If machines can do almost all work better and cheaper than humans, the economy does not first run into a production problem. It runs into a distribution problem.

A society can produce huge amounts of goods and services and still become unstable if most people no longer have purchasing power. Output alone is not enough. People need some claim on that output.

From there, three broad futures appear.

1. Managed abundance

Automation drives prices down across much of the economy. People do not rely mainly on wages anymore. Instead, purchasing power is preserved through some mix of dividends, public transfers, citizen funds, pension ownership, or other ways of recycling automation rents back into society.

In that world, markets still exist. But they float on top of a guaranteed floor. People are not fighting for basic survival. They are competing over location, prestige, access, experiences, and taste.

This is the most stable version of an automated future. It requires broad ownership, or at least broad participation in the gains.

2. Forced redistribution

If ownership stays concentrated, automation profits accrue to a narrow capital base while labor income erodes. The economy can still produce plenty, but demand weakens because too many people are cut out of the upside.

Eventually, governments intervene under pressure. Taxes rise. Windfall levies appear. Controls, subsidies, and emergency transfers spread. Redistribution happens, but late, unevenly, and with a lot more conflict than it needed to.

3. Collapse

If concentration combines with weak institutions, energy shocks, political breakdown, conflict, or catastrophic system failures, things get darker. The problem is no longer just inequality. It becomes institutional failure.

Supply chains break. Energy becomes unreliable. Trust drops. Black markets expand. Formal rules give way to local improvisation.

The most likely global outcome is not one universal model. It is a patchwork. Some places manage abundance well. Some lurch through forced redistribution. Some fail.

We are not there yet

None of this is inevitable, and none of it is fully here.

We are still in the early displacement phase.

Software and knowledge work are automating quickly. Text, media, support, analytics, and parts of programming are already being transformed. Physical work moves more slowly, because robotics still depends on sensing, dexterity, integration, energy, and cost curves that have not yet broken wide open.

That matters. It means we are not in a post-labor world today. We are in the messy middle, where some tasks disappear, some expand, and institutions lag far behind the capabilities of the tools.

This is why so much of the current debate feels confused. People are arguing from a future that has not fully arrived, while living inside a transition that is already destabilizing.

Do we still need money if everything is abundant?

Probably yes.

Money exists because scarcity exists and barter is inefficient. If automation drives the cost of many goods toward zero, then the role of money shrinks in those areas. But scarcity does not disappear completely.

Some things remain scarce no matter how smart machines get.

Land stays scarce. Prime locations stay scarce. Reliable energy stays scarce. Compute at the highest level stays scarce. Time, attention, trust, and status all stay scarce.

So even in a world where food, entertainment, and many services are cheap or effectively guaranteed, some system is still needed to allocate the scarce parts. It may look like money. It may look more like energy credits, compute credits, access rights, or priority tokens. But the underlying logic survives.

Trade does not disappear. It shifts.

Instead of being mainly about survival, more of it becomes about differentiation. Better location. Better access. Better curation. Better experiences. Better reputation.

Why school breaks when it is built for workers

Modern mass education was shaped by the needs of industrial society.

Show up on time. Follow instructions. Sit still. Learn standard material. Move through a pipeline. Become a useful worker.

That model was always narrower than it pretended to be, but automation makes the mismatch impossible to ignore.

If tasks change faster than curricula, and if machines outperform humans at routine execution, then education cannot be mainly about preparing people for fixed jobs. It has to prepare them for agency.

That means the center of education shifts toward:

• reading, writing, argument, and media judgment
• probability, statistics, optimization, and decision-making
• computation, data, and AI literacy
• scientific thinking and causal reasoning
• ethics, safety, institutions, and law
• collaboration, leadership, and conflict resolution
• building real things, testing them, defending them, and improving them

In an automated world, a serious project is no longer just “build something.” It is “design and govern an autonomous system for a real stakeholder.”

What is the goal? What are the constraints? What can it do automatically? What needs approval? What happens when it fails? Who is accountable?

That is a much more durable education than training someone to fit into a job ladder that may no longer exist.

“AGI can do all that too”

This is the strongest objection, and it is a good one.

If AGI or ASI becomes capable enough, why would it not also handle policy, ethics, governance, curation, and crisis response? Why assume humans remain central in any of those domains?

At the level of capability, it might not be wrong. Super-capable systems could model consequences better, search policy options better, and outperform humans in many kinds of judgment.

The important distinction is not capability. It is legitimacy and responsibility.

Even if a system can do everything, three gaps remain.

First, the objective gap. What should the goal be? How should different values be weighed? How should tradeoffs be made between freedom and safety, equality and efficiency, speed and fairness? There is no single objective answer waiting to be discovered.

Second, the legitimacy gap. Who has the right to decide? Authority does not come from intelligence alone. It comes from consent, process, and accepted rules.

Third, the responsibility gap. When harms occur, who answers for them? Who pays damages, gets removed, loses power, or is held accountable?

AI can propose goals, model outcomes, and even recommend tradeoffs. But it cannot, on its own, grant itself legitimate authority. It cannot be the ultimate source of political or moral permission unless humans first decide to hand that over.

That means the enduring human role is not “doing the work the machine cannot do.” It is being the legitimate principal of systems that do the work.

That includes writing the charters, setting the red lines, defining rights, deciding where discretion lives, and owning the consequences when things go wrong.

So do we all just become governors?

Not exactly.

If legitimacy remains human, then yes, society becomes more governance-heavy than it is today. But that does not mean everyone lives in assemblies all day.

A more plausible model is governance by default, service by choice.

Everyone holds basic rights and some light civic duties. You may vote occasionally on major questions. You may update your preferences. You may do rare jury or panel duty.

A smaller share of people, for a limited time, does deeper service through sortition, election, or appointment. They sit on standards boards, audit panels, or citizen assemblies. Their terms are short. Their power is constrained. Their decisions are logged and reviewable.

Professionals still exist too. Energy systems, health systems, biosafety, city management, and critical infrastructure all need competent operators. But those operators increasingly work under tighter charters, stronger audits, and more explicit public legitimacy.

Automation supports all of this. It drafts, simulates, checks compliance, summarizes tradeoffs, and keeps logs. Humans do not process every detail manually. They remain the ones who authorize, constrain, and answer.

What do people do with all the free time?

This is where the conversation often gets strangely shallow.

People say, “If work goes away and needs are covered, then everyone will just do what they love.”

Maybe. But we already live in a world where many people have some free time, and a large part of that time gets absorbed by low-effort, high-engagement loops. Infinite feeds. Endless videos. Passive entertainment. Doomscrolling.

So abundance alone does not automatically produce flourishing.

The scarce things in an abundant world are not just material. They are psychological and social. Time. Attention. Taste. Trust. Belonging. Meaning. Status. Real challenge.

This suggests that life after work is not organized around a job, but around a portfolio of meaning.

Some combination of:

• creation, making art, tools, research, or public artifacts
• care, raising children, supporting family, mentoring, coaching
• stewardship, maintaining places, systems, commons, archives, habitats
• discovery, learning, science, travel, field work, serious curiosity
• governance, your share of collective decision-making and institutional maintenance
• play, sport, ritual, games, celebration, competition

The key problem is not lack of options. It is lack of self-chosen constraint.

Without structure, abundance can dissolve into drift. With structure, it can become a civilization of creation, care, stewardship, and play.

The doomscrolling objection is real

There is no point romanticizing this.

A lot of people do not naturally move from easy consumption into mastery, contribution, or harder forms of play. Today’s platforms are designed to prevent that. They are built around variable rewards, infinite scroll, social proof, and low-friction repetition.

Boredom alone does not beat design.

If society wants more people in active modes rather than passive loops, it will need counter-design.

Less autoplay. More friction on passive feed loops. More small on-ramps into active participation. More social scaffolding. More visible ladders tied to outputs, not time spent consuming. Better rituals. Better communities. Better default environments.

This matters for education too. A future-ready curriculum should not just teach people how to use powerful systems. It should also teach them how their own attention is being captured, and how to build lives that are not consumed by passive stimulation.

What to do in the next five years

All of this is philosophical until it becomes practical.

If you want to benefit from this transition over the next five years, the strongest immediate lever is not some abstract future job category. It is agents and automations.

Not as hype. As real systems that save time, reduce errors, and operate inside clear guardrails.

A good starting move is simple.

Pick one narrow digital workflow. Map it end to end. Measure the current baseline. Then build an automation around it with a minimal architecture.

A trigger. A planner. Deterministic tools. Guardrails. Human approval for risky actions. An executor. An audit log. A rollback path.

Run it in shadow mode first. Then deploy it on a safe slice of real work. Measure hours saved, intervention rate, defect rate, and user trust.

If you can prove, in concrete terms, that a workflow now takes less time, makes fewer mistakes, and stays under control, you have something valuable.

Do that a few times and you are no longer just “using AI.” You are learning how to design and govern autonomous systems, which is one of the most useful skills in this transition.

At the same time, build around the bottlenecks that stay scarce.

Accumulate some exposure to broad equity, infrastructure, energy, and compute. Build small datasets with clear rights. Build distribution you control, such as an email list, community, or niche audience. Build a reputation for trustworthy work, not flashy demos.

And build your governance muscles.

You do not need to become a politician. But it helps to get comfortable with contracts, licenses, data rights, privacy, risk, and the basic mechanics of allocating scarce resources fairly.

The future likely rewards people who can set objectives clearly, constrain systems responsibly, and be trusted when something breaks.

The real shift

If automation keeps advancing, then the center of gravity moves.

From doing tasks, to deciding what should be done.

From competing on labor, to participating in ownership and stewardship.

From following systems, to governing them.

From organizing life around jobs, to organizing it around meaning, responsibility, and chosen forms of contribution.

That does not mean humans become irrelevant. It means the basis of human relevance changes.

The question is not whether there will still be something for people to do.

There will be.

The question is whether we design a society where people have a real claim on abundance, real legitimacy over the systems that shape their lives, and enough structure and purpose to do something better with freedom than merely scroll through it.

That is the real future-of-work debate.

It is not really about work at all.

Most people treat metrics like Domain Rating and Domain Authority as if they measured real world authority. A tool shows a number from 0 to 100 and it feels like a direct representation of how much Google trusts a site.

That is not what these metrics actually are.

In this post I will explain what DR and DA really measure, why they are structurally biased toward big brands and old sites, and why even Google itself has moved far beyond simple link based thinking. I will also explore a thought experiment for a different kind of search system where users have explicit power over rankings instead of everything being controlled by a black box.

What DR and DA really measure

Domain Rating from Ahrefs and Domain Authority from Moz are both proprietary scores. They look similar on the surface. You get a number between 0 and 100 and higher is better. They are also logarithmic, which means that moving from 10 to 20 is much easier than moving from 70 to 80.

Under the hood both metrics are basically trying to answer one question.

How strong is this site in terms of backlinks compared to everything else in our index.

They do not look at your content quality. They do not know how fast your site is. They do not see your conversion rate. They do not know how real users behave on your pages. They are only modeling links.

The tools crawl the web and build their own independent link graphs. Then they estimate the relative strength of each domain based on how many other domains link to it, how strong those domains are, and how generously they link out. That last piece matters more than most people think.

Why the best links often come from stingy sites

If you read the original PageRank paper you will find a simple idea at the core of the algorithm. Each page can pass on only a limited amount of value through its outgoing links. The more links it has, the less value each individual link can carry.

Most modern link based metrics behave in a similar way because the idea is still valid.

A link from a page that has three hand picked outbound links is worth much more than a link from a page that links out to fifty random sites. The first is selective and editorial. The second looks like a directory or a link farm.

In practice this means that the best links often come from sites that rarely link to anyone. Think of small but respected niche publications, professional associations, or individual experts in a field. They may not have the highest DR in your tool, but when they do link to you it sends a strong signal.

The limitations of DR and DA

Once you understand that DR and DA are just relative backlink strength scores, their limitations become obvious.

First, they are biased by the tool index. Ahrefs sees a different portion of the web than Moz. If a link is not in their index, it does not exist for the metric.

Second, they are one dimensional. They collapse everything into a single number that ignores on page quality, user behavior, technical health, brand, and intent matching.

Third, they are relative and moving. If the overall web graph changes, your number can move even if you do nothing. When another site gains or loses powerful links, it shifts the scale a bit for everyone.

Fourth, they are easy to misinterpret. People celebrate small jumps as major wins and feel stuck when the metric does not move, even while their real traffic and rankings do.

None of this makes DR or DA useless. It simply means they are rough diagnostic tools rather than a measure of true authority.

How Google likely models links today

Google still uses ideas that look like PageRank, but they are embedded in a much more complex system.

Links are no longer treated as generic votes.

A modern link signal is probably weighted by several factors at once.

Who is linking. Is the source part of a trusted seed set, and is it close to other known authorities.

About what. How topically relevant is the linking page and its domain to the target. Two sites in the same niche likely reinforce each other more than a random cross niche link.

From where in the page. An in content editorial link carries more weight than a footer or sidebar link.

How many other links are present. The stingy versus generous site behavior appears again.

How users behave. Do people actually click the link. Do they stay on the destination page or bounce right back to the search results. Does the link appear on pages that users generally trust.

How stable the link is. A link that exists for years and keeps sending traffic looks more natural than a short lived spike that appears and then disappears.

On top of this, Google has moved to entity based and semantic models. Instead of just matching text strings, it tries to understand which entities and topics a site is about and how they relate to each other across the web.

Why this favors big brands and incumbents

All of these layers create structural advantages for large, established brands.

Big brands are often part of the trusted seed sets in link based models. Government sites, major media companies, large universities, and leading associations all sit very close to the center of the trust graph.

They collect links naturally simply by being known. Journalists link to them. Bloggers reference them. People search for the brand by name, which further trains the system that this site is trustworthy and relevant.

They also have enormous behavioral data behind them. Many users click their results by default. They rarely look suspicious in terms of link velocity or anchor text, because the mentions are organic.

New sites have the opposite starting position.

They sit far away from the trust center. They lack branded searches. They have very little historical behavior. Any active link building they do looks more like promotion than like passive earning, which makes it easier for algorithms to discount low quality efforts.

From the point of view of a risk averse search engine this bias is rational. If the choice is between sending users to a known brand with a long track record, and a fresh unknown domain with a handful of links, the safe bet is obvious.

The price is that it becomes much harder for new players to break through, even when they are objectively better.

Is there a search model where users really decide

If Google and similar engines are structurally biased toward incumbents, it is natural to ask whether there is a different model where users have more explicit control over what ranks.

Social platforms are one partial answer. Reddit, StackOverflow, YouTube, and TikTok all use some form of user feedback to rank content.

Votes, likes, watch time, comments, and shares all shape what surfaces. This makes it easier for new content to break through and for communities to curate what matters to them.

However, these systems work inside closed platforms. They do not operate on the open web at the scale that Google does.

A thought experiment user governed search with one scarce vote

Imagine a search system that tries to bring some of this community power into web search.

Every user has a verified profile. There are no anonymous accounts and no easy bot swarms.

Every user gets one meaningful vote per month. Not per query and not per page, but one unit of scarce approval they can assign anywhere on the web.

If you use your vote on a page, you are saying that this page really helped you and that you want more people to find it.

Over time some pages and sites would accumulate these scarce votes. The search system could combine its own relevance and quality models with this thin but highly trusted signal.

Pros of this model

Scarcity forces seriousness. With only one vote per month, most people will not waste it on mediocre content or on manipulative campaigns.

Verification makes spam much harder. Votes would be tied to real humans, or at least to strongly verified identities, which removes whole categories of cheap manipulation.

It creates a public web of trust. Everyone can see which pages and sites have earned support across many independent users.

It rewards depth over volume. Publishers cannot brute force their way to visibility with hundreds of thin pages. They need a smaller number of truly excellent resources that people feel compelled to support.

Cons and challenges

Verification is hard. A global system that verifies everyone raises privacy, political, and logistical problems. Someone has to decide what counts as a real person.

Cold start is severe. New sites begin with nothing and might struggle to get early visibility in order to even earn votes. Early winners could lock in their advantage.

Herd behavior is real. Even with scarce votes, people might follow influencers or social pressure instead of their own judgment. Popularity could still dominate quality.

Most users will not participate deeply. Many people simply want answers and will never bother to spend their vote, or will use it randomly at the end of the month.

Global search scale is brutal. This kind of governance is far more realistic for smaller vertical search engines than for a universal one that indexes the entire web.

Where a user governed model could work

Although this system is unlikely to replace Google, it could work very well in narrower domains where expertise and trust matter more than breadth.

Examples include medical information, legal research, scientific literature, niche professional communities, and internal company knowledge bases.

In those contexts verified participants have strong incentives to protect quality and reputation. The index is smaller. The community is more coherent. A scarce vote has more meaning.

Practical takeaways for people doing SEO today

First, treat DR and DA as useful but limited diagnostic tools. They can help you compare backlink profiles at a glance and spot large movements, but they are not the score that Google cares about.

Second, assume that Google sees much more than your link tools do. It has its own link graph, its own behavior data, and its own semantic understanding of content and entities.

Third, accept that the system favors incumbents and design around it. New sites need sharper positioning, better content in narrower niches, and a focus on earning a few truly excellent links from highly selective and relevant sources.

Fourth, remember that at the end of the chain there is still a human. If you consistently create pages that solve real problems for real people, and do enough distribution for those people to discover and remember you, then over time every metric, including the proprietary ones, will reflect that reality.

It just takes longer than most dashboards suggest.

TL;DR

LinkTracker.info was a small side project I built as a link shortener and click tracker. It slowly grew to ~3,000 organic Google clicks over 12 months and ranked on page 1 for terms like "link tracker". Despite that SEO traction, usage and retention remained very low: 557 sign‑ups, 583 links created in total, and only 23 active users in the last 30 days.

A deep dive into usage showed that most of the volume came from adult/affiliate and spammy use cases I don’t want to support. The handful of legitimate small businesses weren’t enough to justify more development, marketing, or support.

I’ve decided to shut LinkTracker down. Existing short links will keep redirecting until April 30, 2026. After that, they will stop working. This post explains what I built, what actually happened, and why I chose to kill it instead of trying to turn it into a product.

Background: Why I Built LinkTracker

The original idea for LinkTracker was simple:

"Never share a link again without knowing if anyone has clicked on it."

I wanted a lightweight, privacy‑respecting tool where you could:

• Shorten links.
• Track clicks per link.
• Organize links across campaigns.

There are many link shorteners and analytics tools already, but I thought there was still room for something simple, clean, and focused on indie founders and small businesses.

I built it as a side project and deployed it on Vercel’s hobby tier. The app had:

• Email magic‑link authentication.
• A basic dashboard with a table of links.
• A simple click counter for each short URL.
• A presentable marketing homepage.

Then I mostly left it alone.

What Actually Happened

Because I never wired up proper product analytics, the only reliable external data source I had was Google Search Console (GSC).

SEO Performance

Over the last 12 months, GSC reported:

• 3,040 clicks
• 32,300 impressions
• Average CTR around 9–12%
• Average position improving to about 7.4 in the last 28 days

Most of the traffic came from a single family of queries:

• "link tracker" – 2,207 clicks, 22,537 impressions (12‑month window)
• "linktracker" – 504 clicks
• plus various typos: "link traker", "linktracer", "tracker link", etc.

So SEO‑wise, LinkTracker accidentally did pretty well for a neglected side project.

Product Usage Metrics

Looking inside the app database, the core stats at shutdown time were:

• Total registered users: 557

• Users who created at least one link: 314

• Total links created: 583

• Active users (last 30 days): 23

  • Here, "active" means they created at least one link in that period.

Some quick implications:

• About 56% of sign‑ups ever created a link at all (314/557).
• The average is only 1.86 links per user among those who used it at least once.
• Only 4% of all sign‑ups (23/557) were active in the last month.

In other words, most people tried the product once, created one link, and never came back.

Onboarding Friction

My onboarding flow didn’t help:

• To use the tool, you had to sign up first via email magic link.
• Only after confirming your email could you see the “enter URL and shorten” form.

For a utility tool discovered via a query like "link tracker", this is the wrong order. People want to paste a URL and immediately see something happen. I made them commit before showing any value.

We discussed the idea of flipping this flow (public "paste URL → track" without signup) to test whether conversion would grow from ~6% to something more meaningful. But by the time I looked at the data and the type of users coming in, the conclusion was that the underlying product wasn’t worth that experiment anymore.

The Power User Deep Dive: Who Was Actually Using It?

I pulled the top 10 "power users" by click volume and inspected their domains and patterns. That analysis split them into two main groups.

1. Adult / Affiliate / SEO Spam Cluster

Several users:

• Used email addresses that look like throwaway accounts.
• Created multiple links to domains like nakedmilfs..., loosegirlsh..., naughtytrashy....
• Rotated through 5+ domains per user.
• Showed a suspicious traffic geography pattern: US (~60%) → Korea → Singapore → Germany.

Another pair of users drove thousands of clicks to gibberish domains like liservantuid.com, mistfabulous.com, exhibiting the same geo pattern.

These accounts were almost certainly:

• Affiliate arbitrage.
• Automated traffic.
• Link farms / spam networks.

They produced a large portion of the total click volume, but they are not the kind of "customers" I want or can monetize safely.

2. A Few Legitimate SMB / Creator Users

There were a handful of "real" users:

• A car rental / sales business in Chiang Mai with one link and 19k+ clicks.
• A few real estate or local business use cases.

These looked like genuine small businesses using LinkTracker in the way I originally imagined: one or a few core links with trackable clicks.

However, there were very few of them, and they were not on any paid plan (there was no pricing at all).

3. File‑Sharing / Piracy‑Like Usage

One user drove thousands of clicks to mega.nz and YouTube. This likely involved sharing large files or questionable content. That’s another risk category I’m not interested in building a product around.

Infrastructure, Performance and Reliability

LinkTracker ran on Vercel’s hobby plan. Usage stats over a 30‑day window looked like this:

• ~89k edge requests
• ~18k function invocations
• 1.5% error rate over a 6‑hour slice
• Firewall logs showing thousands of bot challenges and a hundred+ denials

In practice, that meant:

• The app sometimes felt slow or returned HTTP 500 errors.
• Bot traffic and abusive usage were already putting pressure on a hobby‑tier setup.

I could have invested time in:

• Better logging and error handling.
• Rate limiting.
• Bot protection and blocklists.
• Possibly upgrading the plan.

But those are only worth solving if the product itself is promising. The usage and user mix said otherwise.

Why I Decided to Shut It Down

1. Weak Retention and Engagement

Despite ranking for high‑intent queries and getting hundreds of visits per month, the core metrics were poor:

• Only 23 users created a link in the last 30 days.
• Most users created one link ever and never came back.
• There were no signs of a healthy base of legitimate power users.

These numbers are not the foundation of a sustainable SaaS, and they hadn’t budged in a long time.

2. The Wrong Kind of Power Users

The bulk of my "traffic success" came from use cases I don’t want:

• Adult content.
• Spammy SEO networks.
• Possible piracy/file‑sharing traffic.

I could try to combat this with heavy moderation, abuse detection, and legal risk management, but that’s not why I build products.

3. Crowded Market and No Clear Differentiation

The link tracking space is crowded:

• Bitly, Rebrandly, and many others cover basic shortening.
• More advanced tools provide deep analytics, integrations, and branded domains.

LinkTracker didn’t have a sharp, differentiated angle. It was "another link tracker" that required signup first, and I never invested enough to make it stand out.

4. Opportunity Cost

Every hour I might spend fixing LinkTracker is an hour not spent on my more promising projects (like PrintOnDemandBusiness.com and other experiments).

Given the numbers, the right move is to stop, not to sink more time into a project that has already told me it doesn’t want to be a business.

5. Clear Decision Criteria

By the time I revisited LinkTracker, I had enough data to say:

• Organic traffic: decent.
• Retention & active users: poor.
• User mix: heavily skewed to abuse/spam.
• Path to monetization: very weak.

That combination met my internal threshold for a decisive shutdown rather than passive neglect.

How the Shutdown Will Work

I chose a graceful shutdown instead of simply killing it overnight.

• Effective immediately:

  • No new accounts.
  • No new links.

• Until April 30, 2026:

  • All existing short URLs keep redirecting to their original targets.
  • Users can export their links (short URL, destination, total clicks) as CSV and migrate elsewhere.

• After April 30, 2026:

  • Short URLs will stop redirecting.
  • They will instead show a simple shutdown page explaining that LinkTracker has been discontinued.

After a reasonable data retention period, I will:

• Delete or anonymize user accounts and link data.
• Decommission the Vercel project and database.
• Remove or repoint DNS for linktracker.info.

Users who rely on LinkTracker should move to another provider well before the cutoff date.

What I Would Do Differently Next Time

Looking back, there are several lessons I’m taking into future projects.

1. Start With a Narrow, Explicit Use Case

"Anyone who shares links" is not a target market. A better starting point would have been something like:

• "Real estate agents who want to track which listing links perform best."
• "Indie SaaS founders tracking clicks from their email signatures and social profiles."

Without a clear user story, the product naturally attracted the kinds of users who exploit generic tools: spammers and affiliates.

2. Show Value Before Asking for Commitment

For utility tools, the flow should almost always be:

Try → See value → Then sign up.

My signup‑first magic‑link flow reversed that and killed a lot of potential experimentation from legitimate users.

Next time I’d:

• Let anyone paste a URL and get a working short link.
• Show basic stats on a public or temporary page.
• Offer signup only to save history or unlock extra features.

3. Instrument Proper Analytics Early

Relying solely on Google Search Console was a mistake. I should have, at minimum:

• Tracked basic events:

  • Landing page views.
  • Link creations.
  • Signups after creating a link.
  • Returning users.

• Built a tiny dashboard with key ratios like:

  • links_created / visitors.
  • active_users / total_users.

With that in place, I would have had a clear signal much earlier that retention was weak.

4. Decide on Abuse Policy From Day One

Any product that can be used at scale for free will attract unwanted usage.

Next time, I will:

• Decide upfront what categories of usage I’m willing to support.
• Implement basic rate limiting and abuse detection early.
• Be prepared to block entire classes of domains or content.

5. Set Explicit Kill or Commit Milestones

I let LinkTracker sit in an undefined state for too long: not clearly alive, not clearly dead.

A better approach would have been to define milestones like:

• "If we don’t reach 100 legitimate monthly active users within 6 months of launch, we either pivot or shut down."

and then actually act on that.

Closing Thoughts

LinkTracker was never a big product. It was a side project that accidentally picked up SEO traction, attracted the wrong kind of power users, and never turned into something worth serious investment.

Shutting it down is the right decision. It frees up my time and attention for projects where the user base, usage patterns, and potential upside are much clearer.

I’m still glad I built it. It validated that I can rank a tool for a competitive keyword like "link tracker" with relatively little effort, and it reminded me how important it is to:

• Know exactly who you’re building for.
• Measure the right things.
• Kill projects decisively when they don’t cross the bar.

If you’re a LinkTracker user, thank you for trying it. Please migrate your links before April 30, 2026. There are plenty of good alternatives out there—and I’ll be focusing my energy on building things that are a much better fit for the kind of users I actually want to serve.

A post-mortem on my filler-removal app

1. Context

In early 2025 I built a web app that takes an audio recording, removes filler words like "um", "uh", and "äh", and outputs a cleaner version in the speaker’s own cloned voice.

Under the hood it used:

• A simple web frontend and backend (Bolt.new, Supabase, external APIs).
• Stripe for payments.
• A pay-as-you-go model via Stripe Checkout: users bought processing credits priced per minute of input audio, with no subscriptions.
• ASR (Whisper or similar) to transcribe and timestamp the audio.
• An LLM to remove fillers and light disfluencies from the transcript.
• ElevenLabs fast voice cloning to re-synthesise the cleaned text in the original speaker’s voice.

The goal was to offer podcasters and creators a simple way to sound more polished, without manual editing and without losing their authentic voice.

The app shipped. It technically worked. It got essentially zero traction.

This is a post-mortem of that project: what I thought would happen, what actually happened, and what I learned about AI audio, user needs, and distribution along the way.

2. Original Hypothesis

2.1 Problem Hypothesis

Belief

Podcasters and creators hate their own filler words and disfluencies. They would gladly pay for an automatic way to clean those up.

More specifically:

• Filler words make people sound unprofessional.
• Manual editing is tedious and time-consuming.
• Existing tools do some cleanup, but there is room for a dedicated and smarter product.

2.2 Solution Hypothesis

Belief

A web app that removes fillers and re-voices the cleaned script in the user’s own cloned voice is a valuable and differentiated product.

Key assumptions baked into that:

1. Full re-synthesis (TTS plus cloning) is better than surgical waveform editing.
2. Podcasters are okay with an AI version of their voice as long as it sounds good.
3. “Fewer ums” is a strong enough value proposition on its own.
4. It is fine that the product lives outside their main editing tools.

Most of these assumptions turned out to be either wrong or only partially true.

3. What I Actually Built

3.1 Product Shape

The shipped version allowed users to:

• Upload audio or record in the browser.
• Create a one-time voice clone via ElevenLabs samples.

The pipeline looked like this:

1. Transcribe audio with timestamps.
2. Use an LLM to clean the text, remove fillers, and fix some disfluencies.
3. Use ElevenLabs to re-synthesise the cleaned script in the cloned voice.

The output was:

• A new, polished audio file.
• Optional subtitles.

Under the hood it used a Bolt.new frontend, Supabase for authentication, storage, and edge functions, Stripe Checkout for credits, and ElevenLabs plus Whisper for the heavy lifting.

3.2 What Worked Technically

• The pipeline itself worked and the before-and-after difference was clear.
• Voice cloning was surprisingly good for short-form content.
• The infrastructure choices (Supabase plus external AI APIs plus Stripe) were fast to build and easy to operate.

I also learned a lot about:

• ASR → text → TTS chains.
• Latency, batching, and cost trade-offs.
• Voice cloning UX and consent considerations.

On paper, it was a nice project. It just was not a good product.

3.3 Timeline and Numbers

I built the first version over a couple of days for a hackathon. After that, I kept it online for a few months as a live experiment.

During that time:

• Traffic was in the low hundreds of visitors in total.
• Only a handful of people ever uploaded a file.
• No one converted to paid minutes.

I also shared it in a few niche communities and entered it into a hackathon. Nothing suggested there was a strong pull for this product in this particular shape.

From a numbers perspective, ClipClean never got beyond the stage of “toy used mostly by the builder”.

4. Why It Did Not Get Traction

4.1 The Problem Was Already “Good Enough” Solved

Most podcasters who care about filler words are already using tools like Descript, Cleanvoice, Podcastle, Adobe Podcast and others.

These tools:

• Remove fillers in one click.
• Handle silence trimming, noise reduction, compression and similar tasks.
• Live directly in the editing workflow.

For the average podcaster, the pain of “ums” is not large enough to justify:

• Cloning a voice.
• Uploading episodes to a separate app.
• Waiting for TTS re-synthesis.

Lesson: competing against “good enough” inside a user’s existing tool is much harder than it looks from the outside.

4.2 The Solution Was Heavier Than the Pain

The pipeline is objectively cool, but that was not enough.

Transcribe, clean text, re-voice in your own clone.

For most users this is a sledgehammer for a thumbtack:

• They do not need full re-synthesis to remove fillers.
• They are not actively asking for an AI replica of their voice.
• Many are happy with some imperfections, because authenticity matters more.

The result was technically impressive and practically overkill.

Lesson: just because something is technically possible and fun does not mean it maps to a strong enough user desire.

4.3 Wrong Default Target: Generic Podcasters

I implicitly optimised for a “generic podcaster” as the user:

• Hosts who want cleaner sounding shows.
• People annoyed by their own speech patterns.

In reality, this group splits into three subgroups:

1. Authenticity-first creators. They accept fillers as part of their style and removing everything actually feels wrong.
2. Process-heavy shows. They already have an editor or a solid editing workflow and they are not hunting for a new tool for one specific step.
3. Non-native speakers. This is the interesting niche, but the product and messaging were never focused squarely on them.

The one group where the idea does resonate is:

Non-native speakers who are self-conscious about sounding hesitant and would like more fluent-sounding audio in their own voice.

I never leaned fully into that niche and the product itself was not clearly designed or branded as a “speak more fluently in your second language” tool.

Lesson: a vague “for podcasters” target hides the one niche that might actually care enough.

4.4 The Video Story Was Weak

For audio-only content, timing is not a big problem.

For video, which is where many creators live, timing becomes much more important:

• Re-synthesised audio is shorter and differently paced.
• Lip sync breaks for talking heads.
• Fixing that properly means either editing the video to match the new audio, or generating a synthetic talking head that matches the TTS.

Both of those options are essentially entirely different products.

So the app was implicitly audio-only in a world where much creator output is video-first.

Lesson: full TTS re-synthesis and lip-visible video do not work well together unless you are willing to solve video as well.

4.5 Distribution Reality and SEO Check

There was also a distribution problem.

There is no real plugin marketplace for this kind of thing:

• Podcast hosts and directories do not expose audio-processing plugin stores.
• Descript, Riverside and similar tools do not have public marketplaces for third-party audio effects.
• Audio plugin marketplaces for VST or AU exist, but they are music-oriented and require a very different product shape.

There was no natural place to list it and get organic discovery. The app would have had to win attention the hard way, by manually reaching creators, running content, or building a full distribution engine.

I also did a sanity check on SEO. When I looked at search volumes for obvious queries such as “remove filler words from audio” or “podcast um remover”, demand was essentially non-existent. The organic search channel for this exact value proposition was close to zero.

Given that:

• The product did not live inside existing tools.
• There was no marketplace to piggyback on.
• SEO demand for the “remove ums” idea was tiny.

I did not invest heavily in further distribution, because the product–market fit signals were weak from the start.

I could have forced the issue with aggressive outreach, cold emails, paid ads, or content marketing. Given the weak pull, I decided not to spend weeks or months trying to brute-force adoption. The distribution story was not only hard. It also did not feel worth solving for this particular product.

Lesson: there is no distribution cheat code here. Either the product is embedded where work already happens, or it has to earn its own audience from scratch. Ideally SEO should at least tell you that there is an audience.

4.6 Even as an Asset, It Did Not Move

As a last step, I tried to sell the project as an asset (code plus domain plus pipeline) on a marketplace such as Flippa.

• It was pre-revenue, with no traction and a narrow use case.
• Interest was low and it did not sell.

That is another data point. Even among buyers who like small AI tools, a filler-removal app with no traction and no clear wedge is a hard sell.

Lesson: if both users and acquirers are lukewarm, the right move is to archive the project and keep only the parts that compound, such as skills, infrastructure patterns, and code.

5. What I Learned About AI Audio and Voice

Beyond the specific product, the project was a good deep dive into the current state of AI audio.

5.1 The Core Stack Is Mature

• Whisper-class ASR models are strong enough to drive production pipelines.
• Modern voice cloning, such as ElevenLabs, can produce convincing and on-brand voices with relatively little data.
• LLMs are capable of decent disfluency removal and light rewriting on real and messy transcripts.

This combination opens up many possibilities beyond “kill the ums”.

5.2 UX, Consent, and Expectations Matter

Working with cloned voices forces you to think about:

• How you obtain and store consent.
• How you communicate what is synthetic versus original.
• How much control users have over what is re-voiced and what stays real.

Some people are very comfortable with an AI version of their voice. Others are uneasy once they hear it. That alone changes how you need to design the product, the onboarding, and the defaults.

Lesson: with voice, the technical pipeline is only half the problem. The other half is comfort, expectations, and trust.

5.3 Timing, Alignment, and Human Perception

Small timing differences that do not matter for audio-only can be very noticeable on video.

I gained a much better intuition for:

• How tightly audio needs to track original pacing to feel natural.
• Where listeners are sensitive versus where they do not care.
• How important context (music, b-roll, or slides) is for hiding small desync.

These instincts are reusable for any future voice or dubbing product.

6. Opportunity: Pivoting the Tech, Not the Product

While this specific product did not land, the underlying machinery is reusable.

The stack I built – ASR → text → LLM → TTS with voice cloning and per-minute billing – can be a foundation for more promising directions, for example:

1. Multilingual dubbing

   • Take scripts or recordings and produce fluent voiceovers in multiple languages using the same voice identity.
   • Here full re-synthesis is a clear advantage, because you cannot just edit the original waveform.

2. Script-to-speech tools for founders and experts

   • Turn written content, such as blog posts, documentation, or newsletters, into narrated audio in the author’s voice.
   • This plays nicely with asynchronous content and does not fight existing editing workflows.

3. Internal "voice infrastructure" for future projects

   • Reuse the ASR → LLM → TTS chain as an internal component for other SaaS ideas.
   • Avoid solving auth, billing, file handling, and basic orchestration from scratch next time.

Each of these plays more to the strengths of the stack, without competing head-on with Descript’s filler-removal button.

The key shift is to focus on use cases where full re-synthesis is clearly an advantage, not an over-engineered way to solve a solvable editing problem.

7. Biggest Takeaways

If I had to condense the whole experience into a few points:

1. Distribution and workflow integration matter more than clever pipelines.

   • If you are not inside the tools people already use, you need a very strong and distinct value proposition.

2. “Technically impressive” is not the same as “emotionally compelling”.

   • Getting rid of “um” and “ah” is nice. It is rarely the thing people are desperate to fix.

3. Niches beat generic personas.

   • “For podcasters” was too broad. “For non-native speakers who want to sound more fluent in English” would have been more honest and more interesting.

4. Post-mortems are assets, not obituaries.

   • The code, the infrastructure patterns, and the learnings about AI audio are a toolbox. The fact that this particular product did not take off does not make the work wasted.

8. Closing

I did not get the outcome I imagined when I started this app. There is no neat MRR chart, no case studies from happy podcasters, no “we scaled to X users” story.

What I do have is:

• A tested, working pipeline for ASR → LLM → TTS with cloned voices.
• A much clearer mental model of the audio and podcasting tool landscape.
• A concrete reminder to validate distribution and workflow fit earlier.

That is enough to call the project a useful experiment, and a good foundation for whatever voice-related thing comes next.

For a long time, print-on-demand was the business model I wanted to crack.

On paper, it looked perfect. No inventory. Low upfront risk. Huge product variety. Global fulfillment. A business you could start without a warehouse, a team, or much capital.

So I did what many people in this space do. I launched stores. I tested niches. I uploaded designs. I tweaked listings, changed suppliers, adjusted pricing, watched competitors, and tried to make the economics work.

I made sales.

But I never built a POD store business that felt truly solid.

The margins were thin. Attention was hard to get and even harder to keep. Small changes in ad costs, platform algorithms, supplier pricing, or competition could wipe out what little momentum I had. Everything felt fragile.

At some point, the question changed.

Instead of asking:

How do I finally make this store work?

I started asking:

Where in this ecosystem does it actually make sense for me to stand?

That question changed everything.

It led me away from trying to win as just another seller, and toward building infrastructure around the industry instead. In my case, that became PrintOnDemandBusiness.com, a directory and research platform for print-on-demand suppliers and tools.

Same person. Same industry. Very different results.

This post is my attempt to explain why.

POD is not dead. But it is not what most people think.

Let me start with the obvious.

Print-on-demand is not dead.

People still buy custom products. Sellers still make money. Suppliers still process huge order volumes. Platforms like Etsy, Amazon, Printful, Printify, and others are not imaginary businesses.

So the conclusion is not:

There is no money in POD.

The more accurate conclusion is this:

There is money in POD, but it does not flow evenly.

And that is where most people get confused.

A lot of beginners look at the category and think they are entering a neutral market where good design and hard work are enough.

That is not really what is happening.

POD is an ecosystem with layers. And depending on where you stand in that ecosystem, the odds can look completely different.

The POD value chain

Once I stopped looking at POD only through the lens of my own stores, the industry became much easier to understand.

There is a stack.

1. The long tail of individual sellers

This is where most people start.

A few designs on Etsy. Maybe a Shopify store. Maybe Amazon Merch if they get in. Common niches like pets, travel, memes, jobs, hobbies, retro aesthetics, funny quotes.

This layer is noisy and crowded.

Most sellers make little or nothing. A few make decent side income. A very small minority build something meaningful.

The problem is not that these people are lazy. The problem is structural.

They are trying to sell into markets where:

• barriers to entry are low,
• competition is massive,
• attention is expensive,
• and products are easy to copy.

If you do not already have distribution, or a very strong niche angle, you are fighting uphill from day one.

2. Sellers with attention

This is a very different category of seller.

These are creators, brands, niche communities, influencers, or businesses that already have an audience.

For them, POD is not primarily a discovery engine. It is a monetization layer.

They do not depend entirely on Etsy search, Amazon search, or random Meta ads to survive. They can bring their own demand.

That changes everything.

If you already own attention, POD can be a great business model. You get low operational complexity, wide product variety, and fast merchandising without holding stock.

That is why some people genuinely do well with it.

But that does not mean the average new seller will get similar results.

3. Suppliers and fulfillment platforms

Then you have the fulfillment layer.

Printful. Printify. Gelato. And many more.

These businesses aggregate small margins across many sellers and many orders. They win by sitting in the flow of commerce rather than betting on one store or one design.

They still face pressure, of course. Competition is strong. Sellers compare prices aggressively. Some suppliers disappear. Others grow.

But structurally, this is a better position than being one more store owner trying to win a niche battle with a handful of listings.

4. Marketplaces

Then there are the real bosses.

Amazon. Etsy. Redbubble. The platforms that control buyer intent and default consumer behavior.

They own the search box. They own the traffic. They own the habit.

They get paid whether your product wins or your competitor’s does.

This is why new marketplaces struggle so much. Starting from zero attention and trying to compete with established buyer behavior is brutal.

5. Infrastructure around POD

This is the layer I eventually moved into.

Directories. Comparison sites. Tools. Agencies. Workflow products. Research platforms. Service providers.

In other words, the businesses that help sellers and suppliers make better decisions and operate more efficiently.

This is where PrintOnDemandBusiness.com sits.

I am not competing with sellers on design. I am not competing with suppliers on fulfillment. I am helping sellers discover suppliers and tools, while helping suppliers get found by the right audience.

Instead of being one more booth inside an overcrowded market hall, I am building a map of the market hall.

That is a very different business.

Attention is the real currency

Once you look at the industry through this lens, one pattern becomes very obvious:

Attention wins.

Not in a motivational-poster way. In a mechanical way.

Look at who consistently captures value in POD:

• marketplaces that own buyer traffic,
• suppliers that buy, borrow, or embed themselves into traffic flows,
• sellers who already have audiences,
• infrastructure businesses that become useful routing points inside the ecosystem.

What do they all have in common?

They are closer to attention than the average small seller.

That is the real difference.

Most struggling POD stores do not fail because the owner forgot some secret hack. They fail because they are trying to compete in a system where visibility is the bottleneck, and they do not control that bottleneck.

That was true for me too.

My stores did make sales, but I was never happy with the economics. I was constantly aware that the real constraint was not “can I make another design?”

It was:

• can I get the right people to see it,
• can I get them to care,
• and can I do that repeatedly at acceptable margins?

That is a much harder problem than most “start a POD business” content admits.

What changed when I moved up the stack

The biggest lesson from my own experience was not that POD stores never work.

It was that they were the wrong position for me.

My strengths are much closer to:

• structuring messy information,
• building systems,
• creating useful products,
• and thinking about markets as ecosystems rather than just storefronts.

Once I acted on that, things became clearer.

Instead of trying to squeeze better results out of thin-margin stores, I started cataloguing suppliers, tools, features, fees, regions, product categories, and integrations.

That turned into a structured directory.

That directory became PrintOnDemandBusiness.com.

And unlike my stores, PODB became profitable within months.

That result mattered to me because it isolated the variable.

Same industry. Same person. Same general knowledge base.

Different position in the value chain.

That told me something important:

In POD, where you stand matters more than how hard you grind.

Is POD still worth it?

Yes, for some people.

But not automatically, and not for the reasons most beginners hope.

I think POD still makes sense if one of the following is true:

You already have attention

If you have an audience, a brand, a niche community, a newsletter, a content engine, or some reliable way to put products in front of the right people, POD can be a strong monetization layer.

You want to learn ecommerce with low inventory risk

POD can still be a good learning vehicle. You can learn product pages, marketplaces, creative testing, customer behavior, supplier management, and basic operations without buying stock.

That has real value, even if your first store is not a great business.

You genuinely enjoy the creative side

Some people simply like making designs, experimenting with products, and selling to small communities. That is valid. Not every project has to be optimized for maximum leverage.

But if you are a founder looking for the best return on limited time, then the question gets sharper.

You have to ask:

Is my best move really to become one more small seller in a crowded market?

For me, the answer became no.

What I would ask if I were starting today

If I were starting from scratch in POD now, I would ask myself three questions early.

1. Do I have, or can I realistically build, attention in a niche?

Not vague hope. Real attention.

That could be SEO, content, short-form video, a community, an email list, paid traffic you can afford to learn with, or some other repeatable distribution channel.

If the answer is no, the path gets much harder.

2. Am I okay treating this as a learning project rather than a guaranteed business?

That framing matters.

If you treat POD as tuition for learning ecommerce, it can be very useful. If you treat it as your main financial plan from day one, it can become frustrating very quickly.

3. Given my actual strengths, is a POD store the right role for me?

This is the most important one.

Some people should absolutely build stores. Others should build tools. Others should offer services. Others should build media, directories, or infrastructure around the space.

A lot of wasted time comes from choosing the most visible role, not the one with the best fit.

Where I landed

I did not leave POD because I think it is fake.

I moved away from chasing store wins because I was not happy with the margins, the fragility, or the leverage.

What I found on the other side was a better fit.

By moving up the stack, I stopped trying to win one product at a time and started building something useful to the ecosystem itself.

That shift made far more sense for my skills, my goals, and my tolerance for operational grind.

So if you are in POD right now, or thinking about entering it, my advice is simple:

Zoom out.

Do not just ask whether POD works. Ask where the money flows. Ask who owns the attention. Ask what role actually fits you.

Because the answer might not be “start another store.”

For me, it wasn’t.

And recognizing that was one of the more useful business lessons I have learned in a long time.

Why most small teams should start server-first, stay modular, and stop confusing code boundaries with network boundaries.

A lot of teams say they want a composable architecture.

What they often build instead is distributed coupling.

They split the app into a separate frontend and backend early, push everything through HTTP, duplicate validation and state handling on both sides, and call it flexibility. In reality, they did not remove coupling. They just moved it into JSON payloads, API contracts, and deployment coordination.

That is not composability. It is overhead.

For most products, especially those built by small teams, a better default is much simpler:

• keep the app server-first
• keep the core logic modular
• keep most communication in-process
• extract separate services only when there is real operational pressure

This gives you a system that is easier to ship, easier to reason about, and still flexible enough to grow a new UI or new interfaces later.

The mistake: confusing code boundaries with deployment boundaries

This is the root confusion.

People see a clean architecture diagram and assume the boxes must be separate processes talking over HTTP.

They do not.

A boundary in code does not automatically mean a boundary over the network.

Those are two different questions:

1. Where should responsibilities be separated in the codebase?
2. Which parts actually need to be deployed and operated independently?

Most teams answer question two far too early.

You can have a well-structured, modular app where the parts are cleanly separated in code but still run inside one deployable system. In fact, that is usually the better starting point.

What server-first actually means

Server-first does not mean shoving business logic into templates and calling it a day.

It does not mean building a giant tangled monolith where controllers, views, and database models all leak into each other.

It means:

• the server is allowed to assemble the page
• the browser is not forced to become a second application runtime
• the core business logic is not tied to any one delivery surface

That last point matters most.

The goal is not “HTML everywhere forever.”

The goal is to keep the core of the app stable, while making it possible to attach different adapters around it.

Those adapters might be:

• server-rendered HTML
• a JSON API
• a background job
• an admin interface
• a CLI command
• a future mobile client

If those are all thin layers over the same application core, you have optionality without paying the full cost upfront.

What “composable” should mean in practice

When developers say “composable,” they often mean one of two things.

The first is infrastructure composability:

• swap the database
• change the ORM
• replace the payment provider
• move search to a different backend

The second is product composability:

• redesign the UI
• add a different frontend later
• expose an API
• support a second interface without rewriting the app

Both are valid goals.

But neither one requires you to split into “frontend” and “backend” as separate systems from the beginning.

What you actually need is a stable application core and clean seams around it.

The better default: a modular monolith

For most business apps, the right default is not a fat client and not a microservice fleet.

It is a modular monolith.

One deployable app. Clean internal modules. Clear boundaries. Thin adapters.

That means the system is structured around things like:

• domain and application logic
• ports or interfaces for things that vary
• concrete adapters for the web, database, payments, jobs, and so on

Not around a premature split into two independently deployed apps.

A simple shape looks like this:

/domain
  listing.ts
  billing.ts
  permissions.ts

/application
  createListing.ts
  approveListing.ts
  chargePlan.ts

/ports
  ListingRepo.ts
  BillingGateway.ts
  SearchIndex.ts

/adapters
  /db
    ListingRepoPostgres.ts
  /web-html
    listingsPage.ts
  /web-api
    listingsApi.ts
  /jobs
    reindexListings.ts

The important part is not the folder names. The important part is the direction of dependency.

The application core should not care whether the request came from an HTML page, an API route, or a worker.

A concrete example

Imagine you are building a listings product.

You have:

• a public listings page
• an internal admin view
• a flow for creating a listing
• billing rules that determine whether a user can post more listings
• search filters and moderation states

A lot of teams would jump straight to:

• React frontend
• JSON API backend
• maybe separate admin frontend too

But if you are a small team, that usually creates more problems than it solves.

A cleaner shape is this:

• CreateListing application service
• ListingRepo interface
• BillingAccess policy/service
• HtmlListingsController
• maybe later ApiListingsController

Then the flows look like this:

HtmlListingsController -> CreateListing -> ListingRepo -> DB
ApiListingsController  -> CreateListing -> ListingRepo -> DB
AdminJob/Worker        -> CreateListing -> ListingRepo -> DB

All three use the same business capability.

That is real composability.

You can redesign the UI later. You can add an API later. You can migrate route by route. You can even remove the HTML controller for one area if a richer frontend becomes worth it.

The core stays intact.

No, modules inside one app should not talk over HTTP

This is where many people get lost.

If you have these parts inside the same application:

• HTML controller
• API controller
• application service
• repository

then they usually should not communicate via HTTP.

They should call each other directly in-process.

Like this:

HtmlController -> AppService -> Repo -> DB

not like this:

HtmlController -(HTTP)-> AppService -(HTTP)-> Repo

HTTP is for process boundaries.

Inside one app, use direct calls.

This seems obvious once stated plainly, but a lot of teams blur the line between a conceptual boundary and a network boundary.

That confusion creates fake microservices inside one product.

The result is predictable:

• more latency
• more failure modes
• more serialization and contract maintenance
• harder debugging
• weaker transactions
• slower shipping

You bought distributed systems problems without earning the benefits.

When should a module stay in-process?

Most core business modules should stay in the modulith longer than people think.

Keep a module in-process when most of these are true:

• it participates in the same user request or transaction
• it shares the core data model deeply
• it does not need independent scaling
• it is owned by the same team
• there is no real second consumer yet
• a network hop would mostly add friction

This usually applies to things like:

• users
• permissions
• billing logic
• listings or content entities
• moderation
• account state
• admin workflows

These are not great early service boundaries. They are usually core modules of the same application.

What is a good candidate for extraction?

Separate services make more sense when something is operationally distinct.

That usually means it is:

• async
• bursty
• resource-heavy
• failure-prone
• dependent on third-party systems
• running on a different cadence from the main user-facing app

Examples:

• search indexing
• media or PDF processing
• webhook consumers
• crawler/scraper pipelines
• AI enrichment jobs
• analytics ingestion
• async notifications

These are much better candidates for workers or separate services.

The pattern here is simple:

If a module mostly answers what the business does, keep it in the modulith by default.

If it mostly answers how the system processes heavy or operationally distinct work, it is a better extraction candidate.

You can still replace the frontend later

This is the point people are usually worried about.

They want to avoid getting trapped in one presentation layer.

Fair concern. But the solution is not to split everything on day one.

The solution is to keep the presentation layer thin.

If your server-rendered HTML controller is only an adapter that calls application services, you can later:

• replace those routes with an API-driven frontend
• run old HTML and new UI side by side during migration
• keep some parts server-rendered and make only a complex area more interactive

That is often the best real-world setup.

For example:

• marketing pages: server-rendered
• account and settings: server-rendered
• complex dashboard or editor: richer client-side frontend

Not every page needs the same architecture.

That is another reason to resist defaulting to an all-client app too early.

Why teams over-split

Teams usually do not split early because they are stupid. They split early because the story sounds reasonable.

“We want flexibility.”

“We might need mobile later.”

“We do not want a monolith.”

“We want the frontend to be replaceable.”

All of that sounds smart. The problem is that these are often hypothetical benefits traded for immediate, certain costs.

Those costs are real:

• duplicated validation and types
• more auth and session complexity
• more code to coordinate
• slower local development
• harder end-to-end reasoning
• more release friction
• more bugs at boundaries

You should not pay those costs based on imagined future consumers.

Build the second consumer when it becomes real.

Until then, keep the architecture honest.

A good migration path

The right progression for most products looks like this:

1. Start with a modular monolith

One app. Clear boundaries. Server-first by default. Thin controllers.

2. Add API adapters where there is a real need

Maybe a richer frontend is justified for one area. Fine. Add the API adapter there.

3. Extract operational subsystems first

Workers, indexing, AI jobs, media processing, webhook handling.

4. Extract business-domain services only when real pressure proves it

That pressure might be:

• independent ownership
• separate scaling needs
• narrow stable contracts
• truly different deployment cadence

Until then, keep the domain close together.

The rule I would use

If you are unsure, default to this:

Keep business logic and core workflows in one modular, server-first app. Extract only the parts that are operationally distinct, async, or heavy.

That rule will save most small teams from a lot of self-inflicted architecture pain.

Closing thought

A composable architecture is not one where everything talks over HTTP.

It is one where the core of the app remains stable while the surfaces and infrastructure around it can change.

That means:

• clean code boundaries
• thin adapters
• server-first by default
• minimal client-side complexity unless it clearly pays for itself
• service boundaries introduced for real reasons, not architectural fashion

That is the boring answer.

It is also the one that usually works.

First published July 10, 2025. Updated December 2025 with the full story and current status of Print2Social.

Over the last year I have been building Print2Social, a tool designed to automate social media content for print on demand (POD) and indie e commerce store owners.

The original goal was simple:

• connect your Printful account and your social profiles
• auto generate product content
• keep your feeds active without burning your time

I wanted to help shop owners like myself spend less time on content creation and more time building the business, with the hope that automated posts on Instagram, Facebook, TikTok and later Pinterest would grow our brands and bring real traffic to our stores.

After months of real world testing, a small public launch, and a few more experiments, here is what I learned and where Print2Social stands today.

The reality: social automation brings views, not store traffic

In the first version of Print2Social I connected several of my own stores to Facebook, Instagram and TikTok and let it auto post hundreds of pieces of content.

The tool did what it promised. It created:

• lifestyle images and product highlights for feeds
• short form product clips for TikTok
• regular posts that kept every account “active”

Some TikTok videos reached more than 700 views in the early tests. Later, as I expanded to four stores, one typical 7 day window looked like this across their TikTok accounts:

• roughly 18 000 video views in total
• more than 120 profile visits
• a handful of likes
• 9 new followers

On Meta the picture was even clearer. Across four Facebook Pages and four Instagram accounts, a typical week with more than 100 automated posts produced:

• reach in the low double digits on Facebook
• under one thousand people reached on Instagram
• 0 new followers
• 0 new contacts or messages

Pinterest was the most honest of all. For a while one account showed 26 impressions in a month. The others stayed at zero.

The conclusion is simple:

Social automation can keep your feeds busy, but it does not magically create distribution, followers or sales.

Social media platforms are designed to keep users inside the app. They reward content that drives watch time, replies, saves and shares. Static product content from tiny accounts rarely does that, whether it is posted manually or by a bot.

Even if you gain some views, very few people will click out to your website, and even fewer will buy.

For indie store owners, automated posting alone does not drive targeted, purchase ready traffic.

The first reaction: maybe the posts just need to be shoppable

When I wrote the first version of this article in July 2025, my thinking went like this:

• If people do not like to leave the app, bring the shop to them.
• Meta Shops, TikTok Shop and Pinterest Shopping are built for in app purchases.
• Instead of sending people to external product pages, turn every post into a shoppable surface.

The plan at the time was to pivot Print2Social from “auto posting” to a shoppable social commerce tool.

On paper that meant:

• syncing product catalogs from Shopify, WooCommerce, Printful, Printify
• auto generating media with correct product tags
• publishing to Meta Shops, TikTok Shop and Pinterest Shopping
• so that a customer could buy without ever leaving the app

This direction still makes sense in theory. It is a real problem for many brands.

In practice I did not fully execute that pivot.

Before committing to a big new roadmap, I decided to run one more experiment.

The 14 day experiment: mini launch and more data

I set up a very simple two week test for Print2Social.

On the product side:

• keep four POD stores posting to Facebook, Instagram, TikTok and Pinterest using Print2Social
• only fix critical bugs, no new features, no fancy templates

On the marketing side:

• put a banner for Print2Social on my main site, PrintOnDemandBusiness.com
• send a short email to my list
• cross post about the tool on my social channels
• list it on Product Hunt and resubmit to BetaList

Then I stepped back and looked at the numbers from Google Analytics, Stripe and the social platforms.

What happened on the site and in Stripe

Over the 14 day window and surrounding weeks:

• Google Analytics showed only a few dozen unique visitors to Print2Social
• there was no noticeable spike around the launch date
• sources were a mix of direct, Google, a couple of referrals and a bit from my own sites

Stripe told a similar story:

• monthly recurring revenue hovered around a single digit euro amount
• net volume was low double digits
• the only paying users were a couple of early adopters from before this experiment
• no new customers appeared from the launch channels

As a standalone SaaS, Print2Social did not find traction.

What happened on the stores

On the social side I have already shared the high level numbers.

The short version is:

• hundreds of automated posts per week
• a steady trickle of low intent TikTok views
• almost no new followers or meaningful engagement
• no visible lift in store traffic or sales that I could attribute to the tool

At that point I had enough information to make a decision.

Print2Social today: a useful internal tool, not a product

Print2Social does what it was designed to do.

• It connects to Printful and my social accounts.
• It turns products into posts.
• It saves me time and removes boring manual work.

For that reason I am not shutting it down.

Instead I am changing how I think about it.

• Print2Social now lives on as an internal utility for my own POD test stores.
• I am not actively developing new features for it.
• I am not marketing it, pitching it, or trying to grow it as a SaaS.
• If someone finds it and really wants access, I can still let them in, but it is no longer a focus.

My POD stores themselves are treated as testbeds only. At some point in the future I will likely consolidate everything to a simple Etsy presence or redirect the domains to PrintOnDemandBusiness.com.

The experiment did its job. It answered the question.

What I would tell other founders

I am not writing this to say “never build social tools” or “never start a consumer brand”. Those things can work under the right conditions.

This is what I would highlight after going through this:

1. Do not mistake posts for distribution

It is easy to think that the problem is speed.

“If I could post more often, the algorithm would eventually notice me.”

What I saw in practice is closer to the opposite:

• more product posts from tiny accounts mostly produced more quiet
• even thousands of current TikTok views did not turn into traffic

If the base content format does not give the platform a reason to push you, automating that format just makes you invisible slightly faster.

2. Automation is best used on top of working levers

Print2Social optimised something that was never the main bottleneck.

Saving time is real value, but it is not the same as creating demand.

In hindsight, the more interesting automation problems sit closer to revenue:

• helping people who already have traffic earn more per visitor
• helping people who already close deals close them faster

The next time I build automation for others, I want it to sit under levers that are already proven, not under hope.

3. Demand should be visible before you invest heavily

Print2Social started as an internal tool for my own annoyance.

That part was fine. It is still useful for me.

Where I overreached was treating that initial usefulness as proof that there was a commercial product here.

Before turning future tools into products I want to see:

• clear search demand
• or buyers already paying for a worse alternative
• or a channel where similar products clearly get signups and usage

Internal annoyances are a great source of ideas. They are not enough on their own.

4. Run finite experiments and believe the results

The hardest part is not starting experiments. It is stopping them.

My 14 day launch window for Print2Social was intentionally small. It let me test a few channels, watch the numbers and then make a call.

When the data came back weak, the right move was not “one more feature” or “one more campaign”. It was to accept that the idea, in this form, does not have the pull I hoped for.

That is not a dramatic failure. It is just a closed loop.

Closing

I went into Print2Social hoping that social automation would be an engine for store traffic. What I actually built is a solid little tool that takes boring work off my plate but does not change the fundamentals of distribution.

That is still a win for me personally, and it might become a useful component inside something bigger one day.

For now, the lesson is simple.

Build tools that save you time. Just do not confuse “I can post more” with “more people will care”.

And when the data says a project belongs in the internal toolbox, let it live there and move your focus to where demand is already knocking.

We are living through a shift as significant as the Industrial Revolution. Automation, AI and platforms are steadily reducing the need for human labor in almost every sector. Factories, logistics, customer support, copywriting, even coding itself can now be done by machines.

If machines do more and more of the work, a critical question appears for anyone who wants to stay relevant and prosperous:

How can you own a piece of tomorrow's value creation, even if you have limited capital today?

Most advice still focuses on labor: get a better job, learn a new skill, hustle harder. But as value creation shifts away from human labor toward ownership of productive assets (digital, data or distribution), it becomes more important to position yourself as an owner, not only as a worker.

This article lays out five practical, low capital entry points that help you own assets which matter in a high automation future. You do not need a big team or investors. You need a clear niche, a bit of patience and the mindset of an owner.

1. Build a High Trust Micro Directory

Why it matters

Owning structured and trusted data is a form of digital land ownership. In almost every niche, discovery and curation are still unsolved problems. If you control a useful directory for tools, suppliers, consultants or products, you become a gatekeeper and a distribution hub.

You are not just listing links. You are deciding what gets visibility and how people discover options. That is real power.

How to start

• Pick a niche that is fragmented or confusing. Examples: AI tools for lawyers, eco friendly packaging suppliers, telehealth platforms, local renewable installers.

• Use open data, scraping or simple manual research to seed the directory.

• Enrich each listing with extra metadata. For example: who it is for, typical price range, strengths and weaknesses, main use cases.

• Add simple filters, tags and search. Focus on clarity and trust, not fancy design.

How it makes money

• Sponsored placements and featured listings.

• Paid “highlight” spots for new or premium entries.

• Affiliate links to tools and platforms.

• Access to the raw dataset as a paid download or API.

Cost

Time plus basic hosting. Think in the range of 10 to 20 euros per month. The main investment is your attention and judgment.

2. Run a Niche Newsletter With a Companion Database

Why it matters

Email lists are one of the most defensible digital assets. A high quality newsletter gives you both attention and distribution. It is a direct line to people who already trust you.

If you pair the newsletter with a public or semi public database, you end up owning both:

• The narrative about what matters in the niche.

• The structured knowledge base people rely on.

How to start

• Find a niche where people feel overwhelmed by information. For example: “Which AI tools actually save time for solo founders” or “What really works in print on demand right now”.

• Curate and interpret news, tool launches and real world experiments. Use AI to draft summaries, but always add your own judgment.

• Publish consistently. Weekly or biweekly is enough if the signal is high.

• Build a simple companion database in Notion or on your site that collects the most important links, tools and resources from the newsletter.

How it makes money

• Sponsorships and promoted sections in the newsletter.

• Paid access to the full database or extra filters.

• Community memberships or mastermind groups that sit on top of the newsletter.

Cost

Most email tools are free or cheap for small lists. The main cost is your time and your willingness to be the filter for others.

3. Extract And Sell Unique Datasets

Why it matters

In an AI driven economy, clean and structured data is often more valuable than code. Businesses, consultants and model builders all need high quality datasets for training, analysis and outreach.

If you can turn messy public data into a structured dataset that others can use, you own an asset that can be sold again and again.

How to start

• Pick a space where information is public but not organized. Examples: Shopify apps, Etsy shops in a niche, local specialists, conference speakers, podcast guests, SaaS tools for a specific industry.

• Scrape or collect the raw data from websites, directories and public sources.

• Clean the data and normalize fields like names, URLs, categories, location and pricing.

• Enrich the dataset with extra fields using AI or manual research. For example: tags, estimated revenue tier, tech stack, target segment.

How it makes money

• One off CSV sales on your own site or marketplaces.

• Annual or quarterly update subscriptions.

• Licensing deals with agencies or startups.

• Bundling the data into a micro SaaS or report.

Cost

Mainly your time and some basic scraping infrastructure. You do not need heavy servers. Start small and test demand before scaling.

4. Turn a Workflow Into a Micro API Or Tiny Tool

Why it matters

There are endless small workflows people repeat every day. Renaming files, generating product descriptions, adding UTM parameters, resizing images, cleaning audio, checking URLs.

If you can capture one of these workflows and automate it behind a simple interface, you can charge for access instead of selling your time.

How to start

• Watch what you or your peers do over and over inside a browser or editor.

• Ask: “Can this be turned into a single button or API call?”

• Build a tiny web app, browser extension or API that does exactly that one thing.

• Add clear documentation and a simple pricing model, even if it is just pay what you want or a few euros per month.

How it makes money

• Subscription fees for unlimited use.

• Pay per use credits via an API.

• White label deals with agencies who want to offer the feature under their own brand.

Cost

Your development time plus very basic hosting. Many of these tools can run on extremely cheap infrastructure because they only do one thing.

5. Own The Prompt And Output Layer For A GPT Vertical

Why it matters

As large language models become a commodity, the value does not sit in the raw model alone. It sits in the workflow that turns a vague request into a reliable result.

If you define the best practice prompts and output templates for a specific vertical, you become the default interface between people and AI in that area.

How to start

• Pick a high value workflow where people already try to use AI, but often get poor results. For example: legal letters, onboarding email sequences, product requirement documents, podcast show notes, outreach emails.

• Experiment heavily. Find prompt structures and checklists that consistently give good results.

• Turn these into reusable templates and step by step flows.

• Package the result as prompt libraries, downloadable guides, a small web app or a paid Notion system.

How it makes money

• Selling prompt packs or template bundles.

• Charging for access to a hosted version that hides the prompts behind a form.

• Adding consulting or done for you services on top for higher paying clients.

Cost

Very low. You mainly invest time and some API credits to test prompts.

Summary: Start Owning Small, Compounding Assets

All of these entry points share the same pattern.

You are moving from:

• Selling time and isolated deliverables.

To:

• Building assets that can be used and paid for repeatedly.

You do not need a big budget to begin. You can start with:

• A micro directory in a niche you understand.

• A newsletter that curates and explains a noisy space.

• A single dataset that solves a real research problem.

• One tiny tool that removes a daily annoyance.

• A set of prompts and templates that change how a niche uses AI.

Over time these assets can compound. They can feed each other. A directory can power a dataset sale. A newsletter can grow the user base of a tiny tool. A prompt library can evolve into a full vertical SaaS.

The common thread is simple.

In a world where machines create more and more of the output, you want to own at least a small part of the systems, data and channels that direct that output.

You do not control the entire future economy. But you can control a useful corner of it.

Start small. Start now. And build things that keep working even when you are not.

“Follow these 7 steps.”
“Use this funnel.”
“Copy this cold email script.”

The implication is always the same: if you do what successful founders did, you’ll get what they got. Same inputs, same outputs.

That’s a deterministic view of entrepreneurship.

In reality, startups don’t behave like chemistry experiments. You can do almost everything "right" and still fail. You can also do a lot of things "wrong" and still stumble into something that works.

This doesn’t mean everything is random. It means success is not guaranteed, only more or less likely. The rational founder doesn’t look for certainty. They manage probabilities.

Determinism vs. Reality

In a deterministic system, the rules are simple:

Same starting conditions → same result, every time.

Physics experiments. Math equations. Compilers.

If entrepreneurship worked this way, you could plug in:

• X hours of hard work

• Y amount of funding

• Z-size market

…and reliably output a profitable company.

But we know it doesn’t work like that. Two founders can:

• build similar products,

• in similar markets,

• with similar effort…

…and get wildly different outcomes.

So instead of asking, “What guarantees success?” a better question is:

“What increases or decreases the odds?”

The rest of this article is about separating what you can strongly influence from what you can only partially or not at all control – and how to operate rationally inside that uncertainty.

1. What You Can Actually Influence

You don’t control outcomes, but you do control your inputs and behavior. Some levers matter much more than others.

a) Value Proposition & Product–Market Fit

You can’t force a market to want your product. But you can decide whether you:

• talk to customers or just build in isolation,

• ship small and iterate or disappear for 12 months,

• listen to painful feedback or defend your original idea.

Concrete behaviors that improve the odds:

• Run structured customer interviews instead of guessing needs.

• Test positioning and messaging before writing a single line of code.

• Ship a minimum viable version and watch what people do, not just what they say.

You still don’t get a guarantee. You just get much better signal much earlier.

b) Business Model & Strategy

A surprising number of startups fail not because the product is terrible, but because the business model is.

You do control:

• how you charge (subscription, usage-based, one-off, hybrid),

• who you charge (SMB vs enterprise, prosumers vs hobbyists),

• how you reach them (SEO, outbound, paid, partnerships, marketplaces).

Treat these as variables, not destiny. Small changes here can radically change unit economics and survival chances.

c) Team & Culture

You don’t get to choose macroeconomic conditions. You do choose:

• whether you hire slowly or impulsively,

• whether you tolerate low standards,

• whether you reward learning or blame.

Teams with a culture of ownership and honesty can course-correct faster. Teams built on ego and politics usually don’t.

d) Execution & Adaptability

You don’t control competitor moves. You do control how fast you respond.

Questions that matter:

• Do you ship weekly or yearly?

• Do you review metrics and feedback regularly or fly blind?

• Do you pivot when evidence is clear, or cling to sunk costs?

Good execution doesn’t guarantee success. But weak execution almost guarantees you won’t even find out whether the idea could have worked.

2. What You Don’t Control (But Must Respect)

This is the part most playbooks gloss over.

a) Macroeconomic Conditions

• Interest rates change.

• Funding markets freeze.

• Consumer spending shifts.

You can’t vote these away.

You can, however:

• keep fixed costs low,

• maintain some runway buffer,

• avoid business models that only work in perfect conditions.

b) Industry and Technology Shifts

Regulation, new platforms, and new technologies can:

• suddenly open huge opportunities, or

• instantly kill your main advantage.

Again: not controllable. The rational move isn’t denial, it’s awareness:

• follow what’s happening in your space,

• understand where the power is moving,

• be willing to adapt your plans when the terrain changes.

c) Luck & Timing

No one likes to admit how much sheer luck is involved:

• meeting exactly the right person at the right time,

• one blog post or tweet going viral,

• a platform feature you rely on not getting killed.

You can’t manufacture luck on demand.

But you can increase your “luck surface area”:

• share what you’re building,

• talk to more customers,

• participate in relevant communities,

• show your work in public.

Each of these is a small lottery ticket. Most do nothing. A few matter a lot.

3. Timing as a Force Multiplier

A painful truth: the same idea can be a disaster in 2010 and a rocket ship in 2025.

• Infrastructure might be missing.

• Habits might not be formed yet.

• The tools you depend on may not exist.

Or the opposite: you might be too late.

You can’t perfectly time markets. Nobody can. What you can do is:

• pay attention to how fast your space is moving,

• pick problems where adoption is clearly trending up, not down,

• avoid betting everything on a shrinking or stagnant behavior.

Timing isn’t something you “solve”. It’s a background multiplier on everything else you do.

4. How Rational Founders Operate in an Uncertain World

If success isn’t deterministic, what do you do with that?

You stop looking for guarantees and start thinking like this:

“Given that outcomes are uncertain, what strategy gives me the best odds and the cheapest information?”

Here are practical tools for that.

a) Lean Loops Instead of Grand Plans

The classic loop:

1. Build: the smallest version that can test a real behavior.

2. Measure: what people actually do, not what you hoped they’d do.

3. Learn: keep what works, discard what doesn’t.

The point isn’t “move fast and break things.” The point is:

• move small,

• learn fast,

• and avoid big, blind bets.

b) Scenario Planning

Instead of one story about the future, sketch three:

• Best case: what if everything goes unusually well?

• Base case: what is realistically likely with current assumptions?

• Worst case: what if key risks materialize?

Then decide ahead of time:

• what you’ll do if you hit the best case (double down?),

• how you’ll react in the base case (optimize, refine),

• when you’ll stop or pivot in the worst case (clear kill criteria).

This doesn’t control the future. It prevents panic and denial when reality shows up.

c) Financial Flexibility

Runway doesn’t guarantee success, but lack of runway guarantees you don’t get more experiments.

Principles that help:

• keep fixed costs lower than your ego wants,

• don’t hire ahead of proven demand,

• assume revenue will be lumpier and slower than your optimistic spreadsheet.

Cash buys you time to learn.

d) Networks & Mentors

A single warm intro, a piece of hard-won advice, or a reality check can save months of spinning your wheels.

Rational founders:

• deliberately seek out people who have done similar things,

• ask specific, grounded questions,

• trade ego (“I know what I’m doing”) for information (“What am I missing?”).

You still own the decisions. But your decisions are now made on better data.

5. The Mindset Shift: From Guarantees to Probabilities

If you internalize that success isn’t deterministic, a few things change.

a) Failure Becomes Data, Not Verdict

When success is seen as a guaranteed result of “doing it right”, failure feels like a personal verdict: you are the flaw.

When you see it as probabilistic, each attempt is more like:

• a noisy experiment under uncertain conditions,

• with imperfect information,

• and a mix of controllable and uncontrollable factors.

You still take responsibility for mistakes. But you don’t pretend you could have removed all randomness from the system.

b) Multiple At-Bats Matter More Than One Perfect Swing

If outcomes are probabilistic, then:

• one attempt is rarely enough data,

• optimizing for “never fail” is irrational,

• designing your life so you can survive several tries makes more sense than aiming for the miracle.

You want:

• low downside per attempt,

• meaningful upside if it works,

• and the ability to try again.

c) Humility + Agency

The weird, but healthy mix is:

• Humility: you accept you can’t fully control timing, luck, or macro.

• Agency: you aggressively control what you can: skills, effort, process, focus.

Neither “I control everything” nor “everything is luck” is true. The truth is in the middle, and it’s less emotionally satisfying but more useful.

So… Is Startup Success Deterministic?

No.

You can’t plug in effort, funding, and strategy and reliably get a unicorn out the other end.

What you can do is:

• dramatically improve the odds with good research, execution, and iteration,

• avoid obvious failure modes (no customers, no runway, no feedback, no adaptability),

• structure your life and business so you can survive multiple attempts.

Think of entrepreneurship less as solving a fixed equation and more as:

a repeated game of stacking small edges in an uncertain environment.

You don’t get certainty.

You get choices, experiments, and probabilities.

And over enough time, for founders who keep showing up and keep learning, those probabilities start to compound.

If you’re a developer or founder, you don’t need to reinvent the math of deep learning. But you do need a solid mental model of:

• what modern LLMs really are,

• why they’re trained on GPUs/TPUs,

• how context windows, tokenization, and KV cache shape what’s possible,

• what “SFT”, “RLHF”, and “agents” actually mean in practice.

With that, you can:

• choose the right models and infrastructure,

• design prompts and tools that cooperate with the model instead of fighting it,

• avoid the common traps that waste tokens, time, and effort.

This post is that kind of primer: opinionated, practical, and aimed at people who want to build.

2. What a modern LLM really is

At its core, a large language model is:

A giant function that takes a sequence of tokens and predicts the probability distribution of the next token.

Three key pieces:

1. Tokenization

   • Text is split into tokens (subwords, word pieces, sometimes whole words or symbols).

   • Each token is mapped to an integer ID.

   • Different tokenizers → different token counts → different cost and context usage.

2. Embeddings and Transformer blocks

   • Each token ID → high-dimensional vector (embedding).

   • These vectors pass through a stack of Transformer blocks.

   • Each block has:

     • Self-attention: each token looks at other tokens and decides who matters.

     • Feed-forward network: a small neural net applied to each token’s representation.

     • Residual connections + normalization: keep things stable and trainable.

3. Output layer

   • Final hidden state at each position → logits over the vocabulary.

   • After softmax, you get a probability distribution over the next token.

   • During generation, you sample repeatedly from that distribution.

The model doesn’t “think in words”. It operates entirely on vectors, but is trained in such a way that those vectors encode useful structure about language, code, and the world.

3. How LLMs are trained (end to end)

Training has three main phases: pretraining, post-training, and inference-time steering.

3.1 Pretraining: turning text into a base model

Pretraining is where the model learns most of its knowledge and raw capabilities.

Step 1: Data

• Collect large corpora: web pages, books, documentation, code repositories, etc.

• Clean and filter:

  • remove obvious junk and duplicates,

  • filter by language,

  • control for some types of toxic content.

• Tokenize into integer sequences.

Step 2: Objective

The core pretraining task is next-token prediction:

• Given: a sequence of tokens [x1, x2, ..., xT].

• Task: predict token x2 from [x1], x3 from [x1, x2], and so on.

• The loss function (cross-entropy) punishes the model when it assigns low probability to the actual next token.

Intuitively:

The model gets better by being less surprised by real text.

Over trillions of tokens, the easiest way to reduce surprise is to internalize grammar, common patterns, factual structure, and even rough reasoning shortcuts.

Step 3: Optimization

• Run forward pass → compute predictions and loss.

• Use backpropagation to compute gradients.

• Use an optimizer (e.g. AdamW) to tweak weights slightly.

• Repeat this at insane scale across GPU/TPU clusters.

At the end, you have a base model: great at modeling text, but not yet a polite assistant.

3.2 Why GPUs/TPUs instead of CPUs

Training is dominated by a small set of operations:

• large matrix multiplications (matmul) for almost every layer,

• simple elementwise operations (nonlinearities, normalization),

• repeated over and over on huge tensors.

CPUs are designed for:

• a small number of powerful, flexible cores,

• low-latency, branching-heavy workloads (OS, databases, web servers).

GPUs/TPUs are designed for:

• thousands of smaller, simpler cores,

• massive parallelism,

• very high memory bandwidth,

• specialized matrix-multiply units (tensor cores).

If your job is essentially “multiply big matrices and do the same arithmetic on millions of numbers”, GPUs/TPUs will outperform CPUs by orders of magnitude in speed and energy efficiency.

Short version:

Pretraining LLMs is a giant dense linear algebra problem. GPUs/TPUs are built for that; CPUs are not.

3.3 Post-training: from raw model to assistant

Pretraining gives you a model that behaves like smart autocomplete. To turn it into a useful assistant, there are two major post-training steps.

Supervised fine-tuning (SFT)

• Collect (instruction → good response) pairs.

• Train the model again on this dataset.

• Same next-token loss, but now:

  • inputs look like user prompts/questions,

  • outputs are curated, high-quality answers.

This teaches the model to:

• treat the latest user message as a task to respond to,

• answer clearly instead of just “continuing the text”,

• follow patterns like “answer step-by-step” or “output valid JSON”.

This produces the familiar instruct/chat variants.

Preference optimization (RLHF, DPO, etc.)

Now you optimize for style and safety.

• Collect data where humans compare two model responses (A vs B) and pick the better one.

• Train a preference or reward model that predicts which response humans prefer.

• Adjust the base model to produce responses that score better under this preference model.

Effects:

• Reduces toxic and clearly harmful behavior.

• Encourages helpful, polite, cautious answers.

• Sometimes adds more hedging and verbosity than you personally might like.

3.4 Inference: how generation actually works

At inference time:

1. Prompt is tokenized.

2. Tokens are embedded and run through the Transformer stack.

3. The model outputs a probability distribution over next tokens.

4. A decoding strategy chooses the next token:

   • Greedy: always pick the most probable.

   • Top-k: sample from the k most likely.

   • Top-p (nucleus): sample from the smallest set whose total probability ≥ p.

   • Temperature: make the distribution sharper or flatter.

5. Append that token and repeat.

Two key knobs for you as a user:

• Sampling strategy → controls creativity vs determinism.

• Stopping criteria → when to end (max length, special tokens, etc.).

4. Context windows, tokenization, and KV cache

You never interact with “the model in the abstract”. You interact with a specific model that has:

• a tokenizer,

• a maximum context window, and

• performance tricks like KV cache.

All three matter a lot in practice.

4.1 Tokenization

Tokenization decides:

• how many tokens your text turns into,

• which sequences are “cheap” or “expensive”,

• how efficiently code, emojis, non-English languages, etc. are represented.

Why you should care:

• Token count drives latency and cost (on cloud APIs).

• Different models can be dramatically more efficient for certain kinds of text (e.g. code-oriented tokenizers make code cheaper to process).

4.2 Context window

The context window is the maximum number of tokens the model can see in one go. It has to fit:

• system prompt,

• user messages,

• chat history,

• tools’ schemas and logs (if any),

• your actual task content (code, docs, etc.),

• and sometimes the output itself.

Implications:

• Long conversations and large docs don’t fit in raw form.

• You need strategies: summarization, retrieval, trimming.

• For RAG, you’re always balancing “instructions + query + retrieved chunks” against a hard limit.

4.3 KV cache: making long generations feasible

Attention is quadratic in sequence length if you recompute it from scratch each time. KV cache is the standard trick to avoid that.

During generation:

• For each token and each layer, the model computes keys (K) and values (V).

• These are stored in a KV cache.

• For each new token, the model:

  • reuses Ks and Vs for all previous tokens from the cache,

  • computes new Q/K/V for the current token.

This keeps the cost per new token reasonable and enables efficient streaming.

4.4 Long context is not perfect memory

Even with huge context windows (e.g. 128k tokens):

• Attention is soft: tokens distribute their focus over many others.

• Models tend to focus more on recent or salient tokens.

• Training may be optimized more for shorter ranges.

Practical strategies:

• Don’t just paste entire books or giant logs.

• Summarize the core: goals, key facts, definitions.

• Repeat crucial early information near where it’s actually needed.

• For retrieval-based systems, feed the model small, relevant chunks instead of huge blobs.

5. How alignment and prompts interact

You can think of a modern assistant model as the sum of four layers:

1. Pretraining → knowledge and general patterns.

2. SFT → instruction-following behavior.

3. Preference optimization → style and safety.

4. System prompt → per-session steering.

When the model’s behavior feels wrong:

• If it doesn’t understand the task at all → capability issue (model too small or wrong domain).

• If it understands but ignores structure (e.g. you asked for JSON, it gives prose) → prompt design or SFT limitations.

• If it refuses too much or over-hedges → RLHF/alignment layer.

• If it usually behaves but slips on details → fix with better system prompts, clearer instructions, or examples.

System prompts are powerful but bounded:

• You can set role, style, formatting rules, tool policies.

• You can’t give it knowledge it doesn’t have.

• You can’t fully override strong safety constraints.

6. Agents: LLMs that can act in a loop

“Agentic AI” sounds mysterious, but in practice an agent is just:

A loop where the model can plan → act (use tools) → observe → update its plan, instead of answering once and stopping.

6.1 Basic agent loop

A minimal agent loop looks like:

1. Maintain a state:

   • user goal,

   • relevant context (files, docs, notes),

   • history of actions and observations.

2. Call the model with the current state.

3. The model returns either:

   • a tool call (e.g. read a file, run a command, fetch a URL), or

   • a final answer.

4. If it’s a tool call:

   • the environment runs the tool,

   • the result is appended to the state,

   • loop continues.

5. If it’s done or stuck:

   • the loop exits with a final answer or a failure report.

All popular “agent frameworks” are just structured versions of this idea.

6.2 Tools define what an agent can do

Examples of tools:

• Code agent:

  • read_file(path)

  • search_files(pattern)

  • apply_patch(path, diff)

  • run_tests()

• Research agent:

  • web_search(query)

  • load_pdf(path/url)

  • search_notes(query)

  • summarize_chunk(text)

• Ops agent:

  • run_cmd(command)

  • deploy_service(config)

  • etc.

More powerful tools → more capability ↔ more risk.

6.3 Guardrails for agents

Because agents can operate in loops and take actions, you need guardrails:

• max_steps per task (prevent infinite loops).

• Clear termination conditions.

• A way to give up gracefully:

  • “Here’s what I tried, what failed, and what’s left for a human.”

• Tool policies:

  • Prefer patches over full rewrites.

  • Don’t run destructive commands.

  • Don’t fake tool outputs.

Agent behavior benefits from a good system prompt:

• Tell it to check tool results before proceeding.

• Tell it to ask for confirmation before irreversible actions.

• Tell it how to report failures.

6.4 Coding agents vs research agents

Coding agent (e.g. in an IDE):

• Goal: operate over a repo to implement features, fix bugs, refactor.

• Typical loop:

  • inspect files → propose change → apply patch → run tests → inspect failures → iterate.

• Needs to be conservative:

  • limit scope,

  • avoid unwanted refactors,

  • keep changes reviewable.

Research/analysis agent (e.g. in a web UI):

• Goal: answer a complex question using multiple sources.

• Typical loop:

  • clarify question → plan steps → fetch sources → summarize chunks → build hierarchical notes → synthesize answer with citations.

• Works well with long context and many iterations, especially on local setups where you’re not billed per token.

7. How to get more out of LLMs in practice

With these concepts in mind, here are some practical principles.

7.1 Work with the model’s structure, not against it

• Be aware of the token budget.

• Put the most important requirements and constraints near the end of the prompt where they’re fresh.

• Use summaries to keep long-term goals and context alive.

• For large tasks, split into sub-tasks and use an agent-style loop instead of one giant prompt.

7.2 Use the right model for the job

• Bigger, more capable models for:

  • difficult reasoning,

  • complex refactors,

  • high-stakes answers.

• Smaller/local models for:

  • boilerplate code,

  • simple Q&A,

  • summarization,

  • experimentation where cost would otherwise explode.

7.3 When you move to agents, start conservative

• Start with tools that can’t destroy much:

  • read-only operations,

  • patch-based writes,

  • whitelisted commands.

• Add more powerful tools only when:

  • you have tests,

  • you trust the agent’s behavior,

  • and you understand the failure modes.

7.4 Iterate on system prompts

• Treat your system prompts as code:

  • version them,

  • refine over time,

  • test them with real tasks.

• Make them explicit about:

  • reasoning style,

  • output format,

  • safety constraints,

  • interaction with tools.

8. Closing thoughts

You don’t need to derive every formula behind Transformers to use LLMs effectively. But you do need a mental model like this:

• LLMs are next-token predictors trained with huge matrix multiplications on GPUs.

• Context windows, tokenization, and KV cache define the practical envelope of what you can do.

• Post-training (SFT + alignment) and system prompts decide how the model behaves for you.

• Agents are just loops around the model with tools, not magic.

Once you see things this way, you can make better decisions about:

• which models to use,

• how to structure your prompts and contexts,

• when to introduce agents and tools,

• and how to balance cloud vs local inference.

That’s where the real leverage is: understanding enough of the internals to design workflows that actually cooperate with the model and then letting the model do what it’s good at, while you focus on building things that matter.

“I spend way too much time picking models and modes instead of actually shipping code.”

You get:

• Multiple models (Composer, Claude, GPT-5, Grok, Qwen…)

• “Thinking” vs non-thinking variants

• Toggles like Max mode, cloud vs local, Ask vs Agent vs Plan

• And a UI that changes every few weeks

On paper this is “control”. In practice it’s cognitive overhead.

This post is a first-principles way to think about coding with AI so you can stop micro-optimizing knobs and get maximum quality per buck (and per minute).

1. Coding with AI is its own skill

It’s easy to think of AI as a smarter autocomplete. It isn’t. To use coding assistants effectively you need to learn a new skillset:

• Framing tasks so a model can actually solve them

• Choosing the right level of autonomy (advise vs edit vs refactor whole project)

• Knowing when to iterate and when to start over

• Optimizing for your time, not just tokens

What makes this hard is that most tools expose low-level levers (model, mode, “thinking”, Max, cloud) instead of giving you a simple “do-what-I-mean” abstraction.

So let’s build your own abstraction.

2. Forget the UI: there are only three real decisions

Ignore all the product marketing and menus for a second. Under the hood, almost everything reduces to three questions:

1. How big / smart a model do I want?
   (Small/cheap vs large/expensive; “thinking” vs “fast”.)

2. How much of my repo / context does it need to see?
   (Normal vs “Max mode” / huge context.)

3. How much autonomy do I give it?
   (Explain only? Edit a few files? Refactor the world? Run in the cloud without me watching?)

Everything else (Ask vs Agent vs Plan, local vs cloud, etc.) is just preconfigured answers to those three.

Once you internalize that, the UX stops feeling like chaos. You’re just tuning:

Model size × Context budget × Autonomy

3. The cost/quality tradeoff: stop fighting physics

A lot of people (maybe you) are doing this pattern:

1. Try with a cheaper / smaller model.

2. Get a mediocre answer.

3. Switch to a top model (Claude Sonnet, GPT-5, etc.).

4. Finally get something usable.

On paper this “saves money”. In reality, it often doesn’t.

Let’s reason it out.

• Let C_small be the cost of a small/mid model call.

• Let C_big be the cost of a top model call. (Say ~10× C_small for intuition.)

• Let p be the fraction of tasks where you end up using the big model anyway.

Two strategies:

• Strategy A – Always use big model
  Cost ≈ C_big

• Strategy B – Try small, escalate if needed
  Cost ≈ C_small + p * C_big

If C_small = 1 and C_big = 10:

• Always-big → cost = 10

• Try-small → cost = 1 + 10p

You only beat always-big if:

1 + 10p < 10 → p < 0.9

So if you escalate to a big model more than ~90% of the time, the “cheap first” step is pure overhead.

In practice:

• For hard, ambiguous tasks (understanding systems, ugly bugs, architecture), most people do escalate. So going straight to the best model is actually rational.

• For small, mechanical tasks, you rarely escalate, so a cheaper model really can save money.

The trick isn’t “optimize every call”. The trick is:

Know which tasks almost always need a top model, and stop pretending otherwise.

4. Classify tasks, not prompts

Instead of choosing a model for each prompt, classify the type of work first.

Bucket 1 – Hard / ambiguous / high-value work

Examples:

• Understanding an unfamiliar subsystem end-to-end

• Designing a new feature that cuts across backend, frontend, DB

• Debugging a weird bug that involves async jobs, queues, and timeouts

• Reasoning about tradeoffs (performance, correctness, architecture)

Characteristics:

• You’d personally need a while to think

• There isn’t a single obvious local fix

• You expect multiple iterations and back-and-forth

Use case: You want a smart junior/staff engineer thinking with you.

Strategy:
Go straight to your best model (Claude Sonnet, GPT-5, etc.), often with “thinking” / deeper reasoning turned on.

Don’t bother with cheaper models here. Your own time is more expensive than the token difference.

Bucket 2 – Local / routine / mechanical work

Examples:

• “Add tests for this function and adapt fixtures.”

• “Extract this bit of logic into a helper and update this file + its tests.”

• “Generate a typed API client from this OpenAPI schema.”

• “Add logging around this one endpoint.”

Characteristics:

• Scope is limited to 1–3 files

• Expected behavior is clear

• You can quickly tell if it’s wrong just by reading the diff

Use case: You want a smart autocomplete that can handle slightly non-trivial patterns.

Strategy:
Use a cheaper, mid-tier coding model (Composer, Qwen, Grok-code, etc.) as default.

• If it nails it on the first or second try → great, you saved money.

• If it struggles repeatedly for this exact type of task, upgrade that task type to Bucket 1 in your mental model and use a top model next time.

Bucket 3 – Bulk / repo-wide but well-specified work

Examples:

• Updating license headers everywhere

• Renaming a logging library and updating all call sites

• Performing a very specific, repetitive change across many files

Characteristics:

• High file count, but low conceptual complexity

• You can write a very explicit spec: exactly what changes, where

Here you have two good options:

1. Use AI once to generate a codemod, then run that codemod with normal tooling (no AI for the bulk).

2. Use a “Max mode” or background agent, but only when the spec is crystal clear and the change is mechanical.

Background/cloud agents are terrible at vague, creative tasks. They are good at “update this pattern everywhere exactly like this”.

5. Model size, “thinking” and Max mode in plain language

Now let’s map the knobs to this framework.

Model size

• Big / top models (Sonnet, GPT-5, etc.):
  Better reasoning, more robust across weird prompts, more expensive.

• Mid / small models (Composer-lite, Qwen, etc.):
  Fine for localized code, tests, boilerplate, cheaper.

Mapping:

• Bucket 1 → Always big

• Bucket 2 → Default to mid, escalate only if it clearly fails

• Bucket 3 → Depends on whether the transformation is semantic or mechanical:

  • Mechanical → mid/small or no AI at all

  • Semantic → big model once to define the pattern, then script/codemod

“Thinking” models

A “thinking” mode basically means:

• The model spends more internal compute to reason before answering

• It might run extra internal steps, plan, and then answer

• It tends to be slower and more expensive, but handles harder problems

Mapping:

• Bucket 1:

  • “Thinking” ON is usually worth it for tough bugs and design questions.

• Bucket 2:

  • “Thinking” often unnecessary – you want precision and speed.

• Bucket 3:

  • If change is mechanical, “thinking” is overkill. If change is subtle/semantic, have the big model reason once about the pattern, then let code/scripts do the bulk.

“Max mode” / huge context

“Max” is essentially:

• Give the model way more context (more of your repo + history)

• Allow many more tool calls / steps per “task”

• Accept higher cost and latency

This is not “make it smarter”; it’s “let it see and touch more at once.”

Mapping:

• Bucket 1:

  • Sometimes useful if understanding a huge codebase, but dangerous if you give it too much autonomy.

• Bucket 2:

  • Mostly unnecessary. Your scope is intentionally small.

• Bucket 3:

  • Useful if you’re doing massive transformations and want the AI to navigate many files, as long as the spec is strict.

As a default:

• Max OFF unless:

  • The task is explicitly repo-wide or doc-heavy, and

  • You already know what you want it to do.

6. Autonomy: Ask vs Agent vs Plan vs “do everything in the cloud”

The other dimension is: how much power do you give it?

Low autonomy – “Ask mode”

• The AI explains, reviews, suggests.

• You apply changes manually.

This is ideal for Bucket 1 (understanding, design, root-cause analysis). You want conversation, not automated edits.

Medium autonomy – “Agent mode on a leash”

• The AI can edit files, but you keep tasks small.

• You review every diff like a PR.

This fits Bucket 2: local changes where the impact is limited and obvious.

You can even tell an Agent: “Do not edit files yet, only propose a patch” – turning it into Ask mode with extra repo context.

High autonomy – “Cloud agent, big plan, lots of freedom”

• The AI runs in a separate environment, possibly with Max context.

• It can edit many files and run tools, often without interactive feedback.

This only belongs in Bucket 3 – mechanical repo-wide work with a tight spec.

Using high-autonomy modes for Bucket 1 or 2 (“figure out this fuzzy feature idea and implement it end-to-end”) is almost guaranteed to produce garbage. You’re skipping the human-in-the-loop phase where requirements actually get nailed down.

7. A practical playbook you can actually use

You don’t need to think from scratch every time. Here’s a simple policy you can adopt:

Step 1 – Classify the task

Before typing the prompt, ask:

“Is this hard/ambiguous, local/mechanical, or bulk/mechanical?”

Then:

• Hard / ambiguous → Bucket 1

• Local / mechanical → Bucket 2

• Bulk / mechanical → Bucket 3

Step 2 – Apply the corresponding defaults

Bucket 1

• Model: Best available (Sonnet/GPT-5)

• Thinking: ON

• Max: OFF by default, ON only when you really need repo-wide visibility to understand something

• Autonomy: Ask mode; Agent only for small, clearly scoped edits you’ve agreed on

Bucket 2

• Model: Mid-tier coding model (Composer/Qwen/etc.)

• Thinking: OFF (or minimal)

• Max: OFF

• Autonomy: Agent allowed, but limited to small scopes; you review diffs

If it fails more than once for this sort of task, reclassify this specific pattern as Bucket 1.

Bucket 3

• Model:

  • Use top model once to help you define a precise spec or codemod script

  • Use scripts/tools for the actual transformation

• Thinking: ON only during spec design, OFF for mechanical execution

• Max: ON only if you actually need massive context or multi-file reasoning

• Autonomy: Cloud/background agent only for strictly specified, mechanical jobs

8. Optimize for your time, not just token spend

The final mental shift is this:

• Tokens are cheap compared to your time and frustration.

• Chasing small token savings by trying multiple cheap models and then escalating often loses in the real world.

For interactive development:

• Use the best model for anything that feels like “real engineering” (understanding, design, complex bugs).

• Use cheaper models or no AI at all for tiny, obvious, mechanical things.

• Use AI + scripts for big mechanical tasks, not AI alone.

That’s how you actually get quality per buck – and, more importantly, quality per hour of your life.

On paper, it looks like we are only a few prompts away from “AI‑built businesses” that launch, grow, and print money while humans watch from the sidelines.

In reality, that’s not happening. Not because AI is weak, but because we are confusing building products with building businesses.

This article is an attempt to draw that line very clearly.

What AI is already good at

Let’s start from the uncomfortable truth:

For a lot of individual tasks, AI is already as good as or better than the average developer, marketer, or solo founder.

Today’s models can already:

• Generate working code for full‑stack apps, including APIs, auth, and CRUD.

• Fix bugs and refactor code bases.

• Write documentation, tests, and basic system design.

• Do market and competitor research from public data.

• Write landing pages, onboarding flows, pricing pages, and onboarding emails.

• Generate long‑form SEO articles, social media content, and ad copy.

• Draft outbound outreach emails, follow‑ups, and support replies.

If you give an AI system tool access (browser, APIs, Git, deployment, email), it can realistically:

• Pick a niche.

• Build and deploy an MVP.

• Fill it with content.

• Set up analytics.

• Start basic distribution.

So the reassuring line – “don’t worry, AI can’t do X” – is getting thinner every month. The point is not that humans are better at writing code or copy. Often, they aren’t.

But that’s not where the real bottleneck is.

What a business actually is

A lot of confusion comes from treating “I launched a thing” as equivalent to “I built a business.”

They are not the same.

A product is something you can build and ship.

A business is a system that:

• Solves a real problem for real people,

• Reaches those people repeatedly,

• Gets paid reliably,

• And does all of that profitably and sustainably over time.

That system includes:

• Customers and their trust.

• Distribution channels.

• Pricing and positioning.

• Support and operations.

• Brand and reputation.

• Feedback loops and iteration.

That is where things get slow and messy – and where AI runs into its real limits.

The latency wall: execution is fast, trust is slow

Even if an AI system can build and launch a product in a weekend, it does not magically skip the latency of external systems.

Some examples:

1. SEO takes time

You can generate and publish 100 high‑quality articles in a few days. That does not mean you will get traffic in a few days.

• Search engines need to discover, crawl, and index the site.

• The domain needs to build history and trust.

• Backlinks need to appear and be evaluated.

• User behavior signals have to accumulate.

That process plays out over weeks and months, not hours.

2. Social and word of mouth are slow by default

You can have AI generate perfect Reddit posts, tweets, LinkedIn threads, and community replies.

Most of them will still get ignored.

Attention is a crowded, noisy market. Without an existing audience, relationships, or reputation, your posts are just more noise. Occasionally something catches and spreads. Usually it does not.

3. Feedback loops cannot be rushed

You only learn if your product works when enough real users:

• Find it,

• Try it,

• Use it for long enough,

• And either stick around or churn.

That learning loop looks like:

Launch → tiny trickle of users → vague feedback → small changes → wait → observe behavior → repeat.

It is inherently slow in the beginning because you don’t have volume. You cannot A/B test your way to clarity with 23 visitors a day.

4. Trust compounds on a different timescale

People don’t trust a random new domain or anonymous brand instantly.

Trust builds from:

• Showing up consistently.

• Being around for a while.

• Fixing issues instead of disappearing.

• Answering emails.

• Word of mouth.

You can automate responses. You cannot automate “this thing has been here and reliable for a long time”. That’s just time.

Why AI can’t just “agent” its way out of this

Modern AI agents can:

• Run in loops,

• Break goals into tasks,

• Call tools and APIs,

• Read and write to external memory (via RAG or databases),

• Observe outputs and try something else.

On paper, that looks a lot like “agency.” In practice, several hard limits remain.

1. No real skin in the game

An AI system does not care if the business works.

It doesn’t feel the difference between:

• Zero revenue and growing revenue.

• Burning runway and being profitable.

• Keeping a promise to a customer and breaking it.

It can be programmed to optimize metrics, but it does not have anything at stake. There is no real fear, desire, or responsibility behind its decisions.

2. No real judgment under uncertainty

Business decisions are rarely clean optimization problems. You constantly deal with incomplete, conflicting, and noisy signals:

• Some users say they love the product, others churn silently.

• Traffic goes up but revenue doesn’t.

• A new feature might help or might just add complexity.

Humans develop intuition over time for which signals to trust, which to ignore, and when to make a call with limited data. AI can simulate confidence, but underneath, it is still just pattern matching.

3. No ownership of the long game

A real business requires:

• Signing contracts and handling liability.

• Dealing with regulation and taxes.

• Navigating platforms changing rules.

• Choosing when to pivot, when to hold, and when to quit.

All of that ultimately sits on a human or a legal entity that can be held accountable. AI can draft emails and strategies, but it doesn’t own the consequences.

The real bottleneck: resilience and compounding

If you strip away all the hype, the game looks like this:

• Building products is getting cheaper and faster.

• Distribution and trust still take time and consistency.

• Most people quit somewhere in that gap.

This is why so many “good ideas” and “nice products” never become real businesses. Not because they were impossible. Because the builders ran out of:

• Energy,

• Money,

• Patience,

• Or belief,

before the trust and audience had time to compound.

You could describe the situation like this:

You either need a resilient human, willing to grind through months of slow, ambiguous progress.

Or you need a machine with enough credits to run an endless loop of generations and iterations until the numbers finally move.

Right now, only humans actually care about the outcome. AI will keep generating as long as you pay the bill. It will not feel the frustration of a flat analytics graph.

Where AI actually changes the game

All of this does not mean “AI is overrated” or “nothing changes.” A lot changes.

AI dramatically reduces the cost of:

• Testing new ideas.

• Rebuilding or repositioning products.

• Producing content and educational material.

• Responding to user feedback.

• Running experiments in parallel.

In other words, it makes it much more survivable to stay in the game long enough for trust and distribution to catch up.

You still have to endure the grind. But your iterations can be faster, cheaper, and less painful.

Instead of spending three months building the wrong thing, realizing it, and starting over, you might spend a weekend. That does not remove the need for resilience, but it changes the economics of trial and error.

So what’s left for founders and developers?

If AI keeps getting better at execution, what is left for humans?

At least for now:

• Choosing the game – what problem to work on, in which market, with which constraints.

• Understanding people – not as personas in a slide deck, but as messy humans with fears, desires, and habits.

• Building trust – showing up, keeping promises, dealing fairly with customers and partners.

• Holding the line – staying in long enough for the compounding to work instead of hopping to the next shiny thing.

AI can be an amplifier for all of that. It can remove a lot of the busywork and technical friction. But it does not remove the need for someone to care, commit, and endure.

Closing thoughts

AI can already build products that look impressive. It can scaffold full apps, populate them with content, and even start basic marketing.

What it cannot do is skip the part where the world slowly decides whether any of this deserves attention, trust, and money.

That part still takes months or years. It still requires resilience. And it still separates people who ship one clever project from people who end up owning real businesses.

AI is not a replacement for that. It is leverage for the few who are willing to keep going while everyone else gives up.

Not because your tool isn’t valuable.

But because it doesn’t talk enough.

Modern search is still, in practice, a text-first system. If you don’t publish long, optimised articles that feed this system, you’re playing with a handicap.

This isn’t just annoying for founders. It’s a structural flaw in how we discover things online.

How SEO turned blogs into a toll booth

Ask almost any SEO how to get organic traffic for a SaaS, marketplace, directory, or e‑commerce brand and the advice is painfully consistent:

“You need a blog.”

The logic behind that advice is simple:

• Search engines crawl and index text.

• They need a lot of text to infer what your site is about, what queries it should rank for, and how authoritative it is.

• Product pages, dashboards, and tools are often light on copy and heavy on interactions, data, or UI.

So if your core value is:

• an uptime monitoring tool

• an SEO reporting dashboard

• a directory of niche suppliers

• a marketplace with smart matching

…you’re still told to create:

• “Top 10 tools for X in 2026” posts

• “How to do X” guides

• “Complete beginner’s guide to Y” articles

Not because this is always the most useful thing you could do for your users.

But because this is what search engines understand best.

The misalignment

On paper, a search engine’s job is to:

Find the most relevant and useful resource for a given query.

In practice, what often ranks is:

• the best‑optimised article about a tool, not the tool itself;

• the website with more long‑form content, not necessarily the better product;

• whoever has invested more into content and SEO, not whoever actually solves the problem best.

That gap between “best resource” and “best SEO asset” is the blog tax. If you build something valuable but light on text, you either pay that tax – or stay invisible.

Why tools and systems lose to text

Think about the kinds of products that get under‑rewarded in this system:

• A web app that does one thing extremely well with a clean, minimal UI.

• A directory whose value is in the data and filtering, not the prose around it.

• A piece of infrastructure or automation that integrates into someone’s workflow and “just works.”

From a user’s perspective, these are ideal. They are:

• focused

• fast

• low on noise

From a search engine’s perspective, they are often:

• thin on crawlable content

• hard to classify

• weak on traditional on‑page signals

Crawlers don’t “experience” the product the way a human user does. They mostly see:

• how much text is on the page

• how it’s structured (headings, paragraphs, lists)

• what other sites link to it

• what metadata you provide

If your standout feature is an interactive dashboard, a smart recommendation engine, or a slick workflow, none of that is easily expressible in plain HTML text without you writing about it.

So you end up doing exactly that: writing about your product in longform, not because users need more words, but because search engines do.

This pattern isn’t new: meta keywords déjà vu

We’ve seen this play out before.

In the early days of SEO, meta keywords were a thing. You told search engines what your page was about using a simple tag. It didn’t take long for people to:

• stuff every possible keyword in there

• add irrelevant keywords to siphon traffic

• use it as a cheat‑code rather than a description

The result was predictable:

• the signal became noisy and unreliable

• search engines started discounting it

• eventually, major engines simply ignored meta keywords altogether

Any explicit, easy‑to‑manipulate ranking signal follows a similar arc:

1. It’s introduced with good intentions.

2. It’s discovered by SEOs.

3. It’s exploited and overused.

4. It’s discounted or abandoned.

Structured data and schema markup already show the early symptoms of this cycle. They are extremely useful in theory – a machine‑readable way to describe what’s on a page – but they’re also being:

• used to inflate review stars

• applied in contexts where they don’t really fit

• turned into yet another surface for keyword games

The underlying problem isn’t any single feature. It’s the incentive structure: as long as clear, mechanical levers exist, people will pull them as hard as possible.

The perverse incentive: write more, not build better

This dynamic leads to a strange economy of effort:

• You can ship a brilliant tool that saves users hours every week.

• But if you don’t also produce thousands of words of “strategic” content, search may never send anyone to see it.

So founders and teams do what the system rewards:

• spin up content calendars

• produce “SEO articles” that rehash the same advice everyone else has

• write posts that exist primarily so some keyword has a place to live

Meanwhile, users searching for answers often end up:

• wading through generic content

• being told about tools instead of directly finding and using them

• losing time on pages that are optimised for bots, not humans

The search engine technically did its job – it found a page that “matches” the query. But from a human perspective, the result feels… off. You asked for a solution and got an article about solutions.

What a better search system would look like

If we started from the user’s perspective instead of the crawler’s constraints, search would behave differently.

A better system would:

• Rank tools by usefulness, not just the blogs that mention them.

• Understand that a minimal product page can still represent the best possible answer to a query.

• Use more than just text length and keyword usage as proxies for quality.

Concretely, that could mean leaning more on:

• User behaviour: Do people who land on this tool actually stay, use it, and return?

• Direct signals of utility: For web apps, things like repeat usage, task completion, or satisfaction (where measurable).

• Richer understanding of the page: Using modern AI models to interpret layout, UI, and intent – not just count words and headings.

At that point, a small, focused uptime monitoring tool with a tight, honest landing page could outrank yet another “Top 37 uptime monitoring tools you need in 2026” article.

We’re seeing early hints of this direction with:

• AI answers layered on top of web results

• more emphasis on “helpful content” and less tolerance for obvious fluff

• experiments in surfacing apps, tools, and answers more directly

But for now, the old incentives still dominate.

So what should founders do today?

If you’re building a SaaS, a directory, a marketplace, or a specialised tool, you’re stuck in a hybrid reality:

• The system is flawed.

• But you still need to operate within it.

A few pragmatic guidelines:

1. Accept that some text is necessary.
   You don’t need to turn your product into a content farm, but your site needs enough descriptive, structured text that a search engine can understand what you do and who you help.

2. Make content genuinely useful.
   If you’re going to write, write things that:

   • genuinely help your ideal users

   • explain your approach, trade‑offs, and constraints

   • show real examples, case studies, or data

Use content to bridge the gap between your product and the problems it solves, not just to chase keywords.

3. Lean on other discovery channels.
   Search isn’t the only way to be found. For many tools, it may not even be the best channel at the start. Consider:

   • niche communities (forums, subreddits, Discords)

   • integrations and partnerships

   • directories, comparison sites, and marketplaces

   • targeted outreach or small pilot programs

These can get real users in front of your product long before Google “decides” you exist.

4. Design your site for humans first, crawlers second.
   It’s still worth doing the basics right – titles, headings, internal links, structured data where appropriate – but not at the expense of clarity and usability for real people.

5. Keep an eye on how search evolves.
   As AI‑driven search and answer engines mature, the bias toward walls of text will probably weaken. If and when that happens, lean products that are already great for users will be in a stronger position than content‑bloated ones.

The blog tax is real, but it’s not the endgame

It’s frustrating – and a bit absurd – that in 2025 the easiest way to make a product discoverable by search is still to wrap it in longform text.

Many of the most valuable resources on the web are:

• small, sharp tools

• carefully curated directories

• systems that automate something boring and painful

Those things should be first‑class citizens in search, not second‑class ones forced to drag a blog behind them just to be seen.

Until search engines catch up, most of us will keep paying the blog tax in one form or another. But it’s worth remembering that this is a limitation of the current system, not a law of nature.

The end goal shouldn’t be “who wrote the longest article about X.”
It should be: who actually solves the problem best.

“How much return am I getting for each unit of risk I take?”

This is the basic idea behind things like the Sharpe ratio. But you don’t need formulas to use the concept. You only need to compare average long‑term returns with how wildly those returns move around.

Below is a simple way to do that for normal, accessible investments.

1. The idea: return per unit of risk

Two facts:

• A government bond at 3% with almost no drama can be better than a crypto coin at 30% with constant crashes.

• A slightly lower return can be objectively better if it comes with much less risk.

To make that concrete, we’ll look at:

• Average annual return – what the asset class has roughly delivered over long periods.

• Risk – how volatile it is (how much it swings up and down).

• Return ÷ risk – a simple “bang for risk” score.

This is just a simplified version of the Sharpe ratio without the math. The goal is not precision, but ranking: which assets historically gave more reward per unit of pain.

Numbers below are rounded ballpark figures from long‑term historical data (mainly US, because that’s where the best data exists). They’re not forecasts.

2. Accessible asset classes compared

We’ll only look at things a normal private investor can actually buy:

• Government bonds

• Corporate bonds (via ETFs)

• Broad stock market (via ETFs)

• Real estate (via REITs)

• Individual stocks

• Commodities

• Cryptocurrencies

Here is the simplified table:

Again: this is one simplified view over long periods, not a guarantee about the future. But some patterns are very robust.

3. What the table actually tells you

3.1 Corporate bond ETFs: the quiet workhorse

Corporate bond ETFs sit in an interesting place:

• Return: higher than government bonds.

• Risk: much lower than stocks.

• Result: the highest return per unit of risk in our comparison.

You’re lending money to many companies at once, not betting on a single stock. The ETF wrapper gives you diversification across issuers, sectors and maturities.

For a private investor, that often translates into:

• More yield than cash or government bonds.

• Less gut‑wrenching volatility than stocks.

If you only took one idea from this article, it could be: corporate bond ETFs are an underrated middle ground between safety and growth.

3.2 Broad equity ETFs: the long‑term engine

Broad equity ETFs (for example, funds tracking large diversified indices) are the classic long‑term growth tool.

• Historically strong returns (around 8% real/nominal depending on the market and period).

• More volatile than bonds, but you are owning pieces of productive businesses.

• On a return‑per‑risk basis, they score well, just behind corporate bonds in our simplified table.

For most long‑term investors, broad equity ETFs are the growth engine of the portfolio.

3.3 Government bonds and REITs: stability and income

Government bonds:

• Lower returns but also lower volatility.

• Their role is not to make you rich, but to buffer shocks and provide a modest yield.

REITs (listed real estate):

• Equity‑like volatility, property‑linked income.

• Slightly better returns historically than broad stocks in some periods, but also sensitive to interest rates.

Both sit in the middle of the pack on a return‑per‑risk basis. They are useful ingredients, not magic bullets.

3.4 Individual stocks: concentrated bets

Individual stocks have:

• Similar average returns to the broad market.

• Higher single‑name risk (you can go to zero).

Your return‑per‑risk ratio can be great if you pick well. But that “if” is non‑trivial. For most people, concentrated stock picking reduces the overall return‑per‑risk of their portfolio compared to just holding a global ETF.

3.5 Commodities and crypto: lots of drama, little efficiency

Commodities:

• Often volatile.

• Long‑term returns aren’t that impressive once you adjust for inflation and roll costs.

• In our table, they have the worst return‑per‑risk ratio.

Cryptocurrencies:

• Enormous upside in some years.

• Enormous drawdowns in others.

• Even if you assume very high average returns, the volatility is so extreme that the return‑per‑risk ratio stays mediocre.

These can have a place as small, speculative satellites, not as the core where you want efficient risk‑adjusted returns.

4. A simple way to use this in your portfolio

Once you think in terms of “return per unit of risk”, your portfolio design gets simpler:

1. Pick your core growth engine
   For most people, that’s a broad, low‑cost equity ETF.

2. Add a stabilizer with a strong return‑per‑risk profile
   Corporate bond ETFs are a natural candidate here. They:

   • Improve your overall ratio.

   • Provide income.

   • Smooth the ride when stocks are volatile.

3. Use government bonds or cash for shock absorbers
   If you need short‑term liquidity or hate deep drawdowns, you can add some government bonds or a money market fund.

4. Keep speculative stuff small
   Crypto, single commodities, or very concentrated stock bets can stay in a small “fun” bucket. Assume that money can go to zero without ruining your plan.

You don’t need to compute exact Sharpe ratios or optimize every decimal. The point is to avoid obviously inefficient choices: lots of drama for not much extra return.

5. The core message

If you only remember one thing, make it this:

Don’t just ask “what can make the most money?”
Ask “what gives the most return per unit of risk for a normal investor?”

Viewed through that lens, broad equity ETFs plus corporate bond ETFs already put you in a very efficient part of the risk‑return spectrum. Everything else is fine tuning and personal preference on top.

If you just work hard and follow the right steps, you’ll succeed.

Reality is less friendly and more statistical.

You are not just building a website. You are entering a probabilistic game with low base odds, heavy skew, and a few levers you can actually control.

This post is about those odds – and how to think like a founder who plays the game rationally instead of emotionally.

What Does “Success” Even Mean?

First we need a clear definition. Let’s call a project “successful” if:

• It reaches at least $500 net profit per month

• It does so within 24 months of starting

• It sustains that level for at least six consecutive months

This isn’t a unicorn. It’s a modest, but meaningful, bootstrapped win.

If you’re honest, this is already where most projects fail.

Why the Base Odds Are Low

Ignore the success stories for a second.

Most small digital projects quietly die. They never pass a few hundred visitors per month, never find a working monetization model, or never make it past the founder’s exhaustion.

From everything we know about startups, indie projects and niche sites, a single attempt at building a profitable website probably has single digit odds.

Let’s use a simple, conservative range:

Initial chance of success per attempt: 1–5 percent

That sounds depressing, but it’s also liberating. It forces you to stop thinking in terms of one big bet and start thinking like a statistician.

The Four Multipliers of Success

Instead of treating success as magic, we can break it down into four independent questions:

1. Niche Fit – Did you pick a space where you actually have a chance?

2. Model Fit – Are you monetizing in a way that matches how value flows in that space?

3. Execution Quality – Is the thing you built any good at all by market standards?

4. Time Survival – Do you stay in the game long enough for compounding to work?

Think of your probability of success P(S) as a product of these four factors:

P(S) ≈ P(Niche Fit) × P(Model Fit) × P(Execution Quality) × P(Time Survival)

You don’t need precise numbers. The point is that if any of these terms is close to zero, the whole product is close to zero.

Let’s look at each one.

1. Niche Fit: Are You Even in the Right Arena?

Most founders underestimate how much the starting position matters.

Questions to ask:

• Are people already actively searching for this?

• Are they spending money on this problem right now?

• Who dominates the search results and mindshare?

Rough signals of poor niche fit:

• All main keywords are brutally competitive and dominated by huge brands

• The people who care about the topic don’t have much money or urgency

• The problem is real, but the buyer is unclear or scattered

Rough signals of good niche fit:

• There is clear search demand, but SERPs are fragmented and mediocre

• You can name specific, reachable customer types who already spend money

• You can articulate a painful problem in one or two sentences without jargon

The uncomfortable truth: if you choose a bad niche, you can execute extremely well and still lose.

2. Model Fit: Are You Getting Paid in the Right Way?

Even if there’s demand, you can still kill your odds with the wrong monetization model.

Very roughly, the web offers five base models:

1. Direct sales – products, services, info products

2. Lead generation – collect leads and sell them or close them yourself

3. Ads – sell attention (CPM, CPC)

4. Affiliate – send buyers to someone else for a cut

5. Subscriptions / SaaS – recurring value, recurring revenue

Questions to ask:

• Will the people I attract actually pay in this context?

• Is my monetization path aligned with their journey?

• What is my revenue per 1 000 visitors (RPM) likely to be in this niche?

Examples of bad model fit:

• Trying to monetize low-intent curiosity traffic with a high-ticket B2B offer

• Relying on ads in a tiny niche with almost no advertisers

• Selling a subscription in a space where the problem is rare and episodic

Examples of good model fit:

• High-intent, “ready to buy” search traffic to a comparison site with affiliate deals

• Painful recurring problem solved with a lightweight subscription tool

• Local intent traffic monetized via lead gen for businesses with high ticket size

If niche fit says “this is worth solving,” model fit says “this is worth paying for, in this way.”

3. Execution Quality: Does Your System Actually Work?

You can nail both niche and model and still fail if your execution is weak.

Execution is not about code elegance. It is about whether your system actually converts reality into money.

Some brutally simple execution questions:

• Can people understand what you do in five seconds on the homepage?

• Is your site fast enough not to bleed users? (LCP under ~2.5s)

• Are you at least in the ballpark of normal conversion rates for your model?

• Are you running experiments regularly, or just “hoping”?

Execution quality is where many technical founders are surprised. They build, deploy, and then wait – but they do not iterate on copy, onboarding, pricing, or UX with discipline.

Low execution quality doesn’t just reduce your revenue. It destroys your learning speed, which is even worse.

4. Time Survival: Will You Still Be Here When It Starts Working?

Even with a good niche, a viable model, and decent execution, you can still fail for a simple reason:

You run out of time, money, or motivation before compounding kicks in.

This is the most underrated factor.

Survival questions:

• How many months of runway do you have at your current burn rate?

• How many focused hours per week do you realistically put into this?

• What’s your psychological tolerance for slow progress?

A lot of founders technically “could” succeed, but their effective P(Time Survival) is near zero. They pivot, burn out, or give up before any flywheel spins up.

A Simple Example: Two Founders, Same Idea

Imagine two people launching the same kind of site: a niche comparison website monetized with affiliate deals.

Founder A

• Picks a niche with huge search volume but brutal competition (credit cards, VPNs, etc.)

• Monetizes with affiliate offers (good model fit in theory)

• Execution is mediocre: generic content, slow site, little CRO

• Gives up after 8 months of weak results

Very roughly:

• Niche Fit: poor → low probability

• Model Fit: decent → medium

• Execution: weak → low

• Time Survival: weak → low

Multiply four “low” factors and the end result is basically noise-level odds.

Founder B

• Picks a smaller, underserved niche with clear intent (e.g. specialized B2B tools)

• Monetizes with a mix of affiliate + lead gen to a few partners

• Obsesses over speed, clarity, and conversion

• Commits to 18–24 months and ships every week

Now the picture looks very different:

• Niche Fit: good → medium/high

• Model Fit: aligned → medium/high

• Execution: improving → medium

• Time Survival: strong → medium/high

The original base rate hasn’t changed. But this founder has systematically pushed each term up. The final probability of success is still not guaranteed, but it’s no longer a lottery ticket.

Thinking in Portfolios Instead of Single Bets

Here’s the key mental shift:

If a single website attempt has, say, a 5 percent chance of hitting your definition of success, then you shouldn’t be thinking, “How do I make this one work at all costs?”

You should be thinking:

How do I take multiple, informed shots while increasing my odds on each new attempt?

Very roughly, if each project had a 5 percent independent chance of success, then building ten projects over a few years gives you:

P(at least one success) = 1 − (1 − 0.05)¹⁰ ≈ 40%

Reality is messier than this toy model, but the principle stands:

• One shot feels romantic, but is statistically brutal.

• A portfolio of shots with learning carried forward is rational.

Each new attempt should:

• Use a better-chosen niche

• Use a better-matched model

• Be executed with more skill and faster feedback loops

• Be structured in a way that doesn’t destroy your runway and motivation

How to Estimate Where You Stand (Without Fancy Math)

You don’t need a PhD to use this thinking. You just need a honest self-assessment.

For each of the four dimensions, rate yourself from 1 to 5:

1. Niche Fit – From “no idea if anyone will pay for this” (1) to “clear pain and clear payers” (5).

2. Model Fit – From “I slapped on ads or affiliate links and hope” (1) to “my monetization matches how people already buy” (5).

3. Execution Quality – From “it barely works and I don’t track anything” (1) to “I ship fast, measure, and improve regularly” (5).

4. Time Survival – From “I have a few months before I must quit” (1) to “I can keep going for years without destroying my life” (5).

You don’t need exact probabilities. The important part is:

• If any dimension is at 1, treat it as an emergency.

• If you’re sitting at 2–3 in all four, expect slow and fragile progress.

• If you’re moving 3→4→5 across the board over time, your personal base rate is going up.

What This Means for Founders

Most founders are told some version of: "Believe in yourself and never give up."

What you actually need is closer to this:

• Accept that a single attempt has low odds.

• Break success into niche, model, execution, survival.

• Systematically raise each term instead of hoping.

• Design your life and finances so you can take multiple shots.

When you do that, you stop playing the role of the hero in a startup fairy tale and start acting like an engineer of probability.

You cannot control the outcome. But you can control the structure of the game you’re playing.

And if you keep improving that structure, project after project, at some point the numbers quietly shift in your favor.

• Make you believe you are one genius all-nighter away from changing the world.

• Make you feel like if you have not started a unicorn in your parents’ garage by 20, you are already too late.

Both reactions miss the point.

The interesting part is not the garage. The interesting part is the system behind the garage: the constraints, behaviors and decisions that keep showing up in these stories. Those are the few things you can actually copy.

This is a practical look at what Jobs, Gates, Musk and Zuckerberg actually did in their early years, what still works in 2026, and how to apply it if you are a regular, non billionaire human starting from an apartment, dorm or kitchen table.

1. What actually happened in those garages and dorms

The myth: a couple of geniuses disappear into a garage, emerge with a world changing product, the rest is history.

The reality is more boring and more useful.

Apple: a hobbyist kit, not a revolution

In 1976, Steve Jobs and Steve Wozniak based their new company, Apple Computer, out of the garage of Jobs’ parents in Los Altos. That part of the story is true.

The part that gets lost: the garage was not some magical lab. Wozniak later said they did “no designs there… no manufacturing there.” The garage was cheap space: a place to store parts, assemble boards, and load finished Apple I computers into the car to deliver to a local computer shop.

The first Apple product was not a polished Macintosh. It was a bare circuit board sold to hobbyists. They got a purchase order from a local retailer, built 50 boards as fast and as cheaply as they could, collected cash, and only then could they think about a second run.

Key point: the garage was a cost saving hack wrapped around a very small, very specific product for a niche audience.

Microsoft: tiny office, one big customer

In 1975, Bill Gates and Paul Allen did not start with a giant vision board about “a computer in every home.” They saw a single opportunity: a new kit computer called the Altair 8800 that had no good programming language.

They wrote a BASIC interpreter, convinced the manufacturer to license it, and suddenly had a real customer on day one. The company that became Microsoft ran out of a tiny office in Albuquerque. The setup was closer to a scrappy agency than a modern startup campus.

Key point: they started with one clear customer and one clear product, and kept costs absurdly low while they shipped.

Elon Musk: sleeping in the office to keep burn near zero

In 1995, Elon and Kimbal Musk started Zip2, an online city guide. They had almost no money, so they simply removed the line item called “living expenses.”

They rented a small office, slept on the floor, showered at the YMCA and used a single computer as both development machine and server. They hired commission only salespeople to sell listings door to door. The moment there was a little cash, they put it into the product and sales, not comfort.

Key point: their “garage” was a deliberate decision to make burn rate almost zero and buy time to figure things out.

Facebook: one dorm, one campus, then the graph expands

In 2004, Mark Zuckerberg launched Thefacebook from his Harvard dorm room. The product was tiny in scope: profiles, photos, basic social graph – for one campus only.

The magic was not the code. It was the fit with a very specific environment: elite universities where people cared a lot about social status and were already online all day.

Adoption was explosive inside that bubble. Only after it worked at Harvard did they expand to other universities, then other networks, then the open web. Funding and a real office came after that, not before.

Key point: Facebook started as a narrow, almost toy sized product that fit one social context perfectly.

2. The real pattern behind the myths

If you strip away the hero worship, these stories share a boring but powerful pattern:

1. A big wave in its early phase
   Personal computers in the 70s, the web in the 90s, social networking in the 2000s. The founders were early on a wave that was going to grow with or without them.

2. A small, sharp wedge into that wave

   • Apple: a hobbyist computer kit for local nerds.

   • Microsoft: BASIC for one specific computer.

   • Zip2: yellow pages for newspapers.

   • Facebook: a social directory for Harvard students.

3. Ridiculously low burn
   Free spaces (garages, dorms, apartments), no salaries at first, no nice offices, almost no fixed costs. Comfort was postponed on purpose.

4. Fast, imperfect shipping
   They shipped something that worked, not something that was done. Bugs, hacks and ugly design were tolerated as long as real users could use it.

5. A tight feedback loop with real users
   Many of those early users were friends, classmates or local customers you could talk to in person. Feedback was fast and brutal.

6. Relentless iteration and a stupid amount of work
   Long hours, context switching between coding, selling, support and fundraising. Not glamorous. Just grind.

7. Some luck, multiplied by action
   Being early on the right wave is luck. Turning that into a business is work. Many people were “around” the same opportunities. Very few actually built something and stuck with it.

You cannot copy the luck or the exact timing. You can copy the wedge, the low burn, the shipping cadence and the feedback loop.

3. What has changed and what has not (2026 reality)

The world you are starting in today is not the world of 1976 or even 2004.

What is harder now

• Competition and noise.
  Every idea has a dozen clones on Product Hunt before lunch. Users are flooded with apps and pitches.

• Distribution is the bottleneck.
  Building a product is easier than ever. Getting attention and trust is the hard part.

• Incumbents are stronger.
  Big tech has network effects, data and capital. They can copy features quickly if you grow enough to be noticed.

What is easier now

• Infrastructure is almost free at the start.
  You get hosting, databases, version control, payments, email and AI via APIs for pocket change.

• Knowledge is free.
  Tutorials, open source, forums and AI tools make it possible to learn and build much faster than previous generations.

• Global reach from day one.
  You do not need a local hardware store or a single campus. Your first users can be in five countries by accident.

So the modern “garage” is not a physical room. It is a cheap laptop, a stable internet connection, a Stripe account, a GitHub repo and a couple of SaaS subscriptions. The pattern, however, is the same: pick a wave, find a wedge, keep burn low, iterate in public.

4. A simple system you can actually run

Let us turn the pattern into something concrete you can run from an apartment, dorm or kitchen table.

Think of it as a 6–18 month system, not a weekend hackathon.

Step 1: Pick your wave and wedge

1. Choose a growing wave you understand at least a little.
   Examples: AI tooling, developer productivity, creator economy, niche SaaS, vertical marketplaces, remote work tooling.

2. Define a stupidly narrow wedge into that wave.
   Instead of “AI for e commerce,” think “AI that turns product feeds into ready to post social content for Etsy sellers,” or “queue management SaaS for vets in small clinics,” not “healthcare platform.”

Litmus tests for a good wedge:

• You can describe the user and problem in one sentence.

• You could plausibly reach the first 50 users manually (email, DMs, communities).

Step 2: Fix your constraints on purpose

Garage stories are mostly stories about constraints. Use that as a feature.

Write down your rules:

• Time budget. How many hours per week can you realistically invest for at least a year?

• Money budget. How much are you willing to burn per month without panicking? Assume zero external funding.

• Comfort sacrifices. What are you willing to trade temporarily? Nights, weekends, side gigs, lifestyle upgrades?

Then design your setup to enforce low burn:

• Work from home or shared spaces.

• Use free or cheap tools until they hurt.

• Avoid fixed costs: employees, long term contracts, big office, custom hardware.

The goal is to buy yourself runway: 12–18 months to experiment without going broke.

Step 3: Build the smallest thing that proves the point

Your first goal is not to build “the app.” Your first goal is to prove that:

“This specific type of user has this specific problem and is willing to use something clunky if it solves it.”

That means:

• Build a thin vertical slice: one core workflow that goes from input to outcome.

• Accept ugly UI, manual steps, duct taped backends.

• Use no code or scripts if they get you there faster.

If you cannot ship a thin slice in 4–6 weeks with your current constraints, the scope is probably too big.

Step 4: Put it in front of real users fast

Stop polishing alone. Pick a small number of real people:

• Friends or colleagues who match the target user.

• People in niche communities (Reddit, Discord, forums, Slack groups).

• Small businesses or creators you already know.

Offer them something extremely clear:

• “I built X that does Y for people like you. Want to try it for free if I fix issues quickly?”

Watch them use it. Take notes. Ask dumb questions:

• “What did you expect here?”

• “What was annoying?”

• “What are you doing today instead of this?”

Do not argue. Do not pitch. Just observe.

Step 5: Iterate, or kill and recycle

Every 4–6 weeks, make a brutal decision:

• Double down: Users are coming back on their own, telling others, or asking for more.

• Pivot the wedge: Problem seems real, but your approach misses. Try a different angle for the same user.

• Kill it: Users do not care enough, and you are pushing a rope. Archive the code, keep the lessons, move on.

The garage myth hides how often early projects died or pivoted before the “success story” started. Treat small failures as part of the system, not as identity.

Step 6: Only then think about scale and funding

Funding, offices, hiring and PR are all second order. In the old stories they came after there was a working wedge:

• Apple got serious investment after the Apple II started selling.

• Facebook got its first check after strong engagement on US campuses.

• Airbnb got into Y Combinator after they showed desperate but effective cereal box hustle.

Your version:

• Once you have a small group of users who would be upset if you shut down, you have options.

• You can slowly charge them.

• You can show real usage graphs to potential investors.

• Or you can keep it as a calm, profitable small business.

There is no law that says you must swing for a trillion dollar outcome. “A solid, weird little SaaS that pays for your life” is a perfectly valid endgame.

5. How long does it actually take?

Looking at the famous cases is misleading. The narrative jumps from “garage” to “IPO” in a few paragraphs.

A more honest expectation:

• 0–6 months: learning the domain, talking to users, shipping first ugly versions.

• 6–18 months: either you find a real wedge with traction, or you accumulate a few failed attempts and a lot of scar tissue.

• 3–5 years: enough time for one good wedge to turn into a stable business if you keep at it.

There are outliers who explode faster. There are many more who quietly grind for years.

The point is not to predict the timeline. The point is to accept up front that you are signing up for a multi year game, not a viral weekend.

6. So, is it luck or a system?

Both.

• You do not control the macro wave, the exact timing or who you happen to meet.

• You do control whether you pick a growing space, define a narrow wedge, keep burn low, ship fast and keep talking to users.

If you do the second group well, you increase your odds that when luck shows up, there is something for it to multiply.

The mistake is to either:

• Dismiss the legends as “just lucky,” and therefore learn nothing, or

• Treat their biographies as step by step instructions you must copy, including the turtlenecks and sleeping on the floor.

A saner approach:

• Copy their constraints (low burn, small wedge, real users, long runway).

• Copy their behaviors (shipping, iteration, discomfort tolerance).

• Do not copy their specific market, aesthetic or personal mythology.

Your version of the “garage” will look different. It might be a cramped flat, a dorm bed with a laptop, or a kitchen table after the kids are asleep.

That is fine. The building blocks are the same: pick a wave, carve a wedge, keep burn low, ship often, stay in the game long enough for luck to notice you.

That is as close to a system as these stories will ever give you.

After months of real-world testing, here’s what I found:

The Reality: Social Automation Brings Views, Not Store Traffic

I connected Print2Social to Facebook, Instagram, and TikTok and let it auto-post hundreds of pieces of content, including lifestyle images, product highlights, and short-form videos. Some TikTok videos reached over 700 views, but none of it translated into real store traffic, even after optimizing captions, hashtags, and link-in-bio strategies.

Social media is designed to keep users inside the app. Even if you gain views or followers, very few people will actually click out to your website. For indie store owners, automated posting alone just does not drive targeted, purchase-ready traffic.

Why I’m Pivoting: A New Solution for Actual Sales

When I started Print2Social, my mission was to help small shop owners build real brands and get their first customers, not just social “vanity metrics.” I now realize that posting content is not enough. What really matters is creating a direct path from content to purchase.

So I am pivoting Print2Social in a new direction with shoppable social commerce as the focus.

What’s next for Print2Social?
We are building a tool that lets POD brands and indie shop owners easily publish shoppable social content by syncing their product catalogs and automating tagged posts across Meta Shops, TikTok Shop, and Pinterest Shopping. This will streamline the path from content to in-app purchase. When a customer sees your post, they can buy your product right inside TikTok, Instagram, or Pinterest without leaving the app.

Here’s what we are working on now

• Sync your POD catalog (Shopify, WooCommerce, Printful, Printify) to all major social commerce platforms

• Auto-generate media assets with product tags so every Reel, Story, Pin, or TikTok is instantly shoppable

• Schedule and publish your shoppable content at the best times for your audience

This is our answer to the “views but no clicks” problem and I believe it will help brands turn engagement into actual revenue, not just followers.

My Advice to Other Founders

Do not mistake social reach for meaningful traffic or sales.

Test your assumptions with real data, even if it means admitting when something is not working
Be willing to pivot toward solutions that actually solve the core problem for your users

If you are a store owner or builder who has struggled with this, or want to get early access to the new Print2Social, let’s talk. Early beta is available at https://beta.print2social.com if you want to check it out.

How AI Writing Tools Fit Into My Business

Running several businesses, including Print2Social, PrintOnDemandBusiness.com, and AffiliateCompanies.net, content marketing is crucial for attracting traffic. I don’t have the luxury to write every piece myself, so AI tools help me scale content production without sacrificing too much on quality.

SEObot: Fully Autonomous and Surprisingly Effective

For Print2Social’s blog, I tested SEObot (seobotai.com*), and what surprised me most was how hands-off it was. I set the topics, and the system took care of the rest, from keyword research to internal linking and even some traffic analysis.

Some of the articles written by SEObot, like “Print on Demand Automation”, actually brought traffic and ranked well. The major upside? It saved me hours of work, and I could focus on other parts of the business.

Pros:

• Fully autonomous: create content with almost no manual effort

• Built-in keyword research and internal linking

• Traffic and performance monitoring

Cons:

• Limited editing capabilities (but that’s the point I guess)

• Not ideal if you want a very personalized brand voice

Koala Writer: User-Friendly and High-Quality Long-Form Content

For PrintOnDemandBusiness.com and AffiliateCompanies.net, I relied a lot on Koala Writer (koala.sh*). Articles like “Best Print on Demand Sites” and “Start an Affiliate Program” were written using Koala and performed exceptionally well.

What I love about Koala is its balance between quality and ease of use. The interface is straightforward, and content feels human-like, especially when using GPT-4 (though you burn through credits faster). Koala’s ability to pull in data from the top-ranking articles also helps create relevant and SEO-friendly content. I paid $45 for 10,000 credits, which made it an affordable starting point.

Pros:

• High-quality content that doesn’t sound robotic

• Easy to use, clean interface

• Offers a lot of other features besides article writing

Cons:

• Linking can sometimes point to unrelated content if not carefully reviewed

• GPT-4 content uses more credits (higher cost)

Perplexity Deep Research: When You Need Facts, Not Fluff

When I needed research-backed content, like this review of Gelato, I turned to Perplexity’s Deep Research. What impressed me is how thorough it is: it finds real sources, provides citations, and lets me verify the data.

While it’s not an “out-of-the-box” blog post generator like SEObot or Koala, Perplexity is invaluable when accuracy and depth matter. I also used it for social media content ideation and understanding complex SEO topics.

Pros:

• Research-backed, factual content with citations

• Great for expert-level articles or sensitive topics

• Free option available with limitations

Cons:

• Takes more time to generate content (2–4 minutes)

• Requires manual crafting to turn research into a polished post

Other Tools on My Radar

Besides the tools I’ve used extensively, I’ve researched and considered ContentShake AI, Scalenut, and Outrank:

• ContentShake AI (by Semrush): Looks powerful for SEO agencies and businesses already using Semrush. It’s a bit on the pricey side ($60/month) but could be worth it for integrated keyword analysis and optimization.

• Scalenut: Strong on SERP analysis and SEO scoring. Probably great for agencies, but a steeper learning curve. I haven’t adopted it yet because of time constraints.

• Outrank (outrank.so*): Promising as an all-in-one platform that combines content and image generation. However, it is also on the pricey side at $99/month.

What Worked Best for Me and Why

• For hands-off content creation, SEObot delivered quick wins for Print2Social. Perfect when I didn’t have time to manage writers or edit content myself.

• For long-form, high-quality posts, Koala Writer won. Articles over 2,000 words from Koala perform very well, and it’s great when you want a human-like tone.

• For research-backed content, Perplexity Deep Research is my go-to tool when I need accurate, factual information to build authority.

Lessons Learned and Final Thoughts

• AI is not a silver bullet. You still need to review and edit the output to ensure quality and relevance, especially links and citations.

• Mixing tools works best. I use different tools for different projects and article types, for example, Perplexity for research-heavy pieces, Koala for long-form content, and SEObot when I want a fully autonomous solution.

My Top Performing AI-Generated Articles

• Best Print on Demand Sites — Koala Writer

• Print on Demand Trends 2025 — Koala Writer

• Start an Affiliate Program — Koala Writer

• Gelato POD Review — Perplexity Deep Research

• Print on Demand Automation — SEObot

• 5 AI Content Curation Tools — SEObot

Final Recommendation

If you’re considering AI for SEO content, my advice is to try different tools and see what works for your workflow. Start small, maybe with SEObot for quick content, Koala for longer posts, and Perplexity for research. And don’t forget to edit, personalize, and optimize the output. AI is powerful, but human touch still makes the difference. I always start with AI version and then optimise high-performing content manually.

If you’re curious, I’m planning to explore other tools like Scalenut and Outrank soon, so maybe part two of this article will be coming!

What’s your experience with AI writing tools? If you’ve used any of these (or others), drop me a comment or message. Would love to exchange notes!

\ affiliate link — if you make a purchase, I may receive a commission at no extra cost to you.*

In this guide, I'll walk you through how to track outbound affiliate link clicks in GA4 using Enhanced Measurement and custom Explorations. Plus, I’ll share a simple alternative using LinkTracker, a centralized platform for shortening and tracking links.

Step 1: Enable Enhanced Measurement for Automatic Outbound Link Tracking

Google Analytics 4 has an automatic feature called Enhanced Measurement, which makes tracking outbound links (like affiliate links) incredibly simple. With this setting enabled, you don’t need to manually tag links or configure Google Tag Manager.

Here’s how to ensure Enhanced Measurement is enabled:

1. Go to Admin in your GA4 account.

2. Under Property, select Data Streams, then click on your Web data stream.

3. In the Enhanced Measurement section, ensure that Outbound clicks is toggled on.

This enables GA4 to automatically track clicks on links that lead users away from your site, including any affiliate links you share.

Step 2: Create a Custom Exploration to View Outbound Link Clicks

While outbound clicks are tracked automatically, the default reports might not show you the exact URLs that users are clicking. To track the specific affiliate links that are being clicked, we’ll create a custom Exploration.

Here’s how to set up your exploration:

1. Open Explore in GA4: On the left-hand menu, click Explore to start creating a custom report.

2. Set Up Your Exploration:Click Blank to create a new exploration and give it a descriptive name, like “Outbound Link Clicks.”In the Variables section on the left, click + to add dimensions and metrics.Add Link URL (this will show which links were clicked) and Event Name as dimensions.Add Event Count as the metric (this will show how many times each link was clicked).

3. Configure Rows and Values:In the Rows section, drag Link URL to populate the list of URLs clicked.In the Values section, drag Event Count to display the number of clicks for each link.

4. Apply Filters:Under Filters, set a filter so that Event Name exactly matches "click". This ensures you’re only tracking outbound link clicks and not other types of engagement.

5. Run the Exploration:Once configured, refresh the exploration to view the data (if it does not update automatically). You’ll now see a list of all the external links (affiliate links) clicked and how many times each was clicked.

This report will give you the specific data on which outbound affiliate links are receiving the most attention from your users.

Step 3: Access and Monitor Your Report

Once you’ve set up this custom exploration, you can easily access it from the Explore tab in GA4 anytime you need to review performance. This gives you an ongoing way to track outbound clicks without needing to configure new reports every time.

To test the setup or verify real-time clicks, you can also use DebugView in GA4:

• Navigate to Admin > DebugView.

• Click on outbound links on your site, and watch the click events come through in real time with details like the link_url parameter.

Bonus: Use Event-Based Goals for Affiliate Clicks

If clicks on certain affiliate links are critical to your business goals, you can set up event-based conversions in GA4. For example:

1. Create a custom event for clicks on your most important affiliate links using the link_url parameter.

2. Mark this event as a conversion in GA4, so you can track it as part of your conversion goals.

This will help you track how many clicks on specific affiliate links contribute to your overall marketing objectives.

An Easier Alternative: Track Affiliate Links with LinkTracker

If you’d rather not configure Google Analytics, or if you’re using a different web analytics platform, LinkTracker offers a hassle-free solution. With LinkTracker (currently in beta), you can shorten your affiliate links and track their performance across multiple platforms in one centralized dashboard. This tool allows you to monitor clicks, performance data, and easily manage all your links without needing to log into multiple systems or configure advanced analytics. It’s a simple and effective way to keep track of your affiliate marketing efforts, especially for those who prefer an all-in-one tool.

Final Thoughts

Tracking outbound affiliate link clicks is crucial for optimizing your affiliate marketing strategy. Whether you choose to use Google Analytics 4 or a simpler tool like LinkTracker, gaining visibility into how users engage with your affiliate links will help you focus on what works.

With the powerful tools offered by GA4, including Enhanced Measurement and Explorations, you can track and analyze affiliate link performance without needing any extra plugins or third-party software. For those who prefer a more streamlined approach, LinkTracker provides an easy-to-use solution for tracking affiliate links across multiple platforms.

Polr

Polr is a PHP-based, open-source link shortener, with an API access and basic analytics. While its user interface may have charmed users back in 2013 at the project's inception, it now falls short of contemporary design standards.

On the analytics front, this link shortener furnishes insights into visits, referrers, and the geographical distribution of visitors. It has a demo version online, which you can test, before you decide to install it on your server.

I decided to give it a whirl myself, but after poking around in the demo, I didn't even bother with the hassle of installing it on my own machine.

However, it's worth noting that Polr isn't packaged within a container, necessitating manual setup. Nonetheless, for those willing to undertake the effort and requiring only basic analytics, the project is readily available on GitHub, where it garners a commendable 4.9k stars.

YOURLS

Originating in 2009, this link shortener stands as one of the oldest in the field. Developed in PHP, it boasts a robust ecosystem comprising over 200 plugins designed to expand its functionalities.

Despite my attempts to deploy it within various containerized environments - via Docker image on a Lima machine, both with and without docker-compose and later within a Minikube environment using Helm - I encountered persistent setbacks. Whether due to my own missteps or shortcomings in the Docker image's accuracy or currency, I found myself unable to achieve a successful deployment.

Compounding this challenge, as a macOS Sonoma user, I faced the additional hurdle of PHP support removal. To circumvent this limitation, I resorted to manual installation. Employing the familiar brew install php command, which I rely on for most software installations, I obtained the necessary instructions to integrate PHP with Apache:

To enable PHP in Apache add the following to httpd.conf and restart Apache:
    LoadModule php_module /usr/local/opt/php/lib/httpd/modules/libphp.so

    <FilesMatch \.php$>
        SetHandler application/x-httpd-php
    </FilesMatch>

Finally, check DirectoryIndex includes index.php
    DirectoryIndex index.php index.html

However, upon executing the instructions, macOS Gatekeeper intervened, flagging the module as unsigned. While I won't delve into the intricacies here, you can refer to a comprehensive guide provided in a Medium article for detailed instructions. Feeling overwhelmed by the complexity of the process, I made the decision to pivot and explore alternative solutions.

Nevertheless, the project continues to receive active maintenance from its creator, Ozh Richard, and boasts a thriving community of contributors. Its source code is readily available on GitHub, where it has garnered an impressive 10k stars, indicative of its widespread adoption and popularity within the developer community.

Kutt

Kutt represents a sleek, contemporary option, delivering a robust user experience alongside an array of appealing features. Among its highlights are customizable short URLs, comprehensive click tracking, and detailed analytics.

Under the hood, Kutt's tech-stack includes Node.js with Express, Passport for authentication, React with Next.js for frontend rendering, Easy Peasy for state management, styled-components for CSS styling, and Recharts for chart visualization. Data storage is handled by PostgreSQL, complemented by Redis for caching, while deployment is streamlined through Docker.

It boasts browser extensions, a handy CLI, and versatile clients and SDKs for almost any platform you can think of. Plus, it plays nice with ShareX, the ultimate screen capture and file-sharing tool.

However, as of writing this, the hosted version at kutt.it seems to have taken a hiatus. Moreover, its development pace has slowed down, and its tech-stack isn't exactly keeping up with the times. Attempting a manual installation via npm was a headache, thanks to pesky dependency conflicts, leaving Docker as the only viable option.

Even after firing it up in Docker, creating an account proved to be an exercise in futility, with the UI offering nothing more than a vague An error occurred message. Call me lazy, but I wasn't keen on diving into container logs and hunting down root causes. Nevertheless, I'm sure with a bit more effort, one could get it up and running smoothly.

It's open-source under the MIT license, living its best life on GitHub with a respectable 8k stars. And hey, word on the street is that the maintainer's already cooking up a version 3.0!

Shlink

Shlink is a self-hosted URL shortener offering a REST API and a CLI interface for interaction. It also includes a Progressive Web Application (PWA) for interacting with multiple Shlink instances.

Similar to Kutt, Shlink can be run via Docker with an internal database. The only requirement is an API key for GeoLite2, used for geolocation data.

To test Shlink locally with ease, Docker users can simply execute the following command:

docker run \
    --name my_shlink \
    -p 8080:8080 \
    -e DEFAULT_DOMAIN=localhost \
    -e IS_HTTPS_ENABLED=false \
    -e GEOLITE_LICENSE_KEY=your_license_key \
    shlinkio/shlink:stable

This command initiates the Shlink server, encompassing both a REST API and a CLI. Subsequently, you can utilise the CLI to generate your API key:

docker exec -it my_shlink shlink api-key:generate

When experimenting with the CLI, if you create a link using the command docker exec -it my_shlink shlink short-url:create, the resulting short link may not include the default port 8080. Therefore, you have to add it manually for the link to work (e.g. http://localhost:8080).

Additionally, the PWA, commonly used for accessing Shlink, can also be installed and operated via Docker by executing:

docker run \
    --name shlink-web-client \
    -p 8000:8080 \
    -e SHLINK_SERVER_URL=http://localhost:8080 \
    -e SHLINK_SERVER_API_KEY=your_generated_key \
    shlinkio/shlink-web-client

Upon visiting http://localhost:8000 you will be greeted with a user-friendly Web App interface complete with analytics. What I find cool by this link shortener is the ability to manage multiple servers within a single interface. 😎

Besides the number of visits for each link, the provided analytics include operating systems, browsers, referrers, countries and cities. Data series can be shown for any period, from one day to a year or custom ranges.

Other interesting features include QR code generation, redirection rules based on devices, languages or query parameters, editing short URL's after creation and comparing statistics for up to five short links. And all this is just on the first glance at the Web App, and there is more. Very powerful!

All the kudos to the author and maintainer Alejandro Celaya, who has been building the project actively since 2016! 🤯

It's definitely underrated with 2.7k stars on GitHub, considering everything this link shortener offers. For those interested, you can check out the repository here: https://github.com/shlinkio/shlink ⭐️

Dub.co

For those in search of a contemporary solution for link shortening and analytics, Dub.co is worth considering. When you visit this hosted service, you'll immediately notice its modern and user-friendly design, which is typical of today's startup landscape.

Dub.co boasts a modern tech-stack, including Next.js, TailwindCSS, Prisma, NextAuth.js, and BoxyHQ for authentication, alongside Turborepo as a robust build system. It follows a cloud-first approach, utilizing various managed services:

• Clickhouse database, managed by Tinybird - used for time-series click data

• Redis database, managed by Upstash - for caching link metadata and serving redirects

• MySQL database, managed by PlanetScale - for storing the actual user and link data

Whether you choose to deploy it locally or integrate it into your existing infrastructure, you'll need to create accounts with the mentioned service providers. Furthermore, you can use Postmark for sending emails and Unsplash to customise your OpenGraph images.

There is no Docker image, but installation is smooth nonetheless, thanks to a nice looking documentation powered by Mintlify. The only issues I ran into, while setting it up locally, were missing POSTMARK_API_KEY (optional according to the documentation) and @dub/ui and @dub/utils modules not building properly. But it was nothing an average technical user can't solve.

Analytics provide visits, referrers, locations by country or city, devices, browsers, and operating systems. Essentially, it covers everything you might need to effectively track your campaign's performance. What I found the most impressive with Dub.co is its extensive options for link creation: UTM parameters, custom social media cards, link cloaking, password protection, expiration date, iOS, Android and Geo-based targeting. It's all there! 🤯

Steven Tey has done an outstanding job with Dub.co, and its success is evident from its recent launch on Product Hunt. Dub.co quickly rose to become 1# Product of the Day and 1# Product of the Week. With its continued momentum, it's well on its way to being a #1 Product of the Month. This significant recognition is sure to propel Dub.co to even greater success in the future.

Dub.co is licensed under the AGPL-3.0 license and has garnered an impressive 15.7k stars on GitHub. 👏

linktracker.info

This article would not be complete without me mentioning my own take on link shortening and analytics: LinkTracker.

It features a simple interface to create and organise short links. Links can be categorised and tagged. Analytics are similar to what we have seen with other link shorteners: visits, browsers, devices, referrers and countries.

All shortened links are managed in a single table view, with statistics shown below. Currently, statistics are aggregated for all the links, except for visits, which are the most important statistic and therefore also shown for individual links.

Tech-stack is Next.js, TailwindCSS and AntDesign. Data is stored in a PostgreSQL database managed by Supabase, with Prisma serving as the ORM.

It's completely free to use and you can try it at https://linktracker.info. 🙏

Unshorten - just in case

As with any link shortening service, it's essential to consider the potential risks associated with spam and security vulnerabilities. Open-source solutions often offer greater transparency and security assurances.

If you ever encounter a short link and have doubts about its legitimacy, you can utilise the free "unshorten" tool available at unshorten.me. This tool helps you expand shortened links, providing insight into their destination and assisting in verifying their authenticity.

Awesome list

If you find this topic intriguing and wish to delve deeper, I highly recommend exploring the "awesome" list on GitHub dedicated to link shortening and management tools.

Thank you for taking the time to read this far. I hope you found the information useful. Feel free to reach out if you have any further questions or feedback. ✌️