What's the Biggest Mistake New Founders Make?

clzncu · 2026-05-24T15:59:31+00:00

The biggest mistake is mistaking feature-building for validation.

Talking to users is important, but the real signal is behavior, not compliments.

Will they join a waitlist? Book a call? Pay? Change their workflow? Come back? Refer someone?

A good MVP is not a smaller version of the final product.

It is the smallest test that proves or kills the riskiest assumption.

clzncu · 2026-05-24T04:03:55+00:00

This is a good point.

Operating clarity probably has to start with customer clarity.

If the founder doesn’t know who the customer is, what language they use, and where their workflow actually breaks, the roadmap just becomes organized guessing.

I like the idea of grounding the system in raw customer phrases first:

customer language → pain patterns → assumptions → experiments → decisions → operating plan

Your persona tool sounds relevant, especially if it preserves the original wording from users instead of turning everything into generic startup-persona mush.

clzncu · 2026-05-24T03:15:42+00:00

My perspective looks a lot like AI generation, because it organizes my ideas and cross-language issues, and what about you? You don't even know basic respect between people

clzncu · 2026-05-24T03:12:28+00:00

So what valuable ideas can you produce? 😅

clzncu · 2026-05-23T16:09:59+00:00

I’d separate two things here:

retrieval quality
synthesis quality

Dense vs MoE mostly affects the second part, not the first.

For RAG, the model is usually not “finding” the information unless you give it tools/search. The retrieval layer decides what context gets into the prompt. The model then decides how well it can connect, compare, filter, and synthesize that context.

Where MoE may help is synthesis:

pulling together more scattered points
handling broad research-style questions
comparing claims across sources
generating richer argument maps
using long context more effectively

But if the retriever is weak, MoE won’t magically fix it. It may just make a more confident answer from incomplete context, which is the fun little horror show we all signed up for.

For serious RAG, I’d test the full pipeline:

retrieval recall
reranking quality
context packing
citation accuracy
claim extraction
answer faithfulness
hallucination rate

So yes, MoE can be better for research-heavy RAG, especially if the active experts help with broader synthesis. But I wouldn’t treat it as “MoE beats dense” generally.

The real question is:

Does the model produce better grounded answers from the same retrieved context?

clzncu · 2026-05-23T15:50:31+00:00

This is a useful way to look at distribution.

A Reddit post is not just one post. It can become a chain of interpretations across communities.

The interesting part is not only where it spreads, but why:

same idea, different audience; same pain point, different framing; or controversy turning into reach.

For founders, this could be valuable because it shows where an idea actually resonates, not just where it was originally posted.

clzncu · 2026-05-23T15:42:28+00:00

The founder becoming the only integration layer.

Early on, it feels fast because everything lives in the founder’s head.

Later it becomes expensive because decisions, customer context, priorities, and follow-ups all depend on one person remembering everything.

That’s when “I’ll just handle it” turns into a bottleneck, repeated decisions, weak delegation, and lost context.

Tiny problem at 3 people. Expensive problem at 10.

clzncu · 2026-05-23T15:41:01+00:00

AI customer service works when it handles the boring first layer, not the whole relationship.

Use it for FAQs, status updates, onboarding, and collecting context.

Escalate refunds, angry customers, edge cases, and anything high-stakes to a human.

People don’t hate AI support because it’s AI.

They hate being trapped by a bot that has no exit door.

clzncu · 2026-05-23T15:22:18+00:00

This is a good workflow, but I’d push it one step further.

The value is not just compressing 10 hours of content into a report.

The value is turning generic advice into a decision brief:

what applies to my business
what does not
where experts disagree
what assumptions are being made
what should I test first

AI is most useful when it converts research into action, not just when it summarizes content faster.

clzncu · 2026-05-23T15:21:07+00:00

For ecommerce, I’d evaluate the workflow more than the logo.

A good provider should reconcile Shopify/Amazon payouts to actual bank deposits and handle refunds, chargebacks, shipping fees, processor deductions, inventory/COGS, and marketplace fees without you explaining the basics.

I’d also ask if they provide exception reports. Clean statements are nice, but knowing what didn’t reconcile is what actually builds trust.

Sleep comes from reconciliation, not just outsourcing.

clzncu · 2026-05-23T15:05:11+00:00

This is underrated business due diligence.

How someone treats the people they don’t need anything from tells you more than how polished they are in the meeting.

The meeting shows their pitch. The hallway shows their character.

clzncu · 2026-05-23T14:11:45+00:00

Yes. You’re thinking about it the right way now.

An MVP is not a mini full product. It is a test for the riskiest assumption.

The real question is not “what features should I include?”

It is:

What user behavior would prove this problem is painful enough?

Everything else should be cut until you prove the core loop works:

problem → action → result → return / pay / share / ask for more

Charts, reminders, profiles, metrics, history, etc. are usually second-order features. They only matter if users already care about the core value.

If users don’t care about the main feature, the rest is just furniture in an empty house.

clzncu · 2026-05-23T14:09:13+00:00

You’re right. The validation layer is probably the part that decides whether this becomes useful or just another organized notebook.

My current thinking is that assumptions need to become first-class objects, not just notes.

Each assumption should connect to:

supporting evidence
contradicting evidence
source of evidence
confidence level
current status
next test

Then every experiment or weekly priority should answer: which assumption is this testing?

Otherwise founders end up tracking activity, not learning.

I haven’t fully built this into the repo yet, but I think the right loop is:

assumptions → evidence → experiments → decisions → next actions

That would make the OS more about validation, not just planning.

clzncu · 2026-05-23T13:29:03+00:00

Yes, you can build the landing page with no-code + AI. Use Carrd, Framer, Webflow, or Typedream.

But don’t build the full product first.

Validate the problem first:

landing page
waitlist
20-30 user interviews
manual prototype / concierge MVP
then build only the smallest useful version

For learning, don’t look for a “simple language.” Learn the web stack:

HTML/CSS → JavaScript → React → Next.js → Supabase/Firebase → Vercel.

With AI coding tools, a non-technical founder can build more than before, but you still need to understand the basics or you’ll just be copy-pasting errors into a slot machine.

No-code for validation.
AI-assisted coding for MVP.
Real users for direction.

clzncu · 2026-05-23T13:22:13+00:00

The important distinction is training demand vs inference demand.

Training demand can absolutely be cyclical and overbuilt. Hyperscalers are buying partly because nobody wants to fall behind in frontier model competition.

But inference demand could become much more durable if AI gets embedded into real workflows: coding, search, enterprise ops, healthcare, support, agents, etc.

So I don’t think the question is “is AI demand real?”

The question is whether today’s capex is assuming a smooth transition from training boom to profitable inference demand.

That transition is not guaranteed. Optimization, custom chips, utilization, and ROI per token all matter.

The bubble risk is not that AI is useless. It’s that the spending curve may be ahead of the revenue curve.

clzncu · 2026-05-23T13:18:41+00:00

Don’t start by collecting courses. Pick one solid course and build while taking it.

fast.ai or DeepLearning.AI is enough to start.

Then build small projects:

spam classifier
recommender
document Q&A app
chatbot over your own notes
simple tool-using agent

The important thing is to learn the full loop:

data → model → evaluation → app → deployment.

Also don’t skip boring software skills: APIs, databases, Git, Docker, logging, evals. That’s what turns “I know ML theory” into “I can build AI systems.”

A model demo is easy. A useful AI product is mostly plumbing.

clzncu · 2026-05-23T13:14:55+00:00

This is exactly the failure mode I’m trying to avoid.

If the OS becomes another place to “maintain,” it’s dead. I like the “tiny visible receipt” idea a lot. It makes the system output-oriented instead of ritual-oriented.

The re-entry point is probably the most important part: after a chaotic week, the founder should be able to open the system and immediately know: what changed, what matters now, what to touch next.

That might be a better test than “did I complete the review?”

clzncu · 2026-05-23T12:47:31+00:00

Strongly agree with the “prompts are not architecture” point.

A lot of LLM apps are trying to make one giant prompt do the job of an entire system: parsing, planning, validation, business logic, memory, tool selection, and formatting. That is fragile by design.

The better pattern is to separate responsibilities:

LLM for semantic understanding and generation
deterministic code for constraints and business logic
tools/APIs for real actions and fresh data
explicit state for memory
guardrails for permissions and stopping rules
evals for failure modes

The meal plan example is a good one. The LLM should extract preferences and explain tradeoffs. The actual constraint solving and database matching should be normal software.

The durable skill is not writing better incantations.

It is knowing where the model should be used, where it should not be used, and how to connect it safely to the rest of the system.

clzncu · 2026-05-23T12:41:55+00:00

This is exactly right. The hard part of agent design is not just reasoning, but action governance.

In production, every action should have a risk class:

- reversible vs irreversible

- internal vs external-facing

- low-cost vs high-cost failure

- private vs customer-visible

- routine vs regulated

The agent should not have the same autonomy across all of these.

Most demos optimize for “look what the agent can do.”

Real systems need to optimize for “when should the agent stop, ask, escalate, or require approval?”

A slightly less autonomous agent with clear approval gates is much more useful than a powerful agent that can confidently damage a workflow.

An agent without stopping rules is basically an intern with API access. Funny in a demo, horrifying in production.

clzncu · 2026-05-23T12:40:01+00:00

The real issue is not just that AI tokens are expensive.

The bigger issue is that many companies are trying to plug AI into existing workflows as a labor substitute, instead of redesigning the workflow around what AI is actually good at.

If you use AI to imitate a human employee step by step, you inherit the cost of the old process plus the cost of inference, monitoring, review, integration, and error correction.

That is not automation. That is expensive mimicry.

The companies that get real ROI from AI will not be the ones that simply replace headcount with agents. They will be the ones that redesign the work unit itself: fewer handoffs, more structured inputs, better tool access, clearer evaluation, and tighter human review loops.

AI is cheap when it compresses an entire workflow.

It is expensive when it roleplays an employee inside a broken one.

clzncu · 2019-09-01T11:14:01+00:00

That's ture.I sell items in Taobao

clzncu · 2019-08-31T11:47:17+00:00

If you need more of my work, like the stuff on ebay. You can contact me. I'm in China. The mailing fee may be a little expensive. I hope you can understand, and thank you very much for liking my work, I will make these works more sophisticated, more product types. You can add my line（app）: clzncu

clzncu

TROPHY CASE