The Young Entrepreneur

Day 7: The Fastest Way to Lose Confidence in Your Own Code

The Young Entrepreneur — Fri, 31 Jul 2026 21:56:42 GMT

There are basically two versions of every startup.

The one in your head.

And the one your first tester actually uses.

For the past few weeks, I thought everything was finally working. The app looked simply stunning, the features worked, and I was already thinking about launching.

Then I started UAT (User Acceptance Testing).

Everything broke.

Buttons stopped working. Pages that loaded perfectly before suddenly didn’t. Features I spent hours building somehow found completely new ways to fail.

The funniest part is that my testers weren’t trying to break the app.

They were just using it.

They clicked buttons I never thought anyone would click.

They typed stuff I never expected.

They skipped steps that I thought were obvious.

And somehow they found bugs in under five minutes that I had missed for weeks.

Leading to my ultimate crashout which looked something like this:

But in my crashout reflection I realized that testing isn’t about proving your app works.

It’s about finding all the reasons it doesn’t.

Every bug you find before launch is one less bug your users have to deal with later.

It’s annoying now, but it’s way better than getting a bunch of emails saying, “Your app doesn’t work.”

So if you’re building something and it feels like everything is falling apart during testing...

That’s actually a good sign.

It means people are finally using your app like real users instead of like the person who built it.

Now if you’ll excuse me, I have about 37 “quick fixes” that are probably going to create 38 new bugs.

P.S. One thing that’s helped me a lot is Linear. It’s been really useful for keeping track of all the bugs and features instead of trying to remember everything in my head. If you’re building software, I’d definitely recommend checking it out:

https://linear.app/

Day 6 : Pedal to the Metal

The Young Entrepreneur — Thu, 23 Jul 2026 15:31:54 GMT

A lot of people think building a startup starts with writing thousands of lines of code.

A 50,000-line codebase.
A fancy architecture diagram.
A developer who says “it depends” 37 times.

But honestly?

It starts much earlier.

It starts with opening the editor.

For my latest project, Dwell, the first step was simple:

I opened Cursor.

Then I had to answer the hardest question:

“What exactly am I building?”

Because AI is powerful, but it is not a mind reader yet.

You can’t just open Cursor and say:

“Build me the next Apple.”

I tried. The AI politely disagreed.

One thing I’ve learned from building multiple apps:

Long prompts are not always better.

Sometimes we write a giant 5-page prompt explaining every button, color, animation, and feature we might want in 2035.

The result?

The AI is sitting there thinking:

“Cool... but where do we start?”

Instead, I like to start simple.

I give Cursor:

What the product is
Who it is for
The problem it solves
The first features I need

Then we build from there.

Think of it like working with a teammate.

You wouldn’t walk up to a developer and say:

“Here is every single thing this app will ever do for the next 10 years. Good luck.”

You start with:

“Here’s the problem. Here’s version one.”

Then you iterate.

My startup building workflow:

Idea
↓
Explain the problem
↓
Build in Cursor
↓
Move into Xcode
↓
Test the app
↓
Improve based on feedback

I’ve used this process before while building apps like Endless Library, and it taught me something:

The first version does not need to be perfect.

Actually, the first version is probably going to be bad.

And that’s okay.

Because a bad app that exists can become a great app.

A perfect idea sitting in your notes app will stay exactly that:

A note.

The hardest part of building is not coding.

It’s starting.

Now for the fun part.

Here is the prompt I gave Cursor, powered by Claude 5, aka the AI intern that might accidentally make me bankrupt with API costs.

To get my prompt and more information … subscribe to the Young Entreprenuer

Day 4: Inside My Startup's Kitchen

The Young Entrepreneur — Mon, 20 Jul 2026 03:22:32 GMT

Every startup has a kitchen. It is always on fire.

It’s filled with:

Too many tabs
Random error messages
And a bunch of tools holding everything together

Here is what’s inside:

Figma

Where ideas become something people can actually see. - My Design Toolkit - https://figma.com

Cursor

My coding partner that writes code faster than I can explain what I want. https://cursor.com

GitHub

Where my code lives... and it cleans up after me https://github.com

Supabase

The place where all my app’s memories live. https://supabase.com

ChatGPT + Claude

My brainstorming partners. Don’t get me started on which one is better. (pst….Claude)…. coming ChatGPT!
https://chatgpt.com/ | https://claude.ai/

PostHog

The tool that tells me what users actually do instead of what I think they do. https://posthog.com

Vercel

Where my code goes from “works on my computer” to “let’s see what happens.” - https://vercel.com

Spaceship

Making sure my tiny corner of the internet stays alive. https://spaceship.io

Building a startup is basically cooking.

You need the right ingredients.

Sometimes the recipe works.

Sometimes you accidentally add a bug instead of salt.

Either way, the kitchen is open. Lets hope it does not go up in flames.

Tomorrow: building the first version.

To get my secret sauce … subscribe and pledge a subscription:

Subscribe now

Day 3: Turning "It'll Be Fine" Into Documentation

The Young Entrepreneur — Fri, 17 Jul 2026 19:42:51 GMT

Every popular product you’ve probably used started with something surprisingly boring.

A Product Requirements Document.

Or, if you want to sound intelligent...

A PRD.

Before a single line of code gets written, before AI starts hallucinating features you never asked for, and before your developers begin interpreting your “simple app idea” in five completely different ways...

...you need a PRD.

Think of it as the instruction manual for your product.

It answers questions like:

What problem are we solving?
Who is this for?
What features are absolutely required?
What does success look like?
What should we not build?

Without one, building a startup becomes a game of Chinese whispers.

You say:

“I want a simple warranty tracker.”

AI hears:

“Congratulations! I’ve also added social media, NFTs, a crypto wallet, an AI therapist, and a built-in weather forecast. Would you like that with a side of fries?”

Your developer thinks you want a clicker

Your designer imagines a sleep app

Three weeks later everyone has built a different product.

That’s the startup version of chaos.

A good PRD gives everyone the same map.

Whether you’re working with a team of engineers or just prompting Claude, ChatGPT, Gemini, or Cursor, the quality of what gets built is heavily influenced by the quality of the instructions.

Garbage in.

Garbage out.

Clear requirements in.

Much better product out.

I’ve been using AI to help build my startup, and one thing I’ve learned is that spending an hour writing a PRD can save days (or weeks) of rebuilding later.

It feels slower.

It’s actually much faster.

Here is a framework that I use every time :

The AI PRD Framework

Copy this prompt into your favorite AI model and replace everything in [brackets].

You are an experienced Senior Product Manager at a top technology company.

Create a comprehensive Product Requirements Document (PRD) for the following startup idea.

1. Product Overview

Product Name:
One-sentence description:
Elevator pitch:

2. Problem

Explain:

What problem exists?
Why is it painful?
Why is now the right time to solve it?

3. Target User

Describe:

Primary user
Secondary user
User demographics
User goals
Biggest frustrations

4. Goals

List:

Business goals
User goals
Success metrics (KPIs)

5. Core Features

For each feature include:

Feature name
Description
Why it matters
User benefit
Priority (Must Have / Should Have / Nice to Have)

6. User Journey

Walk through the complete user experience from first opening the app to completing the main task.

7. Screens

List every screen in the application.

For each screen include:

Purpose
Components
User actions
Navigation

8. Functional Requirements

Describe exactly how every major feature should work.

Include:

Inputs
Outputs
Edge cases
Error handling

9. Non-Functional Requirements

Cover:

Performance
Security
Privacy
Accessibility
Reliability
Scalability

10. Technical Architecture

Recommend:

Frontend
Backend
Database
Authentication
APIs
Hosting
AI services (if applicable)

Explain why each technology is recommended.

11. Database Schema

List:

Tables
Fields
Relationships

12. User Stories

Write at least 20 user stories in the format:

“As a [user], I want [goal] so that [benefit].”

13. Acceptance Criteria

For every major feature provide measurable acceptance criteria.

14. Risks

Identify:

Technical risks
Business risks
Legal risks
Operational risks

Include mitigation strategies.

15. Future Features

Suggest 20 logical features for Version 2 and beyond.

16. Monetization

Recommend:

Pricing model
Revenue streams
Customer acquisition ideas

17. Competitor Analysis

Compare against at least five competitors.

For each competitor include:

Strengths
Weaknesses
What our product does better

18. MVP

Define:

What should be included in Version 1
What should be postponed
Why

19. Timeline

Estimate development time for:

Design
Frontend
Backend
Testing
Launch

20. Open Questions

List any assumptions or decisions that still need validation before development begins.

Startup Idea:

[Describe your startup in as much detail as possible.]

Additional Context:

[Target audience, business model, constraints, budget, preferred technologies, inspiration, competitors, etc.]

The final PRD should be detailed enough that an engineering team or an AI coding agent could begin implementing the product with minimal additional clarification.

Get more startup tidbits like this by subscribing. Just saying. 😉

Subscribe now

Day 2 of Building my Startup in Public: Naming & Branding

The Young Entrepreneur — Thu, 16 Jul 2026 02:29:35 GMT

Today’s mission: turn “I should start a startup” into an actual brand.

This is going to be a short one, but a longer update will come out tomorrow.

I thought finding an idea would be the hard part.

Turns out the real challenge is finding a name that:

* Isn’t already taken as a domain.

* Is not baby gibberish.

* Doesn’t sound like a thesis.

* Still makes sense after staring at it for three hours.

After way too many ideas (and a few names that absolutely should never see the light of day), I finally landed on something I’m excited about.

Dwell

Since this is a warranty app that protects your dwelling, the name felt perfect.

And then I also made my logo, which is attached. Let me know what you guys think about it. I decided to go a bit simpler, so if can help me out, that would be great!

Dwell Logo

One step closer to launching.

Short update for today, but tomorrow I’ll share a longer one with more progress. 😅

#buildinpublic #substack #branding #startup #indiehacker

Day 1: Building Something New in Public

The Young Entrepreneur — Tue, 14 Jul 2026 21:05:29 GMT

I have a problem...

I own way too much tech.

A MacBook.
An iPhone.
An iPad.
AirPods.
A bunch of accessories.

(*Apple has really sucked me into their ecosystem , they do make great products.)

And every single time I buy something, I tell myself:

“I will make sure to register the warranty”

Spoiler alert:

I don’t. 😂

Six months later:

“Wait... when did I buy this?”
“Is it still under warranty?”
“Where is the receipt?”
“Does AppleCare cover this?”
“How much is this even worth now?”

And then begins the world’s least exciting treasure hunt:

Searching through emails.
Opening random folders.
Trying passwords from 3 years ago.

🤦‍♂️

The funny thing is...

We have incredible technology in our hands, but managing the technology we own still feels like we’re living in 2005.

So today, I’m starting to build something.

I can’t share all the details yet 👀

But the mission is simple:

Make owning technology smarter.

I’ll share the entire journey:
→ The research
→ The designs
→ The failures
→ The user feedback
→ The lessons learned

Maybe it becomes something huge.

Maybe it doesn’t.

Either way, I’m excited to build.

Lets Get Started!

If you have any suggestions of how i should go about building my first startup in public , leave a comment :

Duolingo : The world's most addictive platform

The Young Entrepreneur — Sun, 12 Jul 2026 20:08:35 GMT

I’m willing to bet you’ve heard of Duolingo.

Whether it’s the green owl staring into your soul because you missed a lesson, the absolutely crazy marketing, or your friend somehow maintaining a 1,000-day streak, you’ve probably come across it.

On the surface, Duolingo looks like just another language-learning app. But underneath the cute animations and cheerful sounds is one of the greatest examples of product design, habit formation, and gamification ever built.

So how did a simple translation app become one of the most downloaded education apps in the world? And more importantly, what can we, as builders, learn from it?

Duolingo founded in 2011 by by Carnegie Mellon University professor Luis von Ahn and his graduate student Severin Hacker. Now Luis von Ahn and “Hacker” (As I like to call him) , built Duolingo with a purpose :

To reduce global economic inequality by offering free*, high-quality language education to anyone. Originally, they funded the free service by having users translate real-world web pages and articles as they learned.

*- I don’t think the Duolingo super owl agrees with this statement (if you know , you know)

Duolingo started as a translation app and the way they have evolved is simply astonishing , this is a picture of how Duolingo started then to what it is now :

So... what’s the secret sauce? Is it the owl? Is it the green color? Is it the threatening notifications that somehow know exactly when you’re about to forget your lesson?

Kind of.

The real magic is that Duolingo is one giant masterclass in product design.

The first thing you’ll notice is frictionless onboarding. You download the app, answer a couple of questions, and you’re learning within minutes. No 37-page questionnaire asking about your favorite breakfast cereal. No account setup that feels like applying for a mortgage. They get you to your first “Aha!” moment as quickly as possible.

Then there’s micro-learning. Most lessons take about two or three minutes. That’s genius. Nobody wants to commit to an hour after a long day, but almost everyone can convince themselves to spend two minutes. And, somehow, two minutes magically becomes twenty. It’s the product equivalent of saying, “I’ll just watch one more episode.”

The feedback is also incredibly satisfying. Every correct answer is rewarded with sounds, animations, XP, and enough positive reinforcement to make you feel like you’ve just solved world peace. Get something wrong, and instead of making you feel terrible, it immediately teaches you why. That instant feedback loop keeps your brain engaged.

Now let’s talk about the feature that has probably consumed more human willpower than anything else: the streak.

As I’m writing this, I have an impeccable 101-day streak. That’s 101 consecutive days of opening the app. There have absolutely been days where I opened Duolingo at 11:58 PM because I suddenly remembered Duo was probably sharpening a baseball bat somewhere. Did I learn much in those two minutes? Maybe. Did I save my streak? Absolutely.

And that’s exactly the point.

The streak isn’t there to make you feel good. It’s there to make you come back tomorrow. Once you’ve invested 50... 75... 100 days, losing it feels painful. It’s one of the simplest habit-building mechanisms ever created, and somehow it works on millions of us.

Then there are XP, leagues, quests, achievements, and friend challenges. None of these technically teach you Spanish, French, or Japanese. What they do teach you is how surprisingly competitive you become against complete strangers on the internet over imaginary points.

One design choice I absolutely love is showing progress everywhere. Every completed lesson fills another bubble. Every day extends your streak. Every league promotion feels like a tiny victory. Humans love seeing progress, even if it’s just a number getting bigger.

And then there’s Duo himself.

Most companies have a mascot.

Duolingo has an internet celebrity.

Whether he’s celebrating your success or “gently reminding” you to do your lesson, he gives the product a personality people actually remember.

The biggest lesson for anyone building an app is this: people don’t come back because your technology is impressive. They come back because your product fits naturally into their daily routine.

If you’re building your own app, steal these ideas (ethically, of course):

Get users to their first success in under two minutes.
Break big tasks into tiny wins.
Reward progress immediately.
Make progress visible.
Give your product a personality.
Most importantly, design for tomorrow, not just today. Every feature should answer one question: “Why would someone come back?”

Duolingo isn’t just teaching languages anymore. It’s teaching founders how to build products people can’t stop opening.

It is not a language company , it is consistency insurance.

Now if you’ll excuse me, I have a 101-day streak to protect. I’m not about to let a green owl win.

Claude Fable 5 Is Back And It Reminds Me Why Great AI Feels Like Magic

The Young Entrepreneur — Sun, 12 Jul 2026 03:05:44 GMT

Every few months, an AI model comes along that makes you stop benchmarking and just start building.

For me, Claude Fable 5 is one of those models.

Its return isn’t just another version update , it’s a reminder that the best AI isn’t measured only by benchmark scores or token limits. It’s measured by how naturally it fits into your workflow and how often it surprises you with thoughtful, creative, and genuinely useful responses.

It Doesn’t Feel Like You’re Talking to Software

The first thing I noticed was how conversational everything felt.

Instead of sounding like a search engine wrapped in a chatbot, Claude Fable 5 feels like you’re brainstorming with someone who actually understands context. It remembers the thread of a conversation, expands on ideas instead of repeating them, and often suggests directions you hadn’t considered.

That difference matters.

When you’re writing, designing, coding, or planning a startup, momentum is everything. A model that keeps that momentum alive becomes more than a tool,it becomes part of your creative process.

Creativity Without Losing Precision

Many AI systems force a tradeoff.

Some are incredibly creative but hallucinate details. Others are technically accurate but produce responses that feel robotic.

Claude Fable 5 strikes an impressive balance.

It can draft articles, generate product ideas, explain difficult concepts, and help solve technical problems while keeping responses coherent and surprisingly nuanced.

That combination is what makes it enjoyable to use.

Building Becomes Faster

One of the biggest shifts AI has created isn’t replacing developers.

It’s removing friction.

Instead of spending hours staring at a blank page or debugging a tiny issue, you can iterate in minutes. Whether you’re creating a new app, refining a pitch deck, or writing documentation, Claude Fable 5 feels like an accelerator rather than an autopilot.

It still needs human judgment,but it gives you a much better starting point.

Why This Matters

The AI conversation often focuses on model rankings.

Which one is #1?

Which benchmark increased by 3%?

Those discussions are interesting, but they miss what most people actually care about.

People remember how a tool makes them feel.

Does it help you think better?

Does it make work more enjoyable?

Does it save you time without getting in your way?

Claude Fable 5 checks those boxes.

The Bigger Picture

We’re entering an era where AI isn’t just answering questions,it’s becoming a creative partner.

The best models won’t necessarily be the ones with the highest scores on leaderboards.

They’ll be the ones people instinctively open first because they trust them.

If Claude Fable 5 continues evolving in this direction, it’s going to earn that place for a lot of builders, writers, students, and entrepreneurs.

And that’s far more interesting than another benchmark chart.

What is Claude Fable?

The Young Entrepreneur — Sun, 14 Jun 2026 16:34:12 GMT

you might have heard about claude fable recently. but what actually is it?

fable 5 is basically the watered-down public version of claude mythos 5 - an anthropic model rumored to be so powerful it could practically break out of a computer. mythos was never meant to leave the lab, so anthropic built fable as a safer, gated-down version for the public

how fast is it?

it is built for raw speed, letting you "one-shot" entire applications that used to take hours of back-and-forth prompting. it also broke the 90% threshold on core analytics benchmarks for complex, long-running tasks

what can it do?

- advanced software engineering and automated coding

- heavy data analysis and mathematical modeling

- high-fidelity motion design and fast prototyping

the catch?

just today, it was revoked from public access. the official story is that the government flagged undisclosed security vulnerabilities, but tech analysts are betting it has more to do with the escalating tension between anthropic and the us government

Day 1: How to Actually Start a Startup from Scratch

The Young Entrepreneur — Sat, 13 Jun 2026 17:40:28 GMT

What’s up, everyone! Rishan here.

We’ve all been there. You have a million-dollar idea scribbled on a napkin, but when you sit down at your desk, the screen is blank. The mountain looks too high to climb, and you have no idea where to put your foot first.

Today is Day 1. I’m taking you along as I build my next venture from the absolute ground up. No fluff, no "I already had a team of ten," just me, a laptop, and a lot of caffeine. Here is exactly how to start when you have nothing but an idea.

1. The Identity: Naming and Claiming
A startup needs a soul, and that starts with a name. I spent the morning brainstorming names that felt fast and modern. Once I landed on the winner, I headed straight to Spaceship (https://www.spaceship.com/). Why? Because it’s sleek, fast, and doesn’t feel like a relic from 1995. I grabbed the .com, set up the DNS, and suddenly, this thing became real. Pro tip: Don't overthink the name for weeks pick something punchy and move.

2. The Validation: Finding PMF on Day 1
Product-Market Fit (PMF) isn't just a destination; it's a discipline that starts the second you have an idea. Before I wrote a single line of code, I focused on validating the "problem." This means talking to potential users not just your friends who will tell you it's a great idea, but the people who feel the pain point every day. I'm using a simple framework: start with a core metric you want to move (reach, retention, or revenue) and build only what is necessary to test that hypothesis. If you can't articulate how a feature moves that needle, don't build it.

3. The Blueprint: Stitching Wireframes
Once the core idea is validated, it's time to visualize. I spent the afternoon "stitching" together wireframes. This isn't about high-fidelity design yet; it's about mapping out the user flow and ensuring the "deliverables" (like the user journey from landing to the core feature) make sense. I'm focusing on Stitch (https://stitch.withgoogle.com/) as my mental model for connecting these mockups into a functional narrative. It allows me to see the gaps in the product before the engine is even built.

4. The Brain: Getting Organized with Notion
Chaos is the silent killer of early-stage startups. Before I wrote a single line of code, I opened Notion (https://www.notion.so/). I built out a "Command Center" workspace (check out this template: (https://www.notion.com/templates/founder-os-the-all-in-one-startup-operating-system): a roadmap for features, a CRM for early testers, and a scratchpad for late-night brainstorms. If it isn’t in Notion, it doesn’t exist. Getting organized on Day 1 is the difference between a side project and a real company.

5. The Engine: Choosing the Stack
Now for the fun part. I’m a big believer in moving fast, which means not reinventing the wheel. For backend and auth, I’m leaning into tools like Stytch (https://stytch.com/). It handles the heavy lifting of security and user management so I can focus on building the features people actually care about. The goal is to spend 90% of my time on the product and 10% on the infrastructure.

The Journey Begins
Day 1 is officially in the books. It’s messy, it’s exciting, and it’s finally happening. I’m going to be documenting every single step of this build the wins, the bugs, and the pivots.

If you’re an ambitious young founder or just curious about how things actually get built, hit that subscribe button below. You won't want to miss Day 2.

Let’s go build something great.

Rishan

Note: Google Stitch is an AI-native design platform that allows users to generate high-fidelity UI designs and frontend code from text prompts or sketches, streamlining the wireframing and prototyping process.