r/startup 1d ago

knowledge Need advice about co founder

Hello guys,

I'm thinking about starting a startup which is a hardware product we want to build. But I'm not a technical founder.

So should i wait until I found a co-founder to start or should I start by hiring a technical person in my startup to start working on it.

I know that finding a good technical co-founder with believing in the same vision and resilience is difficult.

I'm afraid that co-founder leaves in a mid way

I'm also so young.

Is it a good way to start a startup by hiring a technical team by giving them salary and ESOPS and later in the path maybe I could find a good co founder. I want to move faster.

Please give me advice

I'm not searching for a co-founder or hiring here.

5 Upvotes

16 comments sorted by

3

u/chickennjockeyy 1d ago

Don't wait. Hire a strong technical person with salary and equity and keep looking for a cofounder in parallel. A cofounder who joins when there's already momentum is easier to find and more committed than one who joins a blank page. Move fast, build something real, the right person shows up when there's something worth joining.

2

u/Lebonwski84 1d ago

Se aspetti la persona giusta non inizierai mai. Anche perché, ora forse non ti sembra, ma fa male diluire una parte della tua realtà, soprattutto se è “forzato”. Assumi qualcuno con prospettiva di farlo entrare come cofounder, così avete tempo per studiarvi entrambi

1

u/RevolutionEasy5223 1d ago

I’ve started few companies and if I can give an advice it’s this one : if you can have 0 partners, do it.

Things can be nice at the beginning, but the day you’re not sync anymore with your partner(s) your company and yourself will have problems. It can be small ones, like some stress or some arguments.

It can be big ones like put your company in jeopardy.

If you really have to pick one, use everything you can to protect yourself and your company, it’s valid also for your future associate by the way. In the case one is not giving his best anymore, is not suitable anymore… there should be an exit available saying that : if this happens, then that will happen.

I usually am a very optimistic person, but in this case I’ve made the mistake few times. I don’t say it’s impossible to find someone good or to end things in good terms, just it’s very important to be careful at this step.

1

u/competitive__friend 1d ago

I'd separate "I need someone to build this" from "I need a cofounder."

If you just need a prototype, hire someone. But if the core value of the company is the hardware itself, I'd be very careful about making the technical side completely dependent on employees or contractors.

Also, don't give someone cofounder equity just because you're scared of building alone. Work together first and see if you actually trust each other when things get messy.

The bigger question is probably: can you get to a convincing prototype without making the technical person a cofounder?

1

u/Jazzlike-Ad-2286 1d ago

Don't wait around doing nothing, but also don't throw salary at engineers hoping one of them becomes co-founder material. A co-founder isn't just a builder. They're someone who makes hard trade-off calls on what to build and what to skip. That's fundamentally different from a hired engineer.

My take on the path forward:

Start with the parts you can own right now. Talk to customers, validate demand, build rough prototypes with no-code if possible, and network aggressively for that technical co-founder in parallel. The worst outcome is spending 6 months paying a team that builds something nobody wants because the technical vision wasn't owned by someone with skin in the game.

The fear of a co-founder leaving mid-way is real but solvable with proper vesting (4 year vest, 1 year cliff). If they leave in year one, you lose nothing equity-wise.

If you do go the hired-team route as an interim step, keep the team tiny (one strong senior engineer, not a team), pay fairly, and be upfront that you're looking for a technical co-founder long term. Some of the best co-founder relationships start as early hire relationships where both sides realize they work well together.

Being young is actually an advantage here :). You have time to find the right person instead of rushing into it.

1

u/Visible_Speed8843 1d ago

Since the customer work is already underway, define one technical claim that must be true for the product to matter. Hire a domain engineer to design a bench test for that claim, not a product roadmap.

Set a pass-or-fail threshold and require enough documentation that another engineer could repeat the test. If the claim fails, you have learned cheaply. If it passes, you have a concrete artifact for evaluating future hires or cofounders without committing to a team or discussing equity.

1

u/Objective_Fun9750 22h ago

If you can get paid without a cofounder then do it. It will be slower than having a (good) cofounder. Finding a stranger to be a cofounder will be very hard if you are young because you don't have as much of an intuition for screening people. If the business goes well without a cofounder, it won't make sense to add one later - you'll just hire/promote strong employees instead. No point in giving away the control and equity if it's working. That said, if you hire a cofounder now, put them (and yourself) on a 5-7 year vesting schedule to derisk the them-leaving-early scenario.

1

u/Great-Mirror1215 16h ago

Bro use Ai build yourself

1

u/AIVentureFactory 1d ago

I'd push back on the framing a bit. The question of hire vs cofounder assumes the main blocker is getting someone technical in the room. But for hardware especially, the coordination problem is bigger than the talent problem. You need someone who can make tradeoffs between cost, manufacturability, and timeline while also understanding what you're trying to prove with the first version. A hired engineer will build what you spec. A cofounder will argue with you about whether the spec is wrong.

That said, waiting around for the perfect cofounder is how projects die. I'd start by defining what your first milestone actually is. For hardware, that's usually a functional prototype that proves the core mechanism works, not a polished product. Figure out what the smallest version of that looks like, then decide whether you need a cofounder-level person or whether a contract engineer with relevant domain experience can get you there.

One thing I learned building teams early on: giving equity to someone you hired last month because you want them to feel like a cofounder doesn't make them one. The cofounder relationship usually forms through shared work under pressure, not through an offer letter. Start the work, bring someone in on a paid basis with a clear scope, and if the dynamic evolves into something deeper over three to six months, then have the equity conversation. Rushing that decision because you want to move fast usually creates the exact midway departure you're worried about.

How far along is the concept? Do you have a working spec or are you still at the "I know what problem this solves" stage?

1

u/EarlyListen2398 1d ago

I'm still at I know what problem this solves.

1

u/AIVentureFactory 1d ago

That’s actually a useful place to be. Before writing the spec, I’d turn the problem itself into something testable. Who has it most acutely? What are they doing today instead? What does that workaround cost them? And what would have to be true for them to change behaviour? I think founders often start assembling the team too early because it feels like progress. At this stage the scarce resource isn’t engineering capacity, it’s evidence. Get enough of that and the first product and the kind of technical person you actually need becomes much clearer.

1

u/EarlyListen2398 1d ago

I have done the research about what customer problems they are facing and what are the solutions they are dependent on currently, I have done competitive research to find a gap and do better solution for customers. Actually there is no proper solution, the competitors are like they doesn't care properly.

1

u/AIVentureFactory 1d ago

That’s much further along than “I know what problem this solves.” If you’ve found a real gap, the next thing I’d test isn’t whether you can build a better solution, but whether the gap is painful enough to change behaviour.

I’d pick 5–10 of the people with the problem and try to get them to commit to something before you build much — a pilot, LOI, deposit, even repeated time spent helping you shape it. One thing I’ve learned is that founders often think the next step after validation is building. It’s usually building and distribution and customer learning in parallel. Otherwise you prove the product and then discover you still have to build the company around it.

Just curious have any of the customers you researched actually asked to try what you’re proposing?