Should Beginners Start With a Kit or Build From Scratch?

Start with a kit, not a from-scratch build, because a beginner cannot yet tell a software bug from a loose wire or a weak battery. A kit gives you a machine that already moves, so every later problem is one you introduced and can undo; build from scratch when the robot must do something no kit does, and pick your own software, ROS 2 or HORUS, sooner. The rest of this post is for someone with a budget, a free month and two browser tabs open, one on a kit listing and one on a parts list.

You have watched enough videos to want to build something, and now you are stuck at the first decision. One person says kits are toys that teach you nothing, that you will assemble somebody else's robot and learn nothing you can reuse. Another says a scratch build is how you actually understand a machine. A third posts a photo of a beautiful hand-built rover and does not mention the four months it took.

Meanwhile the parts list you have been assembling has grown to a page and a half, and you are not sure whether the motor driver you chose can even drive the motors you chose. You do not know whether the battery is right. You have found three different opinions on which single-board computer to use and each one comes with a warning about the other two.

What you actually want is for something to move, this month, so you can start on the part you were interested in: making a machine decide things. The worry underneath both tabs is the same. You are afraid of spending money on a dead end, and afraid of spending a season on wiring and never reaching the software at all.

Should beginners start with a kit or build from scratch?

Start with a kit for the first robot, and build from scratch for the second. The reason is not that scratch builds are too hard, it is that a beginner has no way to divide up a failure. When a hand-built robot drives in a lazy curve instead of a straight line, the cause could be your code, a motor that is weaker than its twin, a wheel that is not quite round, a battery drooping under load, or a connector making intermittent contact. An experienced builder narrows that list in minutes, having met all five before. A beginner has met none, and every hour spent guessing is an hour not spent learning anything that transfers. A kit collapses that list. The hardware came from somebody who already made it work, so when the robot curves, the code is the prime suspect and the code is the thing you are trying to learn. That is the entire argument, and it holds regardless of how good a programmer you are. The exception, which is real, is a robot that must do a specific physical thing no kit sells.

What is actually in a robot kit, and what is not?

A kit is a set of parts chosen to work together, plus instructions and usually some starter software, and what it is not is a finished robot. The parts are the boring, high-risk decisions someone has made for you: a chassis with mounting holes in sensible places, motors matched to a driver board matched to a battery, wheels that fit, connectors that mate, and a wiring diagram that has been followed successfully by a large number of people. That is the value, and it is larger than it looks on the listing page. What kits vary in enormously is the software. Some ship a closed application that makes the robot follow a line and offers you a slider, which teaches you nothing and cannot be extended. Some ship a small library in Python or C++ that reads the sensors and drives the motors and leaves everything above that to you, which is exactly what you want. Before you buy anything, find out which sort you are looking at, because the difference between them decides whether the kit is a starting point or a dead end.

What are your realistic options between a kit and a parts list?

You have six realistic starting points, and only two of them involve choosing components yourself. You can buy a complete educational kit and use the vendor's own software, which gets a machine moving in an evening and stops being interesting fairly quickly. You can buy a hobby chassis kit with a decent library and write all your own code on top, which is the sweet spot for most people. You can put ROS 2 on kit hardware, which is worth it when your project depends on mapping, navigation or a driver somebody else wrote, and costs you workspaces and vocabulary before the robot does anything new. You can put your own programs on kit hardware and connect them with something lighter: HORUS is an open-source real-time robotics middleware for Rust, Python and C++ where the three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised, which matters once a robot runs several programs at once and not before. You can build the whole thing from a parts list. Or you can start in a simulator and buy nothing at all.

How do those starting points compare?

The comparison that matters is what each option assumes you already know, because that decides whether your first month is spent learning or stuck. Nothing here is permanent; most builders pass through two or three of these rows in a year.

Which should you pick if you are teaching yourself with nobody to ask?

Buy a kit, and buy a popular one, because the community around a widely sold kit is the substitute for the colleague you do not have. When something goes wrong on a common platform, somebody has already asked your question in public and somebody else has answered it, and that is worth more than a slightly better motor. A scratch build has no such community: your combination of parts may be unique, and when the robot behaves strangely you are alone with it. Pick a kit that is still being sold, still has a maintained library, and has questions being asked about it recently rather than years ago. Then write your own code from the first day, even if the vendor supplies a working example, because typing somebody else's program teaches your fingers and not your head. Read their example, understand what each line is for, then close it and write your own version that does one thing. If it works, you have learned something. If it does not, you have a machine that is known to be sound and a bug that must be yours.

Does it change if you already have a Raspberry Pi and parts in a drawer?

Slightly, and the temptation is worth resisting for a first robot. A drawer of parts is a fine reason to build a small project — a sensor that reads a room and reports, a motor that turns when a button is pressed — and a poor reason to attempt a whole robot, because the parts in your drawer were not chosen to work together and you will spend your first month discovering that. The motor you have may need more current than the driver you have can supply. The battery may sag when the motors start, resetting the computer, which looks exactly like a software crash and will teach you nothing except despair. A single-board computer you already own is genuinely useful, because that is the one part a kit will happily let you supply. The pragmatic route is a chassis kit with motors, driver and wheels included, running on the computer you already have. You get known-good actuation, you get to reuse what you own, and you skip the failures that make beginners quit.

What should you buy if you have a month before a deadline?

Buy a complete kit with a documented library, and buy it today, because shipping time is the part of the schedule people forget. With a month, the risk is not that your robot is unambitious; it is that nothing moves until week three and you spend the last week debugging in a panic. A kit that arrives assembled or nearly assembled gives you a working machine within days and leaves three weeks for the part your deadline is actually about. Choose the version with the sensors already included, even if it costs more, because a sensor ordered separately arrives late and mounts badly. Then scope the software down hard: one behaviour, done well, beats three behaviours that half work. If the deadline is a class project or a demo, remember that a machine which reliably does one simple thing in front of an audience is more impressive than an ambitious one that needs three attempts. Save the scratch build for a term when a slipped week costs you nothing.

Does the answer change if you are already a strong programmer?

It changes less than you would like, and often the strong programmer has the worse first month. Software skill transfers to the software, and the failures that stop a first robot are mostly not software: a connector that works until the robot turns, a screw terminal that was never quite tight, a battery whose voltage droops under load, a sensor mounted where the chassis blocks half its view. None of those yield to good code, and confidence in one domain makes them harder to accept, because your instinct says the bug must be in the part you understand. What a strong programmer should do is buy the kit and be ambitious with the code: skip the vendor demo, write your own control from the start, and try the thing that made you want a robot. Your advantage is real, it just sits above the wiring rather than in it. Spend the saved time on behaviour, and treat the hardware as a solved problem you were kind enough to buy.

What do beginners usually buy first, and why does it end up in a drawer?

Beginners usually buy either a toy-grade kit with closed software or a pile of individual components, and both end up in a drawer for opposite reasons. The toy kit works immediately and then refuses to change: the app makes it follow a line, there is no way to write your own behaviour, and once you have watched it follow a line the machine has nothing left to give. The pile of components never works at all, because two of the parts do not match and there is no diagram that includes both. In each case the builder concludes that robotics is not for them, when the actual problem was the purchase. Avoid either extreme. What you want is hardware somebody has already proved works together, under software you are free to replace entirely. That combination fails in only one way, which is your own code, and your own code is the only failure that teaches you anything. Ask one question before you pay: can I write my own program and run it on this, in a language I know, without asking permission.

What do you give up by starting with a kit?

You give up learning how to choose parts, which is a genuine skill and one you will eventually need. Somebody else decided what motor could move that chassis, what current the driver had to supply, how long the battery would last and where the sensors should sit, and you learn none of that by unboxing their answer. You also give up physical freedom: the chassis is the shape it is, the mounting holes are where they are, and adding an arm or a different sensor means improvising. You may give up some quality, since kits are built to a price and the motors are usually the first thing cheapened. And you give up a little pride, if that matters to you. Notice that every one of those costs lands on the second robot rather than the first, and by then you will make those decisions from experience rather than from forum arguments. Buying your way past a problem is only a mistake when you never come back to it.

When is ROS 2 the better choice?

ROS 2 is the better choice as soon as your project depends on work other people have already done. If your robot must build a map of a room and drive to a point you pick, that is a ROS 2 project, because mapping and navigation packages represent years of effort nobody reproduces in evenings. If the depth camera you bought ships a ROS 2 driver and nothing else, that decides it. ROS 2 is also right if you are learning robotics to get a job or join a lab, because it is the shared language and being fluent in it is part of the qualification. HORUS is not the answer in any of those cases, and choosing it there means rebuilding plumbing you could have inherited. Be clear about the cost, though: ROS 2 asks a beginner to learn workspaces, build tooling, message definitions and launch files before the robot does anything it could not do before, and it is most comfortable on Linux. For a first kit robot that drives around a room, that is a large detour for no gain.

Is a kit just a toy that teaches you nothing?

No, and here is why: what a kit fixes is the part of a robot you were never going to learn from anyway on a first attempt, and what it leaves open is everything that matters. A chassis and a matched set of motors are a solved engineering problem; buying the solution is not cheating any more than buying a compiler is cheating. Everything above the wiring stays entirely yours — how the robot senses, what it decides, how the program is organised, how it handles a sensor that lies, what happens when it is wrong. That is the whole of robotics software, and no kit does it for you unless you let it. The kits that genuinely teach nothing are the ones with closed apps and no way in, which is a reason to choose carefully rather than a reason to avoid kits. There is a good post to read on projects that teach the software side before you buy, because the project you choose decides how much of a kit you actually use.

Will building from scratch teach you more?

Partly, but not the way you think. A scratch build teaches you an enormous amount about connectors, current draw, mechanical tolerance and the gap between a datasheet and a Tuesday afternoon, and every one of those lessons is worth having. What it does not teach faster is the thing most people came for, which is making a machine perceive and decide, because that work only starts once the robot moves and a scratch build delays that start by weeks or months. There is also a subtler cost. When you build everything yourself, you cannot trust any part of the machine, so every debugging session considers the whole stack at once, and that is exhausting in a way that drives people away from the hobby. The order that works for most people is to learn the software on hardware you can trust, then build hardware once you know what you are asking it to do. If neither tab appeals yet, learning robotics without buying a robot is a legitimate third route.

How do you decide between a kit and a scratch build?

Ask what you want to be doing in a month, and buy whichever option puts you there. If the answer is writing code that makes a machine behave, buy a kit, because that work begins the day the box arrives. If the answer is understanding how a machine is put together, and you are content that nothing may move for a while, build from parts and enjoy it for what it is. There is one more question worth asking honestly: does the robot you have in mind need a physical capability that no kit provides? A specific reach, a particular payload, an odd shape to fit somewhere. If it does, a scratch build is not a preference but a requirement, and the sensible move is to build the simple version from a kit first anyway, so that when you do build your own you already know what the software needs from the hardware.

• If this is your first robot -> a kit, because it removes every failure you cannot yet diagnose.
• If you want to write all the behaviour yourself -> a chassis kit with an open library, because the code stays yours.
• If your robot needs mapping, navigation or a specific driver -> ROS 2 on kit hardware, because those packages are the project.
• If no kit does the physical thing you need -> a scratch build, because this is the one case where it is not optional.
• If you have no budget or no space yet -> a simulator, because control and planning are learnable without hardware.

When two options stay close, weigh them on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, and licence — and take the one that loses on the fewest. Five plain questions about your situation rather than about the product. Later, when your robot grows past one program and the timing starts to matter — the point where latency, jitter and determinism stop being other people's words — star HORUS on GitHub so it is in your list when you start building.