Next or TanStack? That's not the question

I have two projects in production. One runs on Next.js, the other on TanStack Start.

I am going to get the comparison out of the way in one section, because it is not the point. The real point is the thing nobody covers in framework threads: how you find users.

The comparison, quickly

This portfolio runs on Next.js. Prospect Tracker, the tool I use to run my freelance business, runs on TanStack Start.

The choice was not settled by benchmarks:

A content site needs pages generated at build time and indexable. A SaaS behind a login has no SEO needs at all, but demands heavy client-side state management.

Two different problems, two different tools. That is all.

The right framework is the one whose pitfalls you already know. Experience transfers poorly between ecosystems, and experience is what makes you code fast.

There you go. You can pick either one and ship something decent. Now let us talk about what will actually decide the fate of your project.

The product is not the problem

Coding a SaaS has become the easy part. Auth, payments, database: all solved, all documented, and a good chunk of it can be generated.

What stays hard is getting anyone to use it.

It took me a while to accept that, because it stings. You spend years getting good at development, then find out that skill alone will not keep a product alive.

Here are the principles I work from now, in order of importance:

• The right message: clear, speaking directly to the problem
• One feature, done well
• Good time to market: ship before the market shifts
• One offer, one price: no three-column pricing grid at launch
• One acquisition channel: spreading yourself thin kills you

None of them is about code.

Look for a problem, not an idea

The classic mistake is starting from an idea you find brilliant. The reverse instinct is more reliable: take an already validated market, pinpoint what existing solutions are missing, and do better on that specific point.

That is the Lemlist principle. Before them, dozens of cold email tools already existed. The founder simply looked at what users were complaining about with the competition.

It removes survivorship bias: the demand already exists, all that is left is serving it better.

And if you find no competitor at all, that is not good news. It is almost always the signal that there is no market.

The grid I use

Every idea gets scored from 1 to 5 on market saturation. The sweet spot sits at 2-3.

One more thing about picking a market: B2B monetizes more easily than B2C, because the value is calculable. A tool that saves a small company five hours a month justifies 50 to 100 € monthly without argument. In B2C, you have to convince an individual to part with 9 €, and that is often harder.

Validate before coding

Before writing a line, you need to check two things: the problem is real, and people are willing to pay for it to go away.

For Prospect Tracker, I did the bare minimum: a Tally form shared on my socials, before the first pnpm create next-app@latest command.

The answers did more for the product than any architecture decision. They told me what to build first, and more importantly what I could leave out.

Depending on how long the MVP takes to build, two approaches:

• Presale: a landing page with a pricing section, to see whether people pay on the strength of a promise. Useful when the MVP is quick to build.
• Prelaunch: a landing page with a clear promise, no payment, just signups. Useful when the MVP needs more than six months. You come back to the list once the product is ready.

There is also the "fake it" method: deliver the service manually while letting people believe it is automated. It tests real interest without investing in the tech.

The only signal that does not lie: finding at least three people outside your circle willing to actually pay. Not to test for free. The amount barely matters.

Pricing is decided before the code

Mistake number one is launching for free and telling yourself you will monetize later. The classic result: plenty of signups, zero revenue.

Pricing strategy gets thought through before launch, not after.

What you do not do at this stage, on the other hand: pick a final name, design a logo, polish a landing page, fine-tune a pricing grid. None of that finds users.

The math that puts things in perspective

Here is the exercise that made me think the most. Start from your revenue goal and work backwards:

Goal                        10,000 € MRR
Offer at 50 €/month       → 200 paying customers
10% conversion (freemium) → 2,000 active users
For 2,000 signups         → 50,000 to 100,000 people reached

A hundred thousand people. For ten thousand euros a month.

Once you see that number, you understand why the Next versus TanStack debate is secondary. No framework is going to win you 100,000 visitors.

One channel

The temptation is to do everything at once: Product Hunt, Reddit, cold email, ads, newsletter. That is the best way to do all of it badly.

One main channel at launch. The others come later.

• Sell organically: find the communities where your audience already is and show up honestly, without spamming your link.
• Word of mouth: set up an affiliate link as soon as the first customers are happy.
• Newsletter: build a list before the public launch, so you are not talking into the void on day one.

Then the snowball effect: word spreads, opportunities start arriving on their own. Only at that point do you reinvest in other channels.

Watch what people do, not what they say

Once the product is in the hands of early users, two signals are worth more than any declared feedback:

Do they come back without a nudge? Spontaneous usage is the only reliable indicator. Stated intentions are worthless.

What are they patching by hand? Whatever people work around inside the product points straight at the next feature to build.

That is why I set up tracking from day one, with PostHog events all over the place. Not to make a dashboard look good, but because without data you are building blind, running on gut feeling.

In practice

Both projects are live. That is the only criterion that holds up over time.

A project shipped with an average framework will teach you more than a perfect project sitting on your localhost. User feedback, edge cases, real performance issues: none of it shows up until you go live.

And the stack choice is reversible. Most of your business logic does not depend on it.

If you are torn between two technologies for your next project, three questions are enough:

• Which one do I know well enough to ship this month?
• Does my project need SEO, or does it live behind a login?
• Will I be able to debug a production issue at 10 PM with this tool?

Then move on to the real question, the one that decides everything: who is going to use this, and how will those people ever hear about it?

If you are a freelancer running your prospecting on a clunky Notion board, Prospect Tracker is being built in public. The form is still open: share your thoughts. It also gets you early access.