Quite by accident I was in the audience at a tech conference, and the panel was promoting startups.  The panel were all VCs, no founders, and their advice was focused on why you should create a startup.  Their position can be summed up by the expression they said repeatedly:  "Just go for it."

I do not understand how "Just go for it" is actionable advice, I might be missing something obvious to you, but "Just go for it"  sounds like the worst possible advice to me. The VCs on the stage might have their own incentives for creating more startups, but those incentives have nothing to do with your individual success.

My advice to a  potential technical founder would be, "Don't do it unless you have really thought things through.  Even then, you probably should not do it. Figure out some more stuff first.  Or get a real job."

Most technical founders end up creating more or less what they said they would, more or less on time, and more or less on budget.  Yet most  startups fail.

They don’t fail because the technology didn’t work.

They fail because they built the wrong thing extremely well.

This is a trap technical founders are especially vulnerable to.

If you know how to build systems, write code, design hardware, or make hard things work, the instinct is to start with can I build this?  But that’s almost never the right first question. The right question is whether the thing is worth building at all, at this time, and whether you are the right person to build it.

Before you incorporate, hire, or raise money, there are a few assessments that matter far more than your architecture diagram.

[Author's note:  There is so much written about this that  I won't pretend to have anything original to say.  Heck!  I have written articles and blog posts and given funny but unoriginal talks about this for decades! A lot of the material  tends to be quite dry, or written in a way that fails to connect to a 1 or 6 person startup.  Here, I tried to avoid any fancy or professional language, any big stories that might distract you from realizing how this applies to you, the potential technical founder]

1. Is the Problem Real—or Just  Interesting?

Technical founders are great at finding elegant problems. Markets don’t care about elegance. They don't care about technology.  They don't care how cool and tricky whatever you just built is. They don't care how smart you are.  They don't care how hard you tried.  You are just going to have to trust me on this.

And that was before AI.  AI is quickly eliminating any technical advantage from anyone on anything.  Building something better, in hardware or software, is probably not going to be a useful foundation for any startup.

A  good startup problem has three properties:

1. Someone is waking up in the morning fearful that they don't have your solution today

2. They are already spending time or money trying to solve it

3. Doing nothing about this problem is not going to work for them.

I am using "someone" in a very specific context.   Someone is an addressable person.  You can reach them.  A platform, an enterprise, a stack, this is not  a someone.  You can't sell to a platform or an enterprise.  You can sell to a specific person at and enterprise - this is an important distinction that is often missed, although many books have been written about this one idea.

If the problem disappears when budgets tighten, it’s not a startup problem. If people describe it as “interesting” instead of “painful,” that’s a warning sign. If users can postpone dealing with it indefinitely, you don’t have urgency—you have a curiosity project.  You have people who will waste your time but never help your startup succeed.

Before writing a line of code, ask: what happens if this problem is not solved for the next year? If the honest answer is “not much,” you might as well stop coding. 

I know what you are thinking, because I have had that thought, too:

"Once I build it, and people see how awesome it is, everyone will want it and these three properties will be obvious."

So far, in the hundred, maybe thousands of companies I have worked with over decades, this "Field of Dreams" strategy has never, ever worked.  Not once.  But maybe you are really, really lucky!

2. Do You Know Who Actually Makes a Buy Decision?

Users are not buyers. Technical founders often conflate the two.

Our someone needs to:

1. Feel the pain

2. Control a budget

3. Be motivated to act

At a big company, this might be three different "someone"s.  You might need three different people to work together to get your new product sold or adopted.  

If you can’t name specific roles—or better yet, specific people—who would write a check, you don’t yet have a business. “Developers,” “enterprises,” or “any company with data” are not customers. They are placeholders for thinking you haven’t done yet.

A good test: could you make a list of 10 organizations that would plausibly buy your product within 6 months? Not eventually. Not after refinement, after a long and probably growing list of features that come out of meetings with potential customers.... within 6 months?

Of course, the 6 months is arbitrary.  Depending on what you are doing, maybe it should be a year.  Maybe one month.  But I hope you get the idea.

Does all this talking to customers and product strategizing sound like stuff a technical founder wants to do?

3. Is the Value Obvious and Asymmetric?

Great technology does not automatically create value. It only creates value if it produces a result someone cares about.

You should be able to explain, in plain language:

1. What improves?

2. By how much?  (with numbers)

3. Over what time frame?  (with numbers)

“More efficient” or "simpler to use"  is not a value proposition. “Cuts processing time from two days to ten minutes” is.

If the benefit requires a long explanation, a demo, and a white paper sales will be slow and expensive. A slog. Buyers prefer obvious wins with immediate value.  They don't want to wake up in fear anymore. Asymmetric wins—things that are clearly worth the effort and risk.  When you get it right, it wont be hard to explain.

Is every word  that you share with a customer building to a close,  towards a mic drop moment?  If not,  more words are not helping you. If you can’t quantify the upside in under a minute, you don’t yet understand your own value.  

4. Why Hasn’t This Already Been Solved?

This is a critical question technical founders often avoid.

If the problem is real and the market is large, you should assume capable people have noticed it. If no one credible is working on it, there are only a few explanations:

1. It wasn’t possible until recently

2. Incumbents are structurally unable to move

3. The economics don’t (or did not)  work

4. The problem isn’t actually painful

Your job as a startup founder is to identify which one applies. “Everyone else is stupid” is  never the right answer.  As an investor my favorite answer is (2).  Founders seem to like (1) but then it has to be defensible from other technical founders....

A strong startup thesis includes a clear explanation of why now and why others can’t or won’t.

5. Can You Get to the First 10 Customers Yourself?

Before you scale anything, you need to sell something. Maybe you need to sell a baker's dozen.

If your idea requires a large sales team, a long procurement process, or multiple integrations before a customer can say "yes", early momentum will be hard. This doesn’t mean enterprise startups are bad—it means founders need a realistic path to the first deals.

Ask yourself:

1. Can I personally convince someone to try this?

2. What is the smallest credible version that delivers value?

3. How long will the first sale really take?

Founder-led sales is not optional early on. It’s how you learn what actually matters.  As a startup founder, you are trying to turn an idea into a solution that people will pay you for.   You are wrong if you think you can hire "the sales guy" or "the biz dev gal" to do this for you.  You are working on a customer discovery problem. Sales and Biz Dev are something different than customer discovery.  Sales and Biz Dev are what happens once you, the founder, have determined the value of what you are doing in the eyes of the customer, who buys, and how that process works.

Do you find it shocking that a sales person is not useful for the first sale for a startup?   I did.  I learned this the hard way.  I was so let down.  I was very upset about this, actually. 

If you have ever actually worked in sales, or seen "Glengarry Glen Ross" this will makes sense. The perfect sales person takes the product messaging that someone else created, takes the call list that someone else put together, and runs a process whose only measurable outcome is closing a sale.  Anything else is a distraction from making more commission. The moment a good sales person gets to where they are not going to close, not going to make commission, they disengage and move down their list.  Sales people are not going to gain anything by learning why they are not closing that customer. They might make up an interesting story to explain why they failed to close, but if you are on that call or in the meeting, I am willing to bet you will have a different version of that story.

If you don't enjoy talking to people or otherwise engaging about the problem you you are solving, why are you working on this? 

[Not relevant here, but do you know another shocking thing I learned? VCs are rather bad at writing startup pitch decks. Their job is to get to a pass/fail decision very quickly. Helping founders understand how they made their decision and what the founders can change to improve on their next VC pitch is not a practiced skill for them. If you ask they will tell you something, they want to be nice, they want you to come to them with your next idea, but as soon as you leave the meeting they will admit they said stuff to end the meeting painlessly, and it's probably bad advice. I know, shocking, isn't it? ]

6. What Is the Hardest Risk—and Is It Technical?

Most technical founders focus on technical risk because it’s familiar. Often, it’s not the real risk.

The harder risks might be:

1. Distribution

2. Willingness to pay

3. Behavior change

4. Integration friction

5. Trust or credibility

If the technology works but adoption stalls, does the company still succeed? If not, you need to address that risk just as seriously as the engineering.

Be honest about what has to go right—and what happens if it doesn’t.

7 Are You Personally the Right Founder for This?

This is the quiet question underneath all the others.

Why you? Not in an inspirational sense, but in a practical one.

1. Do you have unfair insight from experience?

2. Do you understand this customer deeply?

3. Do you care enough to push through long periods of ambiguity?

Startups are endurance sports. If the problem doesn’t genuinely matter to you it is unlikely you will keep going when things get boring, silly, or scary.

A useful test: would you still work on this if fundraising took longer than expected? If progress was slow? If recognition was delayed? If the answer is no, that’s not a moral failing—it’s information.  Look for something else!

Final Thought

Starting a company is one of the most asymmetric bets you can make with your time. Done well, it compounds. Done poorly, it quietly burns years.

Technical founders have an unfair advantage in building things. The discipline is learning when not to build—yet.

The goal is not to start a startup.

The goal is to start one that deserves to exist, that will make you money or make the world better or fulfill some useful objective, other than keep you engaged.

If you assess honestly, early, and without ego, you dramatically improve your odds of doing exactly that.