The tools and tech I use to run a one-woman hardware company
blog.thea.codes
blog.thea.codes
[1] - https://twitter.com/micktwomey/status/1383527521744867338/ph...
I’d love to get back into synths but my bank account couldn’t handle delving back into that world these days.
Another good point, re HALs. She skipped the official HAL after finding it to be too much trouble. I've found that a good peripheral access library generated from SVD files is all you need, and is easier to work with than a HAL that's not carefully made. Ie an API that provides named register blocks, registers, and fields, and knows how many bits go in each, which you can read from etc. (Is this what the CMSIS lib she mentioned is?)
Related to the last point: "I write very small, usually project-specific, abstractions over that" - If you decide a popular or official HAL isn't helping you, you end up writing your own HAL!
> I've chosen to avoid using the Node.js ecosystem in favor of just plain JavaScript
Also a choice I agree with.
I'm curious how many teams are developing new projects using Rust, but staying away from the open source ecosystem.
The recent posts about Rust in Android shows a side of this. They are avoiding Cargo in favor of plugging in their own build system. Use the language for its benefits and avoid the ecosystem (partly).
It's on Github [1], and rather nice. Vendor's middleware can be of varying quality, so just using CMSIS seems refreshingly nice!
FYI, the About/FAQ/Pre-Order links at the top of your site are currently broken.
I’ve shipped out the first few units of my solo project a couple of weeks ago (a super niche tool for DJ's):
Feels good to follow through from a hobby project to an actual shipping product. Its been fun re-igniting all the things learnt during electronic engineering classes back in university.
What is an interesting contrast is that by day i'm a web/ios software engineer where memory and disk is largely plentiful, but by night i work on cramming TCP/IP + USB stacks and real-time audio decoding threads into less than 80KiB of RAM on a Cortex-M4 MCU.
Currently busy ramping up production of a small batch of units and adding checkout to the website.
>Feels good to follow through from a hobby project to an actual shipping product.
I'm currently in the hobby stage of a project. It's great to see people going from hobby to shipping.
I'm very new to the hardware world but sometimes it feels like you need a big team to do it.
Great product!
> We hear a tone of people doing it in the SaaS work, but not so much in hardware - if anybody here knows other similar examples, I'd love to hear about it!
Also would love to hear!
Decisions based on reality, limits, and resources. Despite all that, she's a remarkably capable person that makes it all work; regularly, and repeatably.
I've had to make those types of decisions all my adult life. It's how we ship.
An insight I feel many software projects could learn from, even in small to medium teams.
Every tool has overheads in learning, maintenance, edge cases, and interoperability. The more abstracted the less agency you have over the tool, and time savers become roadblocks. Keep it simple, fewest dependencies, and close to where you have the most agency.
Also very impressive. What an undertaking. I can see why someone like this would succeed - she seems exceptionally organized, knowledgeable, and competent.
I have dreams of getting into hardware sometimes, then people like this really temper that thought. I don’t have anywhere near the chops and brain power to pull something like this off.
So it looks like the Winterbloom module is taking a "pitch CV" input in the range of 0-6V... what would typically generate this input in this type of setup? And what do all those other modules on the rack do?
The rest of the modules do a number of things. In the actual patch (so, in use) you can see a Quadrax working as an envelope generator, a VCA, a pan mixer, a filter (in this case Mutable Instruments' Blades). It'd be hard to explain modular in a HN comment, but if this interesting to you and you don't want to spend a lot of money (modular is expensive), give VCVrack a look.
Does it means there are other people involved? Contractors maybe.
Edit:
Answered my own question. Design is indeed a one-woman job, but helped by one other woman (and two cats) for production.
And looking at the downvotes, it looks I was the only one confused. I was wondering about it for the repository aspect. Working alone is an entirely different experience compared to having even a single other person on the same codebase.
software ones i have collected:
- https://draculatheme.com/pro/journey
- https://www.indiehackers.com/post/launched-my-first-course-e...
- https://panelbear.com/blog/tech-stack/
- https://jake.nyc/words/tools-and-services-i-use-to-run-my-sa...
- https://www.listennotes.com/blog/the-boring-technology-behin...
I'm only part way through reading all of your linked articles, and so far they're absolutely great!
Just wanted to say thanks for collecting and sharing.
In a previous job, we used Arduino (environment+boards) to quickly spin up prototypes and testing new peripherals, then moved them over to bare metal (avr-gcc+Makefiles, custom PCB) for our production.
And if it's not too demanding a project, give this a go with AVR first, it's much simpler to move to bare metal than with ARM. Feel free to email with any questions.
Small nit, Makefiles are Turing complete. This of course does not negate the stated reasons for moving to Ninja -- despite being Turing complete Makefiles are frustrating at a certain level.
I love this: https://winterbloom.com/about
My HR department is twice the size of hers.
I too, am a one-person (gender difference) company, and there’s a ton of stuff I do that would not work with a team.
EDIT: I'm not sure why you ask that here though. Rust doesn't appear to be mentioned in this post.
> I write our firmware using C. While some might gasp at using such an "old" language, it turns out that the combination of my familiarity with C, the maturity of its resources and tooling, and the low-level nature of writing firmware means that C happens to be a joyful language for me to write firmware in.
Which has the flavor of defending the choice of C as if it weren't the standard choice.
For "embedded" linux grade CPUs, rust is starting to gain some practical traction. A few years ago the idea of writing application level glue code in it was still a bit silly, but these days it's starting to actually get linked into production systems. It all seems to be done in a way that's interoperable with existing C/C++ codebases, though.
It sounds like you have some experience in this and I have been curious for a long time why Rust can't or doesn't run on almost every micro-controller? Is it based on the compiler? I thought that because Rust has no runtime/produces a binary which does not require a runtime that as long as the Rust compiler emits the right backend instructions it should just work?
Adding to my confusing, I think rustc uses LLVM which is a way of separating a language's frontend from the backend code emitted, so I thought any micro-controller supported by LLVM would work for Rust.
What you're saying isn't wrong, it's just that... embedded development is incredibly diverse. LLVM doesn't support as many platforms as GCC does, and even once LLVM gets support for something, we need to do some work in Rust to get things working; support isn't automatic.
If you get to pick what your hardware is, Rust is fantastic. If you don't get to pick... it's a roll of the dice.
I didn’t know that Rust support for a LLVM target isn’t free and didn’t realize micro-controller targets are so diverse. Very cool.
Also, a lot of embedded code consists of peripheral drivers, and in rust that likely means "unsafe" code. At that point, it's a bit of a wash which language you work in. That's especially true since rust can interoperate with the C ABI.
I haven't familiarized myself with all of rust's built-in data structures yet, and I'm not sure how much stuff necessitates allocating on a heap under the hood. That would be a compelling reason to carefully consider its use in some embedded systems. That's analogous to C++, where it's typical to avoid most of the STL data structures.
You do need some unsafe, but not as much as you may assume at first.
Rust doesn't really have any complex built-in data structures, and doesn't require a heap at all. That's a standard library thing, which you wouldn't be using in this context.
Not really sure, though. I'm a mobile dev, and not an embedded dev :D
I'm working on a commercial firmware for ATSAMD21 using Rust, and have been finding it quite a nice experience. The tooling is great, PACs and HALs are at least as good as the last time I used the Atmel-provided ones, it's really nice being able to just add a line to Cargo.toml to bring in a library rather than cribbing from a prior project or writing my own.
That said, the Rust HAL for SAMD21 is certainly not complete; I'm working from a forked version of it, and have issued a few PRs to extend/fix it and other libraries. There are a few areas, DMA in particular, where the community hasn't quite decided on the right approach.
While you might find some C++ compilers, most vendors don't have linker scripts that work properly with C++ code, or libraries without issues.
I'm quite intrigued by Zig and am hoping to get in and play with it, since it aims to be a "better C" (not C++) so it remains a small language. See this recent post which triggered my curiosity: https://kevinlynagh.com/rust-zig/
(edit: more thoughts on Zig) I am intrigued because I want out of a new embedded programming language aligns perfectly with their approach. comptime instead of the C preprocessor, generics, any allocation is explicit (any memory allocation is at initialisation time), etc.
Amazing project and superb writing in any case.
Are there good beginner resources on working with kicad out there? I haven't really found much but maybe I'm just failing at my search terms because I'm not as familiar with the field as I should be.
Esp. really beginner "baby's first circuit board design" and also "making minor modifications to someone else's board".
https://youtube.com/playlist?list=PLy2022BX6EspFAKBCgRuEuzap...
yeah this was great starter material thanks :)
It is a TON of work to pull off what Thea is doing here, and then to execute it all with such exquisit marketing on top. I'm impressed and wish her all the best in this fun (but crowded) market.
I also don't see anything that is specific to a "one-woman" company vs "one-person". Not that there's anything wrong with that; the title is accurate. Just wanted to point out this is applicable to everyone regardless of gender.
I remember looing at the early acorn computers that where in eurorack modules - this is the one before the Acorn Atom
> exactly one engineer - me
followed by
> our current tech stack
This is something I struggle with when I'm writing about my own business or product. Sometimes "our" feels like the right thing to say but I know it's really just "me". She seems to have resolved this herself and uses "our" when speaking about the company, the technology, company philosophy, etc. It's kind of refreshing and she might have just helped me decide it's okay to say "our" as a solo maker.
1: https://joeldare.com/how-to-lose-money-with-25-years-of-fail...
For a technical writing, I would treat it like code, use the most accurate word possible, and here it is "me".
Even more confusing since by looking at the company website, there is more than one person involved. For example "When we use a third-party library, we pull its source directly into the firmware's source tree" implies that someone else has access to the repository when it doesn't seem to be the case.
We generally is understood to be - me + project/company because the person and the project are not the same thing. Code bases do not get updated to reflect me/we grammer as people come in and leave.
Also technically a company is an artificial person, even a single person project can be we.
A bit pedandic, but since we're talking about grammar anyway, that should probably be:
> there's one other person (a production assistant), and two cats.
As written, it sounds like the production assistant is separate from the person.
> there's one other person- a production assistant- and two cats.
> there's one other person—a production assistant—and two cats.
> there's one other person - a production assistant - and two cats.
Interesting, when I first read it I did understand that the production assistant was the person he was talking about. But yes, I can see why it could be confusing.
system("echo "Hello, World!"");
is incorrect - it mixes syntax in a ambiguous/incompatible way. It's a bit more amenable to silent autocorrect though, so YMMV.Ack about the string literal.
https://en.wikipedia.org/wiki/Apposition#Restrictive_versus_...
So the source of the confusion is that, in English, non-restrictive appositives typically are indicated with commas, but so are lists of conjuncts.
Of course you are the best judge of what English usage is ambiguous to you, but your suggestion of introducing a comma there is at odds with the convention that you can tell whether a noun following a conjunction is a subject (i e., starting a new independent clause) or an object (ie. the conjunction is bringing together two objects into one collection) by whether it follows a comma. I think your proposed cure is worse than the disease; personally I didn't find lvh's sentence at all difficult to parse.
Who started the company? Well, that would still be you and will never change, so use "me".
Who owns the tech stack? Right now it's "me" but after another hire it would be *us*.
So, no virtual functions, no memory allocations, no smart pointers, probably no exceptions. But, templates that earn their keep. The normal experience with C++ done well is no need for debugging. Debugging microcontroller code is a royal pain, so preventing whole orders of possible bugs is worth a lot.
You cannot possibly be saying this with a straight face :)
The title somehow implies that some of the choices are a consequence of the author's gender when they are in all likelihood purely technical.
Women should use "man" to refer to themselves in such instances. If it starts bothering "men" aka males, then the need to switch to "person" becomes more obvious.
A point to note, there are many languages where the term to express "one man" is gender neutral. Perhaps languages like English should rethink their usage of such language.
This implication reads as pure projection in your part. There is absolutely nothing else in the title or article to substantiate it. The author as a woman more likely just used the term as she is a woman and indeed the sole founder/worker of the company.
The simple fact that is in English language "man" is often used to apply to both sexes, the most common one being "Man"kind, another example being "Chairmanship".
A company being run by a single person is understood to be a "one-man" company even if it is run by a woman, because the emphasis is on the fact of being run by a single person rather than a single person of a particular sex.
PS. Have HN users become a downvote happy bunch in recent years, or is it just my imagination?
Assuming your volume is greater than a dozen pcs/month, you're doing both yourself and your international customers a massive disservice by not outsourcing fulfillment and logistics (at least for international buyers).
I went to order a single nut from your store, and the shipping to Australia was $35. Of course, this makes small purchases prohibitively expensive. But more than that, it shows that you don't care about your buyers from outside of the US, and conversely shouldn't expect them to care about you.
This especially matters if/when your products become cloned. Piracy is a service problem, and any markets you are not serving properly will be serviced by the copycats.
There is some kind of insane massive asymmetry in international shipping costs that really does make it prohibitive to ship anything out of the US.
However, if you've figured out how to do this well, I'd love to read more about it. Maybe another blog is in order. ;-) There are some things that are mysteries to me, such as what kind of inventory level is necessary to make everything run smoothly but without losing your shirt.
Anyway, I don't know how applicable 3PL is for products that are built to order, but for something mass produced it really is as simple as putting barcode stickers on them (I use a $50 desktop label printer for this) and then sending a box of them to a Chinese 3PL company (ChinaDivision etc.).
This can and should be done from day 1 (again, probably not for bespoke items unless volume is high!), and will cover basically every country on Earth except Iran and North Korea with cheap and reliable logistics. Loudly trumpet that shipping is free (or fixed cost) no matter the buyer's location, and you'll get a lot of goodwill from buyers in underserviced markets.
The next step from there is to set up an Amazon FBA presence in various markets worldwide. Even if you don't sell much inventory through their site, you can take advantage of Multi-Channel Fulfillment to send stock cheaply from a local warehouse. I pay something like US$50 a month to be a part of their logistics network, plus around US$5 per package for fulfillment and logistics regardless of location.
Regarding inventory levels, if possible I'd recommend always holding enough stock to cover 6 months' worth of baseline sales at all times. If your product relies on word of mouth for discovery, a feature on a site like Hackaday (and the ripple effect that causes) could easily cause 3-6 months' worth of sales in a week. I learned this the hard way last year.
Best of luck with your business, and if you want to have a chat about logistics feel free email admin at espotek dot com. It's something I really care about and it kills me to see so many people do it wrong.
This thread is about Eurorack products, and you happen to sell a pretty sweet looking low-cost oscilloscope
which you don't mention, because it is irrelevant to your super-helpful advice.
I don't think I've ever had someone complain about the extra shipping cost: I think they're used to it.