📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
The single best thing ever written on customer conversations. It teaches you to ask about the customer's life and past behaviour, not your idea, so you can't be lied to. If a founder reads one thing before talking to a single customer, it's this.
From
momtestbook.com
by Rob Fitzpatrick
~130 pages
- Talk about their life, not your idea.
- Ask about specifics in the past, not opinions about the future.
- 'That's so cool, I'd totally buy it' is a compliment, not data, dig for commitment and evidence.
Open
momtestbook.com →
📖 Book
✓ Link checked
Free
Beginner
Why we picked it
Free to read online, with chapters like "Build Less" and "Half, Not Half-Assed" that name your exact trap. It argues that cutting scope is a feature, and that the version with fewer things done well beats the bloated one. A fast, opinionated read you can skim straight to the chapters that sting.
From
Basecamp / 37signals
by Jason Fried, David Heinemeier Hansson (37signals)
Free online, ~4 hr
- Build half a product, not a half-built product.
- Every feature you add is one more thing to maintain and explain.
- Deliberately underdo the competition on scope.
Open
basecamp.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
If you read one chapter, this is the core argument: doing less is a feature, not a compromise. It helps you strip your MVP down to the one thing worth testing, which is usually deliverable on the mobile web today. Concrete and quick.
From
Basecamp (37signals)
by Jason Fried, David Heinemeier Hansson
- Fewer features means faster learning
- Cut anything not core to the first test
- Less software is easier to change later
Open
basecamp.com →
📄 Article
✓ Link checked
India
Free
Intermediate
Why we picked it
Flipkart serves exactly your users, many on 2G in smaller Indian cities, and this case study shows a fast mobile web app tripling time on site versus their old mobile experience. It is proof that a light web page can win in low bandwidth conditions where a heavy native app struggles. Useful data to counter the reflex that real products need an app.
From
web.dev (Google)
- 63% of users arrived over 2G, so speed mattered most
- The fast web app tripled time on site
- Add to home screen gave app like access with no install
Open
web.dev →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Twitter Lite is roughly 600KB over the wire versus a 23.5MB native install, and it grew engagement in emerging markets on flaky networks. For users on cheap phones with little storage, this is the clearest example of why smaller and web based often wins. It also shows a data saver approach worth copying.
From
web.dev (Google)
- The web version was a tiny fraction of the native app size
- It loaded in under five seconds on 3G
- Lower data use lifted engagement in emerging markets
Open
web.dev →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
A concise checklist for making a web app feel native: cross browser, offline capable, responsive, and fast. Use it to judge whether the web can meet your product's real requirements before you commit to native. A good gut check against over building.
From
web.dev (Google)
- Responsiveness and speed matter more than platform
- Offline support is achievable on the web
- Test the web option against real needs before going native
Open
web.dev →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
The neutral, vendor free reference on what a PWA is and can do, from the people who document the web. It helps you separate marketing claims from what the web genuinely supports on Android today. A trustworthy baseline before you decide.
From
MDN Web Docs (Mozilla)
- A PWA installs and runs from one web codebase
- Android support for these features is strong
- Vendor neutral docs to check vendor claims against
Open
developer.mozilla.org →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
The concrete how to for giving your web app a home screen icon without the app store, which removes most of the install friction that keeps first time users away. For phones in smaller cities where storage is tight, this is the practical middle path. Short and specific.
From
MDN Web Docs (Mozilla)
- Add to home screen skips the app store entirely
- A web app manifest is most of the work
- Users get an icon without a heavy download
Open
developer.mozilla.org →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
This is Google's own field research on building for people coming online in markets like India, and it names the exact constraints you are up against: a 40 to 60 dollar phone with 512MB of RAM, a network that flips between 3G, 2G and nothing, and 250MB of prepaid data for the whole month. It is the clearest single primer on why a metro-built app breaks for a first-time user, and it stays concrete instead of preaching. Read it as a starting point for how you scope features, not as a checklist to blindly copy.
From
Google Design
by Google Design (Next Billion Users team)
~12 min read
- Assume slow or intermittent connectivity as the default state, not the exception: design offline-first and let the app degrade gracefully when the network drops.
- Data is expensive and rationed, so every megabyte you ship (heavy images, autoplay, background sync) is a real cost the user notices.
- Many users are new to touchscreens and English, so patterns you take for granted (swipe, hamburger menus, English CTAs) need rethinking for people building outside the big startup hubs.
Open
design.google →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
Hard numbers on how much users resent being forced to install an app for something a web page could do. It quantifies the install friction that hits first time and one time users hardest, which is most of your early audience. A useful reality check against defaulting to native.
From
Forbes
by John Koetsier
- Most people resent forced app installs
- Many abandon transactions rather than download an app
- One time and first time users especially prefer the web
Open
forbes.com →
Why we picked it
The permission slip to recruit users by hand, do things manually, and deliver 'insanely great' experiences to your first few customers. The cheapest, most honest way to validate demand is to go get it one person at a time.
From
paulgraham.com
by Paul Graham
~15 min read
- Recruit your first users manually, don't wait for them to come.
- A tiny group of users who love you beats a big group who like you.
- Manual, unscalable effort early is a feature, not a failure.
Open
paulgraham.com →
📄 Article
India
Free
Advanced
Why we picked it
A first hand engineering account of why Flipkart, an app first Indian company, rebuilt the mobile web to reach users on weak networks and low end phones. It is candid about the constraints your users live with and the tradeoffs the team made. Read it when you want the practitioner view, not the case study gloss.
From
Medium (Progressive Web Apps)
by Aditya Punjani
- An app first Indian company chose to reinvest in the web
- Low end phones and weak networks drove the decision
- Real tradeoffs from a team serving your exact users
Open
medium.com →
Why we picked it
The book that gave the world 'MVP', 'build-measure-learn', and 'validated learning'. It reframes a startup as a series of experiments, not a bet, the mental model everything else in this category builds on.
From
theleanstartup.com
by Eric Ries
~330 pages
- Progress = validated learning, not features shipped.
- Build the minimum that produces a real learning loop.
- Decide pivot-or-persevere on evidence, on a schedule.
Open
theleanstartup.com →
