When Should a Startup Hire a Product Development Partner?

Keep the product owner inside the company. Buy a bounded phase with a deliverable and a stop, not a retainer that measures activity. You should leave owning the source files and able to take them to another manufacturer. The money below is hypothetical teaching maths. It is not a BrahmWorks fee, not a salary survey, and not a reason to hire or not hire on the rupee gap alone.

The useful scope is a missing practice. Mechanical design for a process you can name. Electronics a contract manufacturer can build. Firmware architecture when nobody in the company has done it. Or the work of taking a prototype that already functions into something a factory can repeat. That last scope, once the unit works, is the subject of How to Take a Hardware Prototype to Production. Hiring someone to "do the hardware" without saying which of these you mean will be priced as if you meant all of them, and the result will be a bit of each.

A partner is also a review you are too close to give yourself. That is worth paying for only if they are allowed to reject a feature, a material or a date. A partner who is paid to agree is an expensive meeting with drawings attached. Put the right to reject in the way you brief them, and do not punish the first disagreement or you will not get a second one.

Do not hire a development partner instead of writing a requirement. If the payer, the job and the thing you would not ship without are unwritten, the partner will stall or will invent them. You then pay for their assumptions and discover the invention at the tool. Stop and write the brief. A week of writing is cheaper than a month of CAD pointed at the wrong product.

Do not hire one because a pitch needs CAD. A model built to decorate a round is not a phase of development. It produces files nobody can manufacture, and a belief inside the company that the product already exists. Investors who know hardware will ask which question the model answered. If the answer is "none", the drawings have made the conversation worse.

Do not hand over the whole company. The supplier relationship you will have to live with, the firmware if that firmware is the thing you are actually better at, and the decision to ship, stay with you. A partner who holds every file and every vendor, with no exit, is a single point of failure with an invoice. Continuity of the product is your problem even when the drawings are someone else's work.

A contract manufacturer who also offers design will quite reasonably favour the processes they already run. That is a good fit when you have chosen those processes on purpose. It is a poor fit when you have not, because the design becomes "what our line does" without anyone writing that choice down. Ask who is paid to disagree with the factory. If the answer is nobody, you do not have a development partner. You have a supplier who draws, and the disagreements will surface as late quotes rather than as design options.

This is not an argument against manufacturing input. A process engineer who marks up a drawing early can save a tool. The failure is letting that markup be the only review, and letting it happen before you know which requirements are allowed to lose.

One founder writes firmware and knows the protocol the fleet already uses. The other sells. Together they can define the message, the power available on the vehicle, and the environment: heat, vibration, and a connector a technician can mate in a yard. They cannot design the enclosure, the power protection, or a board a manufacturer can panelise and test. That is a specific gap, not a general lack of seriousness.

A bounded phase is mechanical design and electronics through a brought-up board in a printed enclosure. Both sides sign a pinout and a power budget before layout starts. Firmware stays with the founder. Parts are a separate invoice, with the bills visible. The deliverable is files at a named revision, a bring-up log, and a list of what the printed housing did not prove. It is not a tooled product, and it is not a verdict on the protocol. If the only open question were whether a factory can repeat a design the founders already trust, the phase would be the handover, not a fresh architecture. Paying for an architecture you do not need is a way to look busy.

Invented inputs, so the method is visible. Replace them with salaries you can pay and with a quote for a scope you wrote.

• Loaded cost of one engineer: INR 1,80,000 per month. Not a market rate.
• The gap is two disciplines, mechanical and electronics.
• The bounded work lasts 4 months.
• A partner phase covering both for those 4 months: INR 14,00,000, parts excluded. Not a quotation.
• The hires need 6 weeks before they produce. Those weeks are calendar. Do not turn them into lost revenue. You do not have that number, and a made-up one would decide the question dishonestly.

Employment cash for four productive months: 2 × 4 × 1,80,000 = INR 14,40,000.

Set against the phase fee, the difference is 14,40,000 − 14,00,000 = INR 40,000. That gap is smaller than the uncertainty in either invented figure. On cash alone, the two options are the same decision, and anyone who claims the rupees settle it is reading past the label.

The calendar is a different fact. The hires produce nothing for 6 weeks. A phase with a written brief can start in days. Six weeks matters when a season, a customer trial or a date you have already filed is real. It does not matter when you will need both skills for years and you can spend the wait.

Extend the same rates, still as fiction, to see the long case. Two employees for 18 months: 2 × 18 × 1,80,000 = INR 64,80,000. A hybrid, the 4-month phase and then one employee for the remaining 14 months, is 14,00,000 + 14 × 1,80,000 = 14,00,000 + 25,20,000 = INR 39,20,000. On these numbers the hybrid spends less and leaves you with one person, not two, and with less of the practice inside the company. If the second discipline is still required in month 18, the hybrid was a delay dressed up as a saving. Run the sum again with real salaries and a real quote. When the totals are close, choose on the calendar, on whether you will own the files, and on whether the skill has to remain after the phase stops.

Name the deliverable, the revision, and what is outside the fee: tools, laboratory fees, parts, a certification submission, a second spin. Name who owns the source files, who owns a tool if one is created, and that you may use another factory. Name who can grow the scope, in writing, before the extra work starts. A phase that grows by agreeable email is how four months become a year without a second decision.

Give the partner the constraints you will not trade, and the failures you have already seen, not only the demo. Hiding the failures to look further along produces a plan for a product you do not have. A competent partner will find them later, on your invoice, or will design around a success that was never repeatable.

• You have written the user, the job and the requirement you will not ship without.
• The missing discipline is named. "Hardware" is not a discipline.
• The phase has a deliverable, a revision and a stop.
• Parts, tools and laboratory fees are either outside the fee or explicitly inside it.
• Source files and any tool can leave with you.
• Your product owner can reject the partner's proposal without ending the relationship by surprise.
• Firmware, if it is your asset, has a stated home.
• The manufacturer is not the only reviewer of the design.
• The partner has seen the failures, not only the demo.
• A hiring lag is either acceptable or it is the reason the phase exists.
• Any rupee comparison uses your salaries and a written quote, not the illustration above.

When form and internals will conflict, which they will on anything handheld or sealed, one team that has to resolve both is simpler than two vendors who each believe they have finished. Split the work only if someone inside your company will force the trade and own the master model. Two vendors and no owner is how you pay for two files and then pay again to reconcile them. The reconciliation is the actual design, and it will not be in either quote.

The brief, the environment, the quantity you are designing toward, and what must not be cut. Also the constraints you already know are commercial rather than technical: a connector the vehicles already have, a price band, a market you will not enter. And every workaround already hiding in the prototype. A partner who starts from a render and a verbal hope will spend the first month interviewing you. That month is still part of the phase. It is not free discovery.

At the stop you wrote down, or earlier if the evidence kills the requirement. Extending because the relationship is pleasant turns a phase into a department you do not manage. Stay for another phase only when that phase has its own deliverable and the skill is still missing. Hire employees when the work is continuous and you can use the lag. Do not keep a partner as a way of avoiding a hiring decision you have already made in practice.

Not always. A studio that learns quickly at the bench may not produce drawings a factory can run. A factory team may be the wrong place to disprove an idea, because disproving it does not fill a line. Ask which question the next months must answer, and hire for that question. Changing the question in the middle, without changing the contract, is how both sides feel the other has failed. They are often both describing a scope that was never written.

On UltraFast EV charging hardware, BrahmWorks has treated the enclosure, screen mounting, cable routing, component access and the electronics as one review. A partner engaged only to deliver a board, or only to deliver a shell, will not see the interface where those meet. If that interface is the risk you are paying to reduce, write it into the phase. No yield, cost, time or test result from that charging work is stated here.

Bring the brief, the skills you actually have on the team, and the decision the next phase has to close. BrahmWorks can say whether that phase is design, a repeatable build, or a requirement you still have to write yourselves.

Review the next stage with BrahmWorks