06. Checklist Before Deciding "What To Build?"

So far, you'd have guessed that I'm trying to build something in the education market. Even after enough research, I couldn't converge on a niche; instead I accumulated a fog of plausible options. So instead of asking what should I build? directly, I’m taking a step back. I want to first define the constraints I refuse to violate, the outcomes I actually care about, the advantages I already have (whether earned or accidental), and a set of guiding principles that will quietly shape decisions later.

The Constraints

Before starting anything, these are the constraints upon me that I can't break.

~₹60k capital $\rightarrow$ mostly going into compliance/company setup
Asset-light, tech-first (minimal physical infra)
Only ~2–3 hrs/day + weekends $\rightarrow$ part-time build
Launch needed within ~15 days

These imply hyper-focused execution $\rightarrow$ cut all the noise, and build only the things that will break the whole system if absent.

Implications

Avoid anything that requires continuous manual servicing early. No need for content creation first, just curate the existing content. Ops need to be really simple. Use AI as much as possible for management tasks.
Collect testimonials. Proof-of-work matters more than marketing claims. Transparency becomes a competitive advantage!
In edtech, distribution often beats product. Focus more on distribution than product!
Avoid claims that can't be operationally guaranteed. Need to come up with T&C document before taking money to manage legal sensitivity.
Design something that becomes lighter over time. Not heavier.

The Expected Outcomes

Constraints define what I can’t do. Outcomes define what would make this worth doing at all. This isn’t a hobby project, and it isn’t purely an intellectual exercise either. The goal is simple: this side venture should generate at least ₹1 lakh per month in reasonably short order, and then grow from there. Longevity matters, but not in the romantic “build for decades no matter what” sense; but more in the practical sense of building something that compounds revenue over time without proportionally increasing effort. In other words, durability with cash flow.

At the same time, I’m deliberately optimizing for revenue density. Every feature, decision, or expansion should be evaluated partly on whether it increases earning potential without breaking the constraints already defined. This means preferring monetizable niches, faster feedback loops, and offerings that people demonstrably pay for rather than those they merely say they want. Sustainability here doesn’t mean slow growth; it means consistent, constraint-aware growth.

Implications

Early monetization is essential; validation comes from revenue, not signups or praise.
Focus on high-value outcomes for users (jobs, career advancement, concrete skill gains) because those justify pricing power.
Favor repeatable or scalable revenue streams over one-off transactions wherever possible.
Track effort-to-revenue ratio carefully; if effort grows faster than revenue, the model needs redesign.
Keep optionality open. The project should create assets (audience, credibility, data, processes) that can compound into future opportunities even if the initial product evolves.

The Advantages

In my case, the biggest advantage is not a particular skill, but proximity: I’ve spent the last few years inside the job-oriented edtech ecosystem itself: teaching, observing companies scale, and watching some collapse under predictable pressures. That exposure makes certain traps very visible to me now, especially the CAC treadmill where growth becomes indistinguishable from aggressive sales hiring and increasingly fragile promises. I want scale, but not that version of it.

Another advantage is versatility. I’m not the world’s best specialist in any single technical domain, but I’m unusually comfortable across many: web development, AI/ML, software systems, DevOps, analytics, even some finance thinking. This reduces coordination costs dramatically. Ideas can move from concept to prototype without waiting on multiple specialists. Combined with formal training in statistics and data science, this also adds analytical credibility, which I hope matters in an education product aimed at employability.

Then there’s marketing literacy. Performance marketing knowledge doesn’t guarantee distribution, but it prevents naive mistakes. It creates awareness of CAC early, encourages experimentation with channels, and helps avoid overreliance on a single acquisition engine. In edtech especially, distribution competence often separates viable startups from technically superior but invisible ones.

Finally, there’s what might be called earned skepticism. Having seen mis-selling, inflated placement claims, and unsustainable scaling models firsthand, I have a clearer sense of what I don’t want to build. Avoiding obvious failure modes is itself an advantage.

Implications

Prioritize scalable trust over aggressive sales. Credibility compounds faster than CAC efficiency.
Build tech-enabled leverage early since cross-domain skills reduce dependency on large teams. AI-based full stack management: optimize for revenue-per-employee.
Use data thinking in decision-making.
Design distribution deliberately rather than assuming product quality alone will drive adoption.
Treat past industry failures as guardrails, not just anecdotes.

The Guiding Principles

1. Start as a Service, Not a Platform.

Paul Graham has repeatedly said: Do things that don’t scale. So instead of building LMS platform, AI learning app, or course marketplace, I'd likely start with a high-value cohort course, live tutoring and mentorship. This ensures there is zero engineering delay, immediate pricing feedback and real user interaction.

Most edtech founders hide behind product-building. PG-inspired founders would talk to users on Day 1.

2. Pick a Pain Linked Directly to Money or Status.

Most edtech startups begin with: “Education needs transformation.” That's too abstract. Successful ones begin with: “Students struggle to learn X.”, “Teachers waste time doing Y.”, or “Parents are anxious about Z.” Concrete pain beats grand mission.

For ramen profitability fast, the learning must affect: jobs, promotions, exams, business revenue, or research output. Strong examples today:

Exam-specific, high-stakes certifications with real gatekeeping (e.g., UPSC Civil Services, CA Final). These have brutal failure rates (sub-10%), take 18+ months to prepare, and directly determine life trajectories. Unlike coding interviews (where you can prep in 3 months), these require sustained structured guidance. A ₹50–100k cohort-based program with proven placement/success rates can charge heavily because stakes are high and alternatives (coaching centers) are already expensive. The pain is urgency + desperation, not just learning.
Niche B2B skill gaps in emerging tools (e.g., "Using Cursor AI for full-stack devs," "LinkedIn Sales Navigator for B2B founders," "Prompt engineering for content agencies"). Companies that sell these tools have paying customers who need to unlock ROI fast. A 4-week intensive for agency owners on "how to use AI to 10x copywriting output" can easily command ₹30–50k because it directly affects their revenue. The pain is competitive disadvantage, not self-improvement. You're selling against urgency ("my competitor is already doing this"), not motivation.
Financial outcomes with measurable ROI (e.g., "Freelance pricing strategy for developers," "Negotiation tactics for SaaS account execs"). Someone who learns to negotiate a 10% higher salary or raise rates from $50/hr to $75/hr has immediate, measurable returns. A ₹15k course that promises "earn ₹2–5L more this year" sells itself. The pain is quantifiable loss, not abstract skill gap. Example: "Freelance rate-setting for Indian web developers in global markets": very specific and very monetizable.
Solving operational bottlenecks for solopreneurs/small teams (e.g., "Building AI tools to automate your agency's delivery," "Systems thinking for 2–5 person startups"). A solo consultant or 3-person agency with ₹50L ARR is bleeding time on repetitive work. A ₹25k program that teaches them to build simple automation can reduce their workload by 20 hours/week, directly improving profitability and scalability. The pain is operational burnout, not ambition. They'll pay because it solves a problem right now.
Credential stacking in emerging fields (e.g., "GenAI certification for product managers," "Data strategy for non-technical founders"). Companies investing in AI hiring want employees or founders who understand AI deeply enough to make decisions, not just use tools. A ₹30–50k cohort that produces people who can speak credibly about AI strategy in board meetings has real market value. The pain is credibility gap at high leverage points.
Language/communication for high-value transactions (e.g., "Technical communication for research scientists pitching to VCs," "Executive presence for immigrant engineers in US companies"). A researcher who can write a compelling grant application might unlock ₹50L in funding. An engineer who can present clearly to executives moves faster. These are leverage points, not generic communication skills. The pain is missed opportunities, quantified.

People pay quickly when outcomes are economic.

3. Sell Before Building.

This is what PG would do: (a) Write a sharp landing page (b) Offer a specific promise (c) Start conversations manually, and (d) Close first customers personally.

Then refine based on who bites. No heavy curriculum upfront. Obsess over outcomes, not content. Content is easy now: AI generates explanations, videos are everywhere, and notes are commoditized. What isn't commoditized are completion rates, learning retention, career impact and confidence gained by the learner. If you can reliably produce outcomes, you win. If you only produce content, you compete with free.

4. Charge More Than Feels Comfortable.

To hit ramen profitability in ~2 months: price high, serve a few customers, and deliver intense value! Underpricing signals low value and overpricing without roof kills adoption. We prefer high signal customers with high intent > high volume.

5. Build Audience While Selling (Not Before)

Typical edtech mistake: Build audience $\rightarrow$ monetize later. We have to sell first, teach publicly alongside, and let teaching generate audience organically. Essays, short tutorials, insightful twitter/LinkedIn posts, case studies from real students, etc., will help us scale. Authority compounds quickly.

6. Focus Narrower Than Feels Rational

Probably something like: "AI for dermatology clinic owners” or "Coding cohort for ML engineers". Specificity reduces marketing cost. Broad education markets are slow. Win a niche market completely, and then repeat the same cycle in each niche that we enter!

7. Optimize for Retention Immediately (and Experience)

Because repeat cohorts reduce CAC, referrals kick in fast, and testimonials compound. Some classical retention strategies are: personal feedback loops, small communities, accountability structures, and tangible progress milestones. In education, retention is marketing.

Learning products fail when they require motivation every time. Winning products build routines, create streaks or progress loops, and provide small frequent wins. Habit beats brilliance. Students rarely finish the “best course.” They finish the one they return to.

8. Ignore Fancy Tech Initially.

PG wouldn't recommend to build adaptive learning engines, custom LMS, or AI tutor infrastructure. They are all commoditized today! Instead, Zoom + Notion + WhatsApp + Stripe works fine. Productization comes after revenue, pattern recognition, and proven demand. Real moats are: pedagogy design, community effects, institutional relationships, data on learning behavior, and brand trust. Tech helps; it rarely wins alone.

However, there is an exception here: If your core value prop depends on automation (e.g., AI-powered feedback, personalized learning paths), skipping tech might hurt unit economics faster than you think.

9. Choose a Market Where Trust Transfers Fast

PG would favor founders, engineers, academics, professionals, etc., because they value expertise, word spreads quickly in the community, and they pay faster. K12 edtech, by contrast, has slower trust cycles.

10. Stay Close to Users Longer Than Feels Efficient

Paul Graham often emphasizes founders talking directly to users. In edtech, founder should watch students struggle live, sit in classrooms and answer support tickets himself. This prevents abstraction creep. Many edtech failures happen when founders become too “platform-level” too early.

Now that we have the checklist of the constraints, the expected outcomes, the advantages, and the guiding principles, we are good to finally decide What To Build?!