How to Build a Hardware MVP

Cut preferences. Do not cut a safety behaviour the use itself requires, and do not substitute away the physical fact you are trying to learn. If the job happens in a cold room, a warm bench is not the MVP. What a development prototype is allowed to fake, as a method inside a longer programme, is set out in Hardware Product Development Process Explained. This article is about product scope: which job is in, and which features belong to a later product. The day counts are hypothetical teaching maths, not a BrahmWorks plan and not a fee.

Write the job in a sentence a user would recognise. "A cook notices that a fridge has been too warm" is a job. "A platform for kitchen operations" is not. The MVP has to perform that sentence for someone who is not you, in the place the job actually lives. If you cannot name the person and the place, you are not ready to choose what to leave out, because you do not yet know what "out" would damage.

Then write the decision the MVP is allowed to change. Continue into a production design, narrow the user, or stop spending. If no outcome would change the next sum of money, you are building for comfort, not for information. Say in advance what evidence would make you stop. A stop condition written afterwards will be rewritten to match whatever you built.

The environment is part of the scope, not a detail for a field trial "later". A fridge logger that has only been tried in an office has not met condensation, gloves, or a door that slams on the cable. Include the condition that makes the job real. Exclude the conditions that belong to a market you are not in yet. Write both, so a success in one kitchen is not described as a success in every kitchen.

Cut anything that does not change the decision. A second colour. A custom mould. A dashboard for several sites. An account system. Updates over the air. A cheaper part you hope to use at a quantity you do not have. Those can be the right work after the decision. Before it, they add time and, worse, they add places to hide. A team can spend a month on login screens and honestly report that the hardware is "in progress".

Replace a cut feature with the crudest stand-in that is still honest. A printed case instead of a tool. A buzzer instead of a phone notification, if the question is whether a person notices. A spreadsheet instead of a cloud history, if the question is whether a manager looks at yesterday. The stand-in has to be something the user will actually touch during the job. A slide of the future app is not a stand-in for use. It is a slide.

Do not cut behaviour that keeps a person, a food contact or a mains connection inside the claim you are already making by putting the device there. An MVP used in a working kitchen still has to be fit for that kitchen. Calling it a prototype does not shrink a hazard. If the honest version of the job needs evidence or a material you cannot yet justify, the job is the wrong MVP. Narrow the job, or do not put the device in that use. There is no third option in which the hazard is paused.

Do not cut the measurement or the mechanism the job depends on. A logger whose temperature is typed in by the founder tests the lamp. It does not test whether anyone trusts the alert. Label every stand-in, and label the conclusion it forbids, in the same note as the result. A forbidden conclusion that is only remembered will be used in the investor deck.

Do not cut the chance for the user to fail in front of you. If you help on every trial, you have tested your help. Agree, before the trial, the help you will refuse to give. Write it down so that in the moment, when the user is stuck and the room is watching, you do not quietly become part of the product.

The teaching product is for a single restaurant, not a chain and not a platform. The job is that the person who closes up can see that a fridge stayed above a limit, without opening a laptop. The decision is whether the staff do anything different the next morning. If they do not, there is no reason yet to build accounts, history or a second site.

In the MVP: a probe in that fridge, a limit you can explain, a buzzer or a lamp the closer can perceive from the pass, and a paper note of what they did next. Out of the MVP: a custom mould, a phone application, history across several fridges, a battery if a mains adapter is acceptable in that corner, and any work on branding. The probe's contact with food or with air is not a styling choice. If the probe would touch food, the MVP uses a contact that is acceptable for that use, or the job sentence is rewritten to air temperature. You do not temporarily put an unknown material where food is.

The trial is a few real shifts, not a scripted visit. You watch whether the alert is noticed, ignored or defeated. An ignored alert is a finished MVP. It answered the decision. It is also a failed product idea, which is a result you are allowed to get. Building the cloud history in order to avoid that result is how the MVP quietly becomes a product nobody chose.

Invented person-days for this exercise. They are not a quotation, not a schedule to copy, and not a BrahmWorks estimate.

• Probe, limit and a reading you are willing to stand behind: 20
• A buzzer the closer can hear in the pass: 3
• A printed case that holds those parts in that kitchen: 5
• Custom shell surfaces, in place of the print: 15
• A cloud history and the logins it requires: 25

The MVP is 20 + 3 + 5 = 28 person-days.

The wish list, with the custom shell replacing the print, is 20 + 3 + 15 + 25 = 63 person-days.

The days you can refuse for now are 63 − 28 = 35.

At an invented internal cost of INR 7,500 per person-day, those 35 days are 35 × 7,500 = INR 2,62,500 of engineering. That figure is not a saving until the 28-day build has been in front of the closer. If the alert is ignored, the INR 2,62,500 is work you were right not to start. If the alert changes the morning, you will still spend some of those days later, and the 28 days were the price of earning the right to spend them. Tooling sits in neither total. A tool bought during the 28 days would be a different and larger commitment, made before the decision the MVP exists to support.

As a fraction, 28 ÷ 63 is about 0.44. The fraction is not a target and not a definition of lean. An MVP that happens to be 44 percent of a wish list can still be the wrong job, in the wrong room, with the founder helping. The test is whether a real closer meets a real fridge and whether you then change the spend. A percentage that looks disciplined in a plan does none of that by itself.

It is finished when the decision can be taken, not when the device is pleasant to show. Write what you saw. Who used it. Which help you refused. What failed. Which parts were stand-ins, and what those stand-ins cannot prove. A video of the device working in your hand is not that record. If you show the device to an investor, show the record as well. Otherwise you will be funded to build the history feature of a job that nobody acted on, and the funding will feel like validation of the job.

Then choose, in writing. Stop, narrow the user, or fund the path toward a product someone else can build. Do not drift into a second effort that adds the cloud "while the enclosure is open anyway". That drift is how an MVP becomes an unfinished product with no decision left inside it. The enclosure being open is not a reason. The decision is the reason.

• The job is one sentence a user would say.
• The decision the build can change is written, including the evidence that would make you stop.
• The environment is the real one, or the gap is explicit and accepted.
• Preferences are out. The mechanism the job needs is in.
• The use you are actually attempting is safe for that use, or you have narrowed the use.
• Every stand-in is listed, with the conclusion it forbids.
• A user who is not the founder has done the job.
• You agreed the help you would not give, and you kept to it.
• You watched what the user did after the alert, the reading or the click.
• Tooling and extra features are not added "to save a later spin" before the decision.
• The next spend depends on the record.

It can be, if the print does not hide the fact you must learn and a real user finishes the job with it. A print that cracks in the real environment is information. A print that only resembles the product in a photograph is a model, and a model can be the right tool for a form question without being an MVP. The manufacturing process is not what earns the name. The user and the decision do.

Enough that one enthusiastic person cannot be the entire result. In a single kitchen, several shifts and more than one closer will tell you more than a pile of friendly interviews about a render. There is no universal sample size hiding behind the word MVP. Write who you did not include, so a conclusion about a chain is not drawn from one pass and then defended as if the method required it.

You can be paid for the job if the buyer understands what is missing, and if the safety of that use is real rather than promised. You should not take money for a warranty, a certification mark, or a finish you have not built. A sale also creates an expectation of support. If you cannot support the unit, a paid trial with a written end is clearer than a product page. Clarity about the end is part of the product, not a legal afterthought you invent when the buyer calls.

A prototype can be internal. It can answer a question only an engineer is asking. An MVP has to answer a question about use, with the user present and your help withdrawn. You may need several prototypes before one honest MVP is possible. Calling every prototype an MVP makes a bench result look like demand, and it makes the word useless the one time you need it, which is when someone asks whether anybody did the job.

A BrahmEarth environmental product can use a printed shell in an MVP and still has to be reviewed as one assembly: enclosure, sensing window and electronics together. A handsome print that shadows the sensor, or a board that only behaves on a bench supply, does not test the job you wrote down. Keep that review even when a tool is correctly deferred. No yield, cost, time or test result is stated here.

Bring the job sentence, the list of stand-ins, and what the users did when you were not helping. BrahmWorks can say whether the next build is still an MVP, or whether you are now funding something that has to be repeated by other people.

Review the next stage with BrahmWorks