Understanding the expensive system before you buy it
The situation
Technical programs face a recurring decision: a vendor system costs more than the budget, and nobody on staff can evaluate whether the price reflects the engineering or the market. The useful move is not to build your own. It is to understand the mechanism well enough to have a real conversation — about price, about what the proprietary part actually is, and about whether a cheaper path exists. This doubles as a strong lab exercise, because the reasoning is the content.
Steps
-
Write what the thing has to do, in outcomes
Paper
Not a product category — the outcome and its tolerance. Hold a pass within this many centimetres across this many hectares. Keep a greenhouse within this range unattended overnight. Outcomes let you compare unlike options; a product name does not.
What you only learn by doing it: Include the tolerance number. Precision is most of the price in this category, and a loose requirement often has a far cheaper answer.
-
Ask how it works at component level
Anthropic-Claude for Education Perplexity Comet
Ask for the operating principle, the components, where the accuracy actually comes from, and which part is genuinely hard. You are looking for where the engineering difficulty sits, because that is what you are paying for.
What you only learn by doing it: Ask which single component the whole thing depends on. The answer usually explains the price, and sometimes reveals the vendor is reselling a commodity module with software around it.
-
Ask what the open and DIY paths look like, and name them
Ask for existing open-source projects, kit options and community builds by name, with maturity and support. Then verify each one exists and is maintained. Abandoned projects are presented with the same confidence as active ones.
What you only learn by doing it: Check the last commit date and whether anyone answers questions. A dead repository with good documentation is a trap that costs a semester.
-
Price all three paths honestly, including your time
Vendor, kit, and from scratch — with hardware, labour at a real rate, maintenance, spares, training and the risk of it being down when it matters. Put them in one table.
What you only learn by doing it: Put your own hours in at a real rate. Every build looks cheap when the labour is free, and that is precisely the error that leaves a program with equipment only one person can fix.
-
Decide, write it down, and name what would change your mind
A one-page memo for the file
Record the decision, the reasoning and the trigger that would reverse it. Then go talk to the vendor with the table in hand.
What you only learn by doing it: Buying the vendor system after this is a good outcome, not a wasted exercise. You now know what the premium buys, and you negotiate from a different position.
Where this breaks down
The model is systematically optimistic about building it yourself. It will give you a parts list and a plausible cost and leave out integration time, the failures you hit in week three, calibration, enclosure and weatherproofing, spares, and the person who maintains it after the enthusiast leaves. Assume the real cost is a large multiple of the estimate.
It also omits the things that often decide the question: certification, warranty, liability, insurance, vendor support and who answers at harvest when it fails. On a working operation those usually dominate the hardware price.
Student-built equipment on real production machinery is a safety and liability matter, not a class project. Anything that steers, lifts, carries current or moves under its own power goes nowhere near a working site without your institution’s risk office. Keep builds on a bench or a dedicated training rig.
Finish with the vendor conversation rather than skipping it. Arriving informed changes what they offer, including education pricing you will not be shown otherwise.
Provenance: adapted from Hiroki Tomiyasu, interviewed in OpenAI’s ChatGPT for Pros newsletter, 1 June 2026, who asked how RTK-GPS tractor auto-steer works before buying a proprietary system and concluded that a self-built version was feasible for a fraction of the price, which in his words “significantly expanded my available options.” He built greenhouse vent control the same way. The sequence, the checkpoints and the cautions below are our construction, written for a classroom. Treat the source as one practitioner’s documented experience in a vendor publication, not as evidence that this works generally.