Founders who hire an engineering firm usually arrive expecting either that the firm takes the problem away entirely, or that it executes a plan they already hold fully formed in their head. Neither survives contact with a real program. The workable answer is measurable: on a typical six-to-nine-month hardware project, the client side spends three to eight hours a week, clustered hard around a handful of decision points where the project cannot move until someone with authority says yes.

The Time Budget, Phase by Phase

Involvement is lumpy. Understanding where the lumps fall lets you plan around your day job or your other obligations instead of being ambushed.

  • Definition and requirements (weeks one to four): the heaviest stretch, often eight to twelve hours a week, transferring everything you know about the customer, the price point, and the competition into a document the team can build from. Who drafts that document is covered in who writes the product requirements spec.
  • Concept and industrial design: four to six hours a week. Concept reviews, material and finish choices, and the round-by-round narrowing that turns five directions into one.
  • Detailed engineering: the quiet phase, one to three hours a week. The team is inside CAD and firmware. Your job is to answer questions within a day or two and otherwise stay out of the way.
  • Prototype evaluation: spikes back to six or more hours, because you are physically handling parts, running them past real users, and deciding what is good enough.
  • Production preparation: three to five hours a week, heavy on approvals: tooling release, packaging sign-off, the first article you accept or reject.

The Decisions No Engineer Can Make for You

An engineering team can tell you what a decision costs. It cannot tell you what the decision is worth to your business, because that depends on facts only you own. Five categories come up on essentially every project.

The cost ceiling. Someone has to declare the landed unit cost the product must hit, because that number silently decides material choices, part count, and manufacturing process. Declaring it late means redoing work.

Feature triage. Every project reaches a week where the schedule and the feature list stop being compatible. Cut a feature, extend three months, or spend more. Engineers can quantify all three; only you can choose.

Regulatory ambition. Chasing one market or four changes the design from day one, and adding a market later costs far more than designing for it, so start with finding out early whether your product needs regulatory approval.

The spec freeze. At some point you sign that the requirements are final. Everything after that is an engineering change order with a price tag, which is exactly how the ECO process is supposed to work.

A Review Cadence That Actually Holds

The cadence that works on most projects is simple and boring: a written status note every week, a thirty-minute call every week or two, and a formal gate review at the end of each phase where something gets approved in writing. Gate reviews are where the real decisions live, which is why stage-gate development holds up better than open-ended time-and-materials drift.

What a Useful Weekly Update Contains

  • What closed this week, in deliverable terms, not activity terms.
  • What is blocked, and specifically what is blocking it.
  • Open questions waiting on you, each with a date by which an answer is needed.
  • Any change to schedule or budget, flagged the week it appears rather than the month it becomes undeniable.

Keep a decision log. One shared document, one line per decision, with the date and the reasoning. Six months later, when someone asks why the housing is polycarbonate instead of ABS, the log answers in ten seconds instead of triggering a two-day archaeology exercise. Version control on the engineering side does the same job for files, as described in engineering documentation and version control.

What a Silent Client Costs

Projects rarely stall because the engineering got hard. They stall because a question sat unanswered. The mechanics are unglamorous and expensive.

A team that cannot get a decision does one of three things. It guesses, and roughly half of those guesses get reworked later. It stops and reassigns your engineers to another client, which means your restart is not immediate but four to six weeks out when those people free up again. Or it keeps working on lower-value tasks and burns budget on items that were not on the critical path.

The cost compounds downstream. A two-week delay approving a housing material can miss a tooling shop's queue slot and push first shots out six weeks. Silence during prototype evaluation is worst of all, because the window where changes are cheap closes when tooling is cut.

Set a norm at kickoff: questions get an answer within two business days, even if the answer is "I need a week, here is why." Name a single decision-maker. Projects with two co-founders who both have opinions and neither has authority are the slowest projects there are. The kickoff meeting is the right place to settle this.

Over-Involvement Is Its Own Failure Mode

The opposite problem is real. A founder who calls daily, redirects work mid-sprint, or hands the mechanical engineer sketches of a new concept every Monday produces churn that costs more than absence. The symptoms are the same subsystem redesigned three times and a schedule that slips every week without any single dramatic event.

The healthy split is that you own what and why, and the team owns how. If you find yourself specifying screw sizes, either you have hired the wrong team or you are doing their job with less information than they have.

Involvement When Everything Is Remote

Distributed projects work on discipline rather than proximity. Shared CAD viewers, video walkthroughs, and photographs of every build stage substitute for standing over a bench. What they need more of is written decisions, because the hallway conversations never happened. The practicalities are covered in developing a product remotely, and the same habits carry through to acceptance testing and handover at the end.

Plan Your Hours Before the Project Starts

Projects House works with US founders on exactly this rhythm: defined gates, written weekly updates, and a clear list of the decisions that need you and when. Tell us your product stage and how much time you realistically have each week through our contact form, and we will map the involvement your project would need.