The hardware has a large number of 3D printed components as well as more traditional components such as aluminum extrusion frames.

The build process is, at the moment, not something you can just sit down and work through on a weekend. It's still very much in development so slow and steady does the trick if you don't want to have to undo and re-do work later.

There is no real standardization of naming or processes for hardware startups, but the Beta Kit is more what I would call at the "Alpha" stage. The hardware itself and bill of materials is more or less at a final Beta stage, but the kit process is still very much Alpha. Documentation is in progress but currently bottlenecked with the head designer because some elements of the build and assembly are non-intuitive or even counter-intuitive. Those who dive in and assemble everything based on the extremely detailed 3D models of the assemblies in the official repository do so at their own risk. It is possible to paint yourself somewhat into a corner, so the best option for those of us who can wait is to take it slow.

There are some lessons to be learned from the process so far, which can be applied to any Beta program:

Make sure intentions, scope, and expectations are clear for your Beta program. There is a difference between Early Adopter and Alpha/Beta Tester & Developer. You don't want someone buying too early, not fully understanding what they are getting into.

Fast is good, but Right The First Time is always better. If you have not personally made 100% sure of every last item going into your kits, it costs through the nose later in terms of following up on any component that was any mixture whatsoever of: not quite right, missing, or needs replacement. Then you need to sort out which is which, because since you're designing something new it's incredibly important to know whether a part is wrong or defective versus simply being shipped wrong. Then there is all the time and cost required on top of all of that to ship replacements. You can absolutely rely on your testers and developers to give you prompt and accurate feedback, but whenever possible you want people to be running into only one type of problem otherwise issues compound each other rapidly and the effort needed to sort it out and rectify things goes through the roof.

People will surprise you in good ways. This will often be unexpected. Think of it not just as collaboration paying off, but also as a sign that your project isn't doomed. It's good!