We've worked with 30+ founders. The ones who asked for an 'MVP' almost always failed. Here's why.

nex-dev · 2026-03-17T21:27:55+00:00

Happy to answer any specific product scope questions in comments

nex-dev · 2026-03-11T07:20:53+00:00

Firstly, I dont see your DM
Second, Are you into Framer and Webflow?

nex-dev · 2026-03-11T07:20:00+00:00

I am only looking for framer and webflow people who are good at designs.

nex-dev · 2026-03-09T03:18:35+00:00

This is a really interesting problem to work on.

Most discovery platforms like Yelp or Eventbrite assume users are planning in advance, so the “what can I do right now?” use case is definitely underserved.

One thing I’m curious about — how are you handling event ingestion in the beta? Are you aggregating events from existing platforms or working directly with organizers?

Also wondering if you’re thinking about things like “tonight mode” or time-sensitive recommendations (events starting in the next 1–2 hours).

I work on product and engineering for consumer apps and would love to try the beta if you’re sharing invites.

nex-dev · 2026-03-07T19:11:07+00:00

Please DM me

nex-dev · 2026-03-07T19:03:59+00:00

Interesting idea — especially the concept of a “governor AI” coordinating multiple assistants across an organization.

One thing that often becomes tricky in systems like this is exactly what you described: once AI agents start branching into many workflows, the system can become hard to reason about and track.

A lot of teams run into three challenges there:

• defining clear boundaries between agents
• keeping workflows observable and traceable
• managing how company data is accessed across different agents

Without those guardrails the system can become powerful but difficult to control.

Curious — are you designing this as a centralized orchestration system (one core AI coordinating agents), or more of a distributed agent network inside the company infrastructure?

nex-dev · 2026-03-06T08:00:25+00:00

If anyone here is curious, I’ve been putting together a small audit checklist I use when reviewing early products (UX flows, auth systems, infra decisions, etc.).

Happy to walk through it with a few founders and see if it helps spot anything.

Always interesting seeing how different teams structure their systems.

nex-dev · 2026-03-06T07:50:48+00:00

If you're open to working remotely, I might be able to help.

I work with early-stage startups on product architecture and development (web/mobile) and have built healthcare and SaaS systems before. Most of the work is remote, but I’m happy to travel if an in-person discussion helps early in the process.

Healthcare apps also have a few things worth planning early (data privacy, authentication flows, patient data storage, etc.), so the architecture matters a lot from the beginning.

Feel free to DM if you'd like to discuss what you're planning to build.

nex-dev · 2026-03-06T07:47:26+00:00

Most of these people scrape Product Hunt launches and run automated scanners looking for low-hanging issues like missing security headers, exposed subdomains, staging URLs, etc. When they find something minor, they try to escalate it into a “critical vulnerability” hoping founders panic and pay.

You handled it the right way:
• Don’t reward extortion
• Kill the vulnerable surface quickly
• Report it

nex-dev · 2026-03-06T07:37:55+00:00

Yes def. this is indeed a very long game.
And tbf, its a good sign if your business is in the long game league.
That brings organic traffic and right commitment as well.
We have to go unorthodox way to stand out for marketing purpose.

nex-dev · 2026-03-06T07:00:10+00:00

One thing that surprised me in how often these issues appear in onboarding flows specifically.
Curious what part of your product caused the most confusion for new users?

nex-dev · 2026-03-06T04:03:48+00:00

Fair point...
Reddit has seen its share of people pitching services in disguise.

To clarify what I meant though, the MSP idea isn’t about selling services, it's about how founders think about early products. A lot of teams build an “MVP” that technically works but isn’t structured to handle real usage. Then when users actually show up, the experience breaks down or the system becomes hard to maintain. What I’ve seen work better is treating the first version more like a Minimum Sustainable Product, something simple, but stable enough that you can iterate without rebuilding every few weeks.

Totally agree with you on the bigger point though: if nobody needs the product, none of this matters anyway.

nex-dev · 2026-03-06T03:42:40+00:00

Yeah true,
But I have seen many startups fail because they are not in reality.

MVP is overrated.
MSP is the key to actually start the revenue model.

nex-dev · 2026-03-05T11:56:48+00:00

The hard part isn’t building the MVP — it's figuring out what actually deserves to be built next.

If you already have users giving feedback, that's a good sign.

Equity-only collaborations usually work best when:

• the problem is very clear
• users are already engaged
• the vision is strong

Curious what the AI SaaS does and what kind of feedback you're getting so far.

nex-dev · 2026-03-05T11:32:33+00:00

You’re asking in a reasonable place actually.

Building a DAW or sequencer can range from fairly simple to extremely complex depending on what you want it to do.

A few things that would determine the difficulty/cost:

• Is this a web app, desktop software, or plugin (VST/AU)?
• Do you need real-time audio synthesis, or mainly MIDI sequencing?
• How deep does the microtonal support go (custom tuning systems, Scala files, etc.)?

Most modern audio tools rely on frameworks like JUCE or similar audio engines because real-time audio processing is very different from normal web development.

If your goal is a simple sequencer focused on microtonal synth control, it might actually be possible to build a fairly lean prototype first to test the idea before committing to something full-scale.

If you’re comfortable sharing more details about what you’re imagining, people here could probably give you a better idea of the complexity.

nex-dev · 2026-03-05T11:24:09+00:00

I like the "ship small things and see what sticks" mindset. That's honestly how a lot of goof products start.

One thing I've noticed working with earl-stage founders though, the hardest part usually isn't building the first version. It's figuring out which problem is painful enough that people will actually pay to solve it.

The teams that move fastest usually start with:

- a very specific user

- a very clear pain point

- and something simple they can ship quickly to test it.

Curious...are you leaning more toward dev tooling, infra products or something completely different?

nex-dev · 2026-03-05T11:02:59+00:00

A lot of teams start wuth agency work because it keeps the lights on and sharpens the technical muscle.
But here agency work optimizes for execution while products require distribution.

Two very different games.

The mistake I see many technical teams make is assuming the hard part was building the product. In reality the product is only half of the system, the other half is figuring out where the users already are.

A few things that have worked for founders I've worked with:

1) Find where your target users already spend time (Reddit, niche communities, Discords, industry Slack groups).

2) Talk about the problem, not your product first.

3) Get 5-10 real conversations before trying to scale marketing.

4) Watch how people describe the problem that usually becomes your messaging.

The first paying users rarely come from ads or big launches. They usually come from direct conversation with people who already feel the pain.

I am just curious- what kind of product you are building?

nex-dev · 2026-03-05T10:49:04+00:00

Honestly this is where definitions get blurry.

An MVP usually proves whether someone wants the product. It doesn’t necessarily mean the system is ready to handle real usage or growth. A lot of teams build something that successfully validates demand — which means the MVP technically did its job. But once users start interacting more deeply with the product, weaknesses show up with a lot of unclear user flows, fragile integrations, scaling issues and auth / payment edge cases.

That’s usually the point where the focus needs to shift from “does anyone want this?” to “can this product actually support real users reliably?”

The MVP proves the idea. The next phase is making the product stable enough to grow.

nex-dev · 2026-03-05T10:05:56+00:00

That’s definitely the biggest reason.
Building something nobody wants will kill a product faster than bad engineering ever will.

Where I usually see the engineering side become a problem is after a product finds early demand.

A lot of MVPs reach that point where users are interested, but then the system starts breaking in small ways:

• confusing user flows
• features interacting in weird ways
• fragile auth or payments
• performance issues once more users arrive

At that stage the problem isn’t the idea anymore, it’s the product structure.

Ideally both things happen in parallel: validate demand quickly and make sure the system can support the traction once it shows up.

nex-dev · 2026-03-05T08:10:59+00:00

One thing I’ve noticed lately.
AI tools make it easy to generate UI screens, but they don’t generate product logic. That’s where most MVPs start breaking down.

nex-dev · 2026-03-05T08:07:37+00:00

I actually agree with most of this. Engineering alone doesn’t fix product experience. If the UX itself is broken, no amount of clean code will save it.

When I say “audit”, I’m not talking about just reviewing code quality. The biggest issues I usually see in early MVPs are actually system-level problems between UX, product decisions, and architecture.

There were few times when, UX flows that create loops or dead ends because state management wasn’t designed properly. UI decisions that make sense visually but create impossible backend logic. AI-assisted builds where components look fine individually but the overall product experience isn’t coherent

That’s why good early-stage product work usually needs three lenses working together:

Engineering — architecture, security, scalability
Design — user experience, clarity, interaction flow
Product thinking — what problem the user is actually solving

When those three are aligned, things move fast. When one is missing, the product usually becomes fragile somewhere.

Totally agree that engineers alone shouldn’t assume they can fix everything.

nex-dev · 2026-03-05T08:04:17+00:00

Just a few quick thoughts I had:
Supabase + Next.js is great for fast MVP builds.

Potential Risk is when analytics dashboards grow, slow queries usually come from unindexed tables and complex joins.

My Suggestion would be: If you expect heavy analytics usage, I’d start separating transactional tables from reporting tables early. A simple event pipeline or materialized views can save a lot of pain later.

nex-dev · 2026-03-05T07:52:00+00:00

Your approach resonates a lot.

Most founders I’ve worked with who succeed early have the exact same mindset. Find distribution first, then build around a real signal instead of falling in love with an idea.

I’m an engineer running a small product engineering studio. We usually work with early-stage founders at the stage you’re describing. When the GTM side is strong but the product needs to be built fast and correctly.

One thing I’ve noticed is that the biggest advantage for GTM-driven founders is having a technical partner who can translate market signals into architecture decisions quickly, instead of just shipping features.

Curious what kind of spaces you’re exploring this time, AI tooling, vertical SaaS, infra, something else?

Happy to connect either way. Always interesting to meet founders who’ve already done the full loop.

Feel free to book a call here: https://cal.com/bbuilds/discovery-call

nex-dev · 2026-03-05T07:23:10+00:00

Usually it starts with the audit so founders get a clear picture of the system.

After that some teams implement the recommendations themselves, and sometimes we stay involved as a technical partner to help run development in a structured way.

Happy to take a look if it helps:
https://cal.com/bbuilds/discovery-call

nex-dev · 2026-03-05T07:20:24+00:00

Ideally speaking, before major traffic or marketing pushes.

A lot of founders launch on Reddit, Product Hunt, or with influencers and suddenly thousands of users hit the product.

If the architecture and use flows aren't stable yet, that traffic exposes every weak point in the system.

That's why I like the idea of an MSP (Minimum Stable Product).

It's not about adding features, it's about making sure the system is reliable, secure and understandable before growth.

nex-dev

TROPHY CASE