How to start a startup in 48 hours

Pick problems worth hacking on

Most projects fail because they picked a bad problem. A bad problem is one that feels impressive, sounds “AI-native,” and still doesn’t matter to anyone.

You don’t find good problems by thinking harder. You find them by shutting up and letting other people talk about their day. Start by asking people about their work, not their ideas. What they did yesterday. What annoyed them. What they had to double-check. Where they felt slow, stupid, or blocked. People are very bad at articulating “problems,” but very good at describing friction if you let them stay concrete.

Don’t start with a solution. The moment you say “what if there was a tool that…,” you contaminate the signal. People will try to be helpful. They’ll nod. They’ll say “yeah, maybe.” That’s politeness, not demand. Instead, keep pulling on why things are the way they are.

• “Why do you do it this way?”
• “What happens if you don’t?”
• “Who notices when this breaks?”
• “How often does this come up?”

Listen for repetition. The same workaround mentioned twice. The same spreadsheet referenced casually. The same “we just manually…” said like it’s normal. Those are gold.

If you already have something built, never ask “would you use this?” That question is useless. People don’t know, and even if they did, they won’t tell you the truth. Ask the inverse:

• “Why wouldn’t you use this?”
• “What would make this annoying?”
• “What part feels risky or untrustworthy?”
• “What would stop this from being your default?”

The objections are the product. If they say “I’d still need to check it manually,” that’s not rejection - that’s the real problem. If they say “this breaks our current flow,” that’s distribution friction. If they say “my boss wouldn’t approve,” that’s your buyer mismatch.

Pay attention to energy, not words. When people lean forward, rant a little, or go off-script—that’s signal. When they get abstract or start future-casting (“in an ideal world…”), you’ve lost it. Pull them back to reality.

Also: don’t over-sample founders. Founders are edge cases. Talk to operators, admins, analysts, interns - the people closest to the mess. They have the least power and the clearest view of what’s broken.

Don’t overvalue the opinion of an investor or VC. Just because they’ve seen tons of companies doesn’t mean they necessarily know what the best option for you is. If you’ve done research into your problem space, most of the time you are the expert, not them. Take their opinions into account, but your customers are your source of truth.

Finally, synthesize brutally. After 5–10 conversations, you should be able to finish people’s sentences. If every call feels “interesting but different,” you’re not there yet. Real problems collapse into the same shape from multiple angles.

You’re not hunting ideas. You’re compressing reality until one small, uncomfortable truth falls out. That’s the thing worth hacking on.

Start From a Niche, Not a Market

Don’t start by trying to serve a big market. That instinct is what produces nonsense like “AI for healthcare.” Big markets are abstractions. Real problems live inside small roles.

Start with one specific customer, doing one specific job, in one specific context. Clinic admin. Accounting junior. Ops manager at a logistics SME. The narrower the role, the clearer the pain.

This is exactly how your calls narrow: you don’t stop at “healthcare” or even “clinics.” You keep drilling until it’s who, doing what, at what time, with what tools, under what constraints. That’s when the problem snaps into focus.

A good problem sentence names the niche explicitly:

• not “doctors,” but “clinic admins”
• not “data entry,” but “re-keying lab results”
• not “sometimes,” but “every night”
• not “systems,” but “Excel”

You don’t need a huge market on day one. You need one customer who would be annoyed if this didn’t exist.

This also keeps you honest about solutions. When the niche is clear, fake ideas die quickly. If you say “AI-powered automation for clinics,” it sounds impressive. If you say “clinic admins manually copy PDFs into Excel because the lab system doesn’t integrate,” now you’re forced to deal with reality: formats, trust, accuracy, approvals.

That’s the real test. If removing the word “AI” makes the problem collapse, you were never solving anything — you were decorating it. Real problems survive without buzzwords. They existed before you showed up, and they’ll still exist if you don’t build.

In calls, this shows up when people stop theorizing and start narrating. They talk about their spreadsheet, theirworkaround, their Friday night. When that happens, you’re no longer guessing the niche — you’ve found it.

Solve one sharp problem for one sharply-defined customer. Expansion is a later concern. Precision is the only thing that matters early.

Optimize for Speed and Experimentation

Your goal isn’t to build the full system. It’s to solve the core problem once, end-to-end, as fast as possible. That means optimizing for speed and learning, not cost control or feature completeness.

In practice, this usually looks like:

• one real user flow,
• one real input,
• one real output that clearly saves time, money, or mental effort.

Everything else is optional. Auth screens, logins, dashboards, are all comfort blankets. Teams reach for them because they feel “real,” not because they create value. Ignore them unless they are absolutely required to make the solution believable.

Cost also doesn’t matter yet. You’re allowed to be inefficient. You’re allowed to hardcode. You’re allowed to burn credits. Optimize for speed and functionality - don’t try to reinvent the wheel or rebuild something if it already exists. Call APIs, build wrappers if they make sense - the only thing you’re testing is if this actually removes the pain you identified.

This is why some problems are bad hackathon material. If the core value only appears when accuracy is perfect, when every edge case is handled, or when enterprise approval is secured, you won’t learn anything in 48 hours. You’ll just simulate progress.

Good hack problems degrade gracefully. Even half-working, they’re still useful. Even janky, the value is obvious. A user can look at it and say, “If this got a bit better, I’d use it.”

Solve the problem first. Make it ugly. Make it fast. Make it undeniable. You can make it cheap, secure, and complete later.

Go for the Goal, Not the Vision

Big visions blur thinking. “Fix healthcare.” “Fix hiring.” “Fix education.” These sound noble, but they hide the real question: what actually causes the problem you care about?

Target root causes, not symptoms. Diabetes isn’t solved by increasingly fancy AI prediction models. It’s solved by structural interventions like a sugar tax. The leverage point isn’t better prediction, it’s behavior and incentives.

The same logic applies to most startup ideas people bring to hackathons.

Take hiring. A common instinct is to build a hiring platform because students can’t get jobs. That assumes the problem is discovery: companies and candidates can’t find each other. But that’s just one hypothesis.

• What if it’s a talent problem — the skills don’t match what companies need? Then the right intervention is education, not a marketplace.
• What if it’s a risk problem — companies have been burned by bad hires? Then the real lever is de-risking: trials, guarantees, or mechanisms like pro-rated EWAs.
• What if it’s a trust problem, a budget problem, or a timing problem?

Good hacks don’t start with a product vision. They start with a goal (“more students get hired”) and then aggressively question the assumed solution. Often the highest-leverage move is second-order and unintuitive.

This is why over-moralizing is dangerous. When you fall in love with the vision, you stop interrogating causality. When you focus on the goal, you’re free to pick whatever intervention actually works — even if it’s boring, uncomfortable, or politically messy.

Surface leverage first. World-changing narratives can wait.

Who Pays?

Every problem worth hacking on has a payer — but finding them requires more than asking “would you pay?”

The difference between an entrepreneur and everyone else is simple: entrepreneurs ask for money. Not opinions. Not validation. Money. Hypotheticals are cheap. Payment forces truth.

But “who pays?” is not a single-answer question. The person who feels the pain most is often not the person with the budget. A junior hire wants to cut workload and avoid mistakes. A manager wants the problem solved and wants to look competent, defensible, and visibly effective while doing so. A founder cares about cost, risk, and optics to the board. Same problem, different incentives.

This is why understanding the ICP matters. You’re not just identifying a user — you’re mapping incentives. Who feels the pain day to day? Who owns the budget? Who takes the blame if this fails? Who gets credit if it works?

These distinctions shape everything. A product for juniors is usually bottom-up, cheap, and usage-driven. A product for managers needs visibility, auditability, and a clear story they can tell internally. If you ignore this, you end up with tools that users love but managers block, or tools managers buy that nobody actually uses.

Never ask “would you pay for this?” That question invites politeness and imagination. Ask them to pay. Even a small amount. Even informally. Even as a test. Payment collapses ambiguity and reveals who actually cares enough to act.

You don’t need to spend too much time hypothesizing. Go out there and ask people about their problems, then ask them to pay you. If they can pay you, then build it for them.

Business models don’t fail because the tech is bad. They fail because incentives are misaligned. If you can’t explain who pays, why they pay, and how the solution makes them look good while solving the problem, you don’t yet have a real business.

We’ll go deeper on how to do this in the sales section. For now, treat this as a hard filter:

if you don’t know who pays, you don’t yet understand the problem.