Hardware has a reputation for being hard for three reasons. First, it scales differently than software. It's far harder to design something you want to make a million of than something you want to make ten of. Second, it's harder to anticipate, test, and correct all the things that can go wrong on the user end. Some people will put batteries the wrong way, some will drop the device on the ground, some will connect it to some vintage equipment you have never seen in your life, etc. And third, there are just more failure modes in an unfamiliar domain - sometimes, your code will intermittently crash not because you have a software bug, but because you put the decoupling capacitor too far from the chip. Or, just as you finish your design, the chip you designed it around becomes obsolete, or impossible to find because a factory in Indonesia is on fire.
Another complication is that at least in theory, if you're selling electronics, there are actual regulations and third-party testing that needs to happen, and if you fail emissions, you might have to redo your design from scratch. Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB".
So, I'm happy for the author, but I think he had an outlier experience. When you look at Kickstarter stories, people repeatedly stumble over this. Manufacturing / cost difficulties, supplier issues, reliability issues, etc.
yeah, and looking at their board I see they use one of "ESP32-WROOM" modules, which has the wifi & blutooth & antennae (pre-certified by Espressif for FCC, CE so itself doesn't need testing) & flash & processor (which even has its own RC oscillator), which takes care of a whole ton of difficult stuff so all the designer needs to do is plop that module down and power it up and wire some SPI/I2C peripherals which I'm guessing don't need super fast clocks or electrical constraints. Without something like those ESP32 modules, this would be much more difficult.
The pre certified module do not exempt the product from testing. It only means that you don’t have to do the conducted testing and that it’s a higher probability for passing the other tests. There are still lots of chances to fuck up and a full radiated test of the product is required.
In the EU (and UK with UKCA), CE certification is down to whoever makes the product available on the market. There's no get out for pre-certified modules. If you put a pre-certified module in a box and sell it, you have to be responsible for the CE mark.
You need evidence that the whole product complies with the EMC regulations. There's some judgement involved - if you put a certified circuit board in a plastic box, it won't change the EMC behaviour so you don't need to re-test. But if you solder a module onto a larger circuit board, you are almost certainly changing the EMC behaviour. You should definitely be re-testing something like that.
The pre-certified module does save you some time in the "intentional radiator" testing - assuming you use the same antenna it was tested with as a module, you can probably make the case that the behaviour is the same.
Will anyone ever notice or care for a few thousand niche devices? I doubt it. But to sell in the EU legally you do need to do that testing.
No, you actually don't have to do the testing, except in some special circumstances (e.g. childrens' toys). Generally, the "CE" mark is a self-certification done by the manufacturer or importer that certifies that the product meets certain (category-specific) criteria. You can do the proper thing, test your product and then certify it. But it is also possible and usually legal to just issue the certificate based on a self-assessment and deal with the fallout later, if there ever is any. That's how basically all non-EU manufacturers and importers get their CE mark...
Im not an expert in emissions testing but pretty sure it still needs CE certification testing. The module shouldnt cause any problems providing that the firmware for the transmitter is configured properly, and is placed sanely in the enclosure, but the entire product must still undergo the relevant testing for 2.4GHz emitters.
Just because you use a certified module doesn't give you a free pass.
> but the entire product must still undergo the relevant testing for 2.4GHz emitters.
To be fair, it's unintentional radiator testing that's required, rather than everything the module had to go through as an intentional radiator. So, it is a "free pass" for nearly all of it, and a much cheaper one, since you don't have to use a costly FCC accredited lab.
The ESP32-S3-WROOM1 module is FCC certified for its own Wifi and Bluetooth emissions when used by itself.
And, well -- that's certainly good.
But the FCC rules cover more than just Wifi and BT, and the whole rest of the widget also needs to comply with them. Of particular interest is FCC Part 15 Subpart B, which covers unintentional radiators. The device would need to comply with Part 15 Subpart B even if it had nothing to do with Wifi or BT.
Putting one part that is certified for one issue into a device doesn't extend a magical blanket of compliance to everything else that the whole of the widget contains.
Does the SPI or I2C bus (or anything else) leak RF beyond allowable limits? Eh, who knows. I certainly don't know. It's easy to say words like "it should be fine," but without testing then nobody actually knows.
The CE mark, meanwhile: That mark means exactly nothing in the US, where the author is located and the devices are sold from. The United States has zero regulatory recognition of any of the processes and/or tests that CE may cover. People often confuse this issue, wherein: They don't think it be like it is, but it do.
Of course there’s no actual official ‘china export’ mark and that is just what some Chinese factories were claiming when they were caught slapping a (accidentally mis-spaced) CE conformance mark on their products! The EC made a statement on this back in 2008 [1] so everyone knows what game they are playing.
> Without something like those ESP32 modules, this would be much more difficult.
I don't disagree. It's important for us to recognize that we stand on the shoulders of giants, but I also think it's a little silly of a critique of someone happy about it being easier than he expected. It's true that hardware would be much harder if you had to do it all yourself, but is that meaningful? The wonders if the modern supply chain is that you don't need to do it all yourself.
Well the title and premise is a bit silly. If you're designing easy hardware by wiring parts together that already do all the hard stuff, then "hardware is not so hard" is something you might conclude, but that only applies for designing easy hardware like this. But if you are doing anything that pushes the limits or involves analog signals and having to worry about signal integrity and EMI and impedances and Laplace transfer functions all that other stuff that requires degrees, then "hardware is hard".
>your JS is too big, you can't ship until you get it under 50 kB
Back in the glorious past, the iOS App Store either didn’t allow apps larger than 100 MiB, or at least forbade them from being downloaded over mobile connections. There’s an old blog post/Twitter thread you can find on Hacker News where an Uber engineer describes the challenges they faced in trying to keep their app under that limit. They were also rewriting the app in Swift, so some compiler patches were necessary.
There isn’t all that much actual first-party code in these apps, but if they made a “Hello World” but kept the same third party library deps, they’d be starting at 300MB, and once they add all the visual assets that’s another 200MB… I have a ton of apps on my phone that are absurdly large. Like Gmail is 706MB. The Gmail app for iPhone could not fit on a CD-ROM. A plain mail client. Compared to that, Facebook at 461MB is looking quite slim.
I don't want to justify the space too much, but things like the Uber app are kind of amazing.
While the base functionality is fairly simple in terms of find location > send car + all the courier and different varieties of what they do. It manages do that while working in 70+ countries over 15,000 cities with multiple different languages and payment vendors and it is all done via a single application.
That is pretty neat.
Yes, it is still very bloated but it does a lot more than what it initially looks like.
But yes, I am endless impressed when you come across a binary that is tiny. Like a text editor that is 14KB, sure it is simply but it doesn't need to be anything more for most people.
>It manages do that while working in 70+ countries over 15,000 cities with multiple different languages and payment vendors and it is all done via a single application.
I'd assume almost all of that is done server side though. Most likely the app is mostly just a wrapped website with some gps and notification code on top.
And as someone who works on platform that makes use of numerous payment portals depending on the product and region you're buying in. It's all just wrapped up in logic AKA if statements.
now App Store doesn't prohibit it, but it still asks you if you'd like to download an app that weights more than X mb or wait for a wifi connection to do so.
Yeah, I think a lot of the "hardness" of hardware is of a different flavor than software. The author mentions how many lines of code are in the software, but that really is more of a symptom of something that makes software "easier": you have way more flexibility to iterate, and try new things, at a relatively low risk and cost, even if it's embedded software (at least for non-critical applications). Hardware is just more unforgiving. There's no cheap way out of the kind of scenarios you mention.
Maybe this isn't special in the era of pre-funding but there's also over manufacturing. You have to guess how many you'll sell. If under guess you leave sales on the table. If you over guess you lose money to all your undersold but already paid for inventory.
Not this exact thing, but I make a hardware product akin to a guitar pedal. I designed around a component type that the semiconductor industry was phasing out. One day I noticed that the list of alternative parts at my distributor included many that were marked "obsolete." I panicked and bought the entire stock of the part number that I use.
At this point I have the only stock of this part in the world, and it's more than a lifetime supply, but otherwise I'd have been faced with a re-design and limited options.
For another of my products, during the pandemic, the part I was using became unavailable, and I had to re-design my board to accommodate a part of the same type in a different package. Then I couldn't buy either part, but found an odd lot at a Texas Instruments factory in China, which I bought.
Dealing with shortage and obsolescence issues is a constant battle. There have been crises in the industry caused by plants catching on fire.
One thing I've always said that with products, especially when they're parts. They should be required to be made "open" as soon as you stop making and/or selling them.
They're making you nothing, they're going to vanish into the nether if the documentation is lost....
Not literally, but I had two projects I had to fundamentally redesign due to multi-year chip shortages in the COVID years. And we're not talking about any fancy chips.
A power converter I designed 3 years ago needs redesigning because the company that made the transistors was bought out and all their packages were phased out. And they were some fucking good packages that allowed for very good cooling and very easy parallelling of transistors using both sides of the PCB.
Then something has to be said about digital/discrete hardware, which is not dissimilar to programming, and then the alien (to software devs) world of analog chips.
Shipping physical products can open you up to more fraud, because once it’s in the mail, it’s in the mail. The customer can say it never arrived or claim their card was fraudulently used in order to keep using the product for free. Whereas with a SaaS you just disable their access.
And also logistics is a race to the bottom, everyone is competing to get more and more packages through the system, and the customers are demanding lower and lower prices.
So there's a fair amount of stuff that just doesn't make it there, there's a whole business now on re-selling non-delivered packages.
And with that also comes the services, the reason they leave it at the door, or in the bin, or yeet it onto the roof. Is because there's no profit margin anymore for the delivery person to wait 30s each time for someone to answer.
>your JS is too big, you can't ship until you get it under 50 kB
Not only that but every single update you push requires paying $$$$$ to get certified. It is freeing that the cost of releasing a fix or improvement to a product is $0.
In the past I considered selling a custom adapter to hobbyists, but all the certification costs just did not make it a viable option to pursue. I didn't want to up front thousands of dollars to make like $100 if I was lucky.
>But for me the take away still is: “hardware is as hard as you make it”.
I dislike this statement. Hardware is as hard as the product dictates it needs to be. A 25 component PCBA and a clamshell of 2 injection molded parts is about as simple of a product as you can make. Heck, most people would just buy an off the shelf clamshell for that type of product.
That doesn't work for the vast majority of products, building a product with 20 COTS parts plus 60 custom tooled parts, and 4 complex PCBAs is what is hard. Getting everything to fit together, pass testing, arrive on time from dozens of suppliers, etc. it where the complexity comes in. Then consider that hardware is cash intensive, you need to pay ahead of time for all the tools, you need to pay to buy the individual parts and warehouse them somewhere while you build the products you hope are going to sell. If something goes wrong there, then your expensive parts are just sitting there waiting for replacement components before you can ship. Then even when you ship, that revenue goes into buying the next round of parts you are going to receive in 3 months. This is where many hardware projects fail as they run out of cash before the project breaks even.
This. A decade ago, during my summer internship in the first year of college, I got put on a hardware project, basically designing a remote monitoring device for a telco.
I wrote the software, and my friend designed the PCB for the digital side. Basically I had to be a decent C programmer, and read the datasheet for the MCU we were using (which was way more work than using something like an ESP, but still). My friend had to lay stuff out on the PCB and place secondary components according to various application notes.
Overall not simple, but not rocket science.
On the other hand, the guys doing the analog daughterboard were industry veterans with decades of experience. They had a million concerns, from signal integrity, to voltage protection, back-EMF, etc. I was not even near the ballpark of that skill level.
Later on, I worked on more complex HW projects, stuff with FPGAs, DRAM integration and 8 layer PCBs, where you had to run full electromagnetic simulations because when you run at 1+ GHz, suddenly signal propagation is not instant, and traces behave like antennas.
I also did software there (a smaller slice of it this time), but there was an army of engineers working on the whole project which took a year, and not a second of it was spent in vain.
I agree with everything you're saying, but if you consider that this is a single-person company, the "hardware is as hard as you make it" statement makes sense. He saw a need, found out that it would be feasible to make a product to fill that need with very simple hardware, and chose to make the product. If solving the problem would've required hardware outside beyond their budget or skill level to make then presumably they wouldn't have pursued the whole project. Which I guess is sort of the point, but of course the title of the blog post doesn't really convey that.
Very happy JamCorder customer here. I've started playing in improv shows since I bought it too, and it's nice to have those on record!
It's rare that I come across a product I have literally zero complaints about, or any feedback to offer. Even my concern that it was tied to an app that might disappear one day is of course covered by the fact that it's all just MIDI files on a card.
Thank you so much for making this, it's basically a perfect product for me and I love it. No notes.
>Even my concern that it was tied to an app that might disappear one day is of course covered by the fact that it's all just MIDI files on a card.
I was sorta surprised when the blog mentioned it was like 200k lines of code for an app. I wouldn't think you'd even need an app for something that puts midi files on an sd card.
Yes the anti-counterfeit is primarily app enforced (though entirely offline). I do use the firmware encryption features of the ESP32-S3, whatever that is worth, and the firmware is tied to the HSM.
I think that highlights one of the reasons why, in this case, hardware has not been hard. (besides the fact that you are very clever)
The value you have created is actually more in the App than in the hardware.
As a maker of small devices (mostly open source) including MIDI - and putting aside commercial aspects like injection molding - I could recreate the hardware side of this project without much issue. The necessary components are likely already in this room with me. (I won't - I'm not in the business of copying things that people don't want copied)
But I'm not a software engineer, and therefore could not produce software of the scope and quality that you have, which is where the unique functionality of your device sits high above the relatively simple "receive MIDI data from MIDI devices" principle of the hardware by itself.
Are we talking about the app operationally day-to-day, or the app vis a vis the way it helps end users flash encrypted firmware images OTA to the ESP32 (like Chip alludes to in gp comment)?
If there are no more app updates, presumably there are no more firmware updates either, so the flashing part probably doesn’t matter (and you can probably flash the last published image to an authentic device by other ESP32-y means if you really need to).
As to the day-to-day: Pretty sure the hardware still records regular ol’ MIDI files to the SD card. The app seems incredibly well-thought-out and ergonomic but, at the end of the day, nonessential to the device’s core function.
Somebody could presumably build and sell their own “MIDI Recorder Loop Nonstop Device Digital Piano Upgraded New 100%,” but it wouldn't be a Jamcorder, you couldn’t flash Jamcorder firmware updates to it just by slapping an ESP32 in a case, and the official Jamcorder companion app would not talk to it. Which… fair enough, right?
For that matter it wouldn’t surprise me if somebody could write their own client for the real Jamcorder, if they felt so inclined… but with the official stack so absolutely perfect from a design perspective, why would they?
But even things like SDCards move on, we've already seen that with SDHC. I've had EOL kit in the past that just doesn't support it because it's that old, and thus EOL and doesn't support that standard.
Oh good, you're not pulling a Cricut where the app interactively proves to the cutter that it has an AES key and then encrypts all the G-code with it before transmitting over Bluetooth.
Congrats on an impressive achievement and milestone. This is a great outcome, great work, and an indication of how far the hardware industry/tooling has come.
This feels though a little to me like building a simple SaaS service, and deploying it on a managed cloud service, and concluding all software is really easy!
This project is near to (if not at) the easy end of the hardware product difficulty/complexity spectrum. Some great choices were made to keep it simple and therefor easy.
An alternate take-away: "If you keep things simple, hardware doesn't have to be as hard"
That underrates the difficulty in keeping things simple.
It is mentioned elsewhere here that a lot of time was burned on unused firmware features. It takes surprising discipline to cut stuff and still deliver.
Agreed. At someone who works primarily in hardware, it is definitely hard. A midi-to-bluetooth recorder is practically a software project in a fancy box. There is very little physical complexity to deal with here, which is what makes hardware difficult- the interaction between firmware and the "real world".
Congrats though, making a half-million a year business is a massive accomplishment! The headline just irked me a bit, haha (but, it got my attention, so I guess you win there)
Hey man, you made a successful product, wrote a great article, and are now getting attention for it. You don't need to respond to every person who wants to nit pick at your title :)
I think there's a lot of people talking past each other here. Sourcing parts internationally, preventing counterfeiting, slow iteration time, inventory management...all this logistical stuff is hard enough that the conventional wisdom in the software business world is to never attempt it. You're here presenting a counterexample and that's wonderful. The people criticizing aren't talking about this though, they are talking about whether logging digital inputs on an esp32 counts as a real hardware project and they act as if you've insulted their expertise in [signal processing/antenna design/insert specialty here]. You didn't do that, most of us know you didn't do that, but the word "easy" sets a lot of engineers off.
Just ignore the noise and keep writing great articles. My personal request, if I may - I'd like to hear how you did injection molding since I always assumed that was out of reach for small business.
Not super low. It starts to make sense around 1000 units. I’ve gotten runs of 2500 done domestically. But it is pretty hard to find domestic injection molders for consumer work - they will give you an FU quote at best because they cater to high volumes and industrial customers.
And they’ll make the molds in China anyway. Chinese molders are hungry — they will work with low volumes and offer a bunch of integrated services. But if you don’t know what you’re doing you will end up with bad parts over schedule.
Easiest way to get started is to use ProtoLabs. They charge lower prices on molds in exchange for higher part cost, are way faster than China, and have way better customer service.
I'm curious to hear more about your anti-counterfeit strategies beyond just enabling encryption. I'm curious if you feel like anti-counterfeit and open source firmware are mutually exclusive. I made the choice to embrace an open firmware approach on my project while keeping the hardware closed, while knowing that if someone tries hard enough they can completely reverse engineer if they put their mind to it. Desoldering caps and x-raying PCB layers etc.
I'm also very curious to hear more about your adventure in injection molding. What starting resources do you recommend, how much did it cost? Would you do it the same way today, or have the recent innovations in 3D printing forms for injection molding present superior paths?
Finally, I'd love to hear about your certification process. What certs did you get, how much did it cost, what were the gotchas?
You don't need an X-ray for a board this simple. Every component has well defined input and outputs. Give a mildly competent freshman EE student or high quality high school student you could have the board recreated in a few days.
Low product quantity and low quality/fake products resold on amazon from AliExpress are the biggest roadblocks at this point. The juice isn't worth the squeeze.
Wow, congrats, I remember reading your HN post. I hope you will continue writing blog posts on your journey, I expect quite a lot of software engineers would be very interested going though a similar journey now that LLMs removed most of the fun of programming. It’s neat to work on something physical for a change
> now that LLMs removed most of the fun of programming
Never understood this, was the "most of the fun of programming" the literal typing for you? For me it was about solving problems and building things, and I get to do that more now than before, and without all the literal typing.
I reject the idea that programming is „just typing“, so we are very unlikely to understand each others. Writing the code and thinking about the exact logic you want to apply and all its implications are part of the same problem solving process in my mind. You can for sure plan things at a different layer of abstraction but putting things together in code is a very satisfying and IMHO is the actual building part of the job. It’s full of decision making and thinking.
LLMs move me away from the implementation, which is more a managerial role, something I personally have zero interest in.
> I reject the idea that programming is „just typing“, so we are very unlikely to understand each others.
I'm sorry if I gave the impression I think programming is just typing. For me "programming" is the whole activity of creating software with code, you can do programming without the literal action of typing.
> Writing the code and thinking about the exact logic you want to apply and all its implications are part of the same problem solving process in my mind.
That's really interesting perspective to me, as these two activities for me are two completely things, and "thinking about the exact logic" happens way before I actually write any code at all, sometimes weeks/months even.
> putting things together in code is a very satisfying and IMHO is the actual building part of the job.
I agree that it's satisfying, but I guess "putting things together in code" still for me is more about being able to mash two concepts together in an elegant way, and none of that actually requires actual typing still.
> LLMs move me away from the implementation, which is more a managerial role, something I personally have zero interest in.
This is also interesting, because it feels like LLMs give me the opportunity to do more implementation, and not get stuck in the minutia so much, but rather focus on how the design and architecture actually fits together. Refactoring no longer is "I want to but also I don't want to spend the time nor get stuck in more rabbit-holes", so being able to focus on architecture/design more feels like it lets me care more about the implementation than before.
It's not bothersome, I'm not bothered by it at all, everyone gets (in my mind) to do things that makes sense to them. When I write comments here disagreeing with others, it's more from a "Please explain further your perspective so I can understand it, which hopefully I trigger by challenging it" view than anything else, not "You should do as I am doing things".
> Maybe they just like doing it the old fashioned way. You can both exist.
Completely fair if that is the perspective, just to re-iterate, I'm not trying to convince anyone of anything, only to understand other perspectives better.
Maybe you haven't fully explored coding with AI, yes a lot of people will say "Make me a pretty website with user accounts" and have a working poc they'll use as finished product.
But there's so much more you can do with programming knowledge to restrict and control AI to build it exactly how you want it without having to write thousands of lines of scaffolding yourself
Rather than "managerial" I tend to view it as more "professorial". Maybe it's my academic training (but I got out before I became a professor), but I tend to like to think about my problems in terms of abstractions and invariants and common ways to represent things. I just now describe them in English rather than code. But I do find that LLMs do a much better job the more clearly and completely I express what's in my head. I get that same satisfaction that you mention, but now it's when the LLM does what I want on the first try rather than fighting with it all day.
In the past when my junior engineers were fighting with a bug all week, I always told them the dopamine hit of solving the bug is what keeps you coming back to work for 20 years. Half joking, but the dopamine hit of from the satisfaction getting complex working software in a weekend is like crack to me, we'll see how that plays out long term :)
Did solutions to problems just pop into your head when you were programming before LLMs? Did you not pause and think about the code you were writing before?
Most of the time by the time I reach the problem, the solution already been thought of, yeah. The literal typing and editing was behind compared to where my mind wanted to go I suppose. But also I spend long time considering the design/architecture before even attempting to write the code, so most of the time when I was literally typing code I'd know pretty much how it should be. Unknowns-unknowns being explored as separate prototypes before solidifying on any design choices, and so on.
I think you just have a much narrower definition of programming. Others seem to be including the "long time considering the design/architecture before even attempting to write the code" in the programming, while you are only counting the time spent at the computer. You both agree much more thinking time than typing time is involved, just not that thinking about programming counts as programming.
Literally typing is definitely part of the fun for me. I’m a mechanical keyboard nerd though so that might explain a lot.
Beyond the typing though, I find enjoyment in perfecting the structure of the code, thinking deeply about how the pieces fit together. I enjoy the process of iteratively refining the code so that it clearly represents the program using the optimal level of abstraction and minimizes superfluous code/syntax. I find that using an LLM eliminates all of this and produces code that lacks all of the elegance and readability that I aspire to in my own code.
> Never understood this, was the "most of the fun of programming" the literal typing for you? For me it was about solving problems and building things, and I get to do that more now than before, and without all the literal typing.
Your take is so reductionist it's hard to believe you actually like to solve problems.
> For me it was about solving problems and building things, and I get to do that more now than before, and without all the literal typing.
The problem at least I have is... when something goes wrong, often enough even you as the original author / LLM slave-driver have no idea what is going on where, and completely forget trying to dig into someone else's pile of vibe-coded garbage. For every single problem you now are completely beholden to the AI agent.
Thinking while typing? Can you just keep generate code at typing speed? I spend a lot more time thinking than typing, and my most productive days are usually when I throw out a heap of code and replace it with a few highly factored functions.
While I'm typing, I'm not just thinking about which keys to hit. I'm thinking about how I'm using a function and what the inputs and outputs are. I'm debugging in my head, I may realize the code isn't going to do what I thought it would. Or I'm realizing that what I'm doing isn't going to scale and that I need a more rigorous approach. Often, I'm thinking "wow I'm going to have to type this same block a bunch of times, I should make a new method/function to handle this."
With code, I'm not planning everything down to the finest detail before I start writing. I know what I ultimately want my code to do but there are many unknowns I hadn't considered. Coding with an LLM is different depending on how you use it. When I'm using code completion, that's usually just helping me prevent syntax errors or to write an efficient snippet of code without having to check docs. But when I tell Claude "I want a web app that does xyz" and it creates it whole-cloth, that takes away the challenge of learning something new and building. I'm not a web developer and anything I could create is going to take me a long time to make (and it probably won't work well or look good) but Claude cranks it out with ease. I get to play software project manager and let the expert do the technical work. It's kinda fun being able to quickly get resulrs. Rather than debugging individual lines of code and thinking about the best way to implement code, I get to test features and think about better ways for the overall system to operate.
> quite a lot of software engineers would be very interested going though a similar journey now that LLMs removed most of the fun of programming.
I suspect we will see a reversal on this. LLMs are flat out worse than humans at programming (yes, even your latest favorite frontier model). I am faster (once you factor in the time fixing its inevitable mistakes) and better at programming than Claude is, and I'm not a particularly exceptional programmer. People say "they aren't going away", but I disagree with that - already we've seen people disenchanted with the lack of results compared to what they pay, and that is only going to grow once the AI companies raise prices in an attempt to turn a profit rather than lock people in. Eventually the industry will wake up and stop drinking the kool-aid, and what matters will once again be the results you deliver, not the tools by which you deliver them. But it's hard to say when that will happen, and it's going to be rough in the meantime.
Are you still below any significant scale thresholds and are there any you dread crossing?
I ask this because I tend to find things are simple until they are not. e.g. it's easy to write an e-commerce platform until you have to deal with shipping, duty, tax, tax on shipping, etc., for multiple countries.
There are scale thresholds I am aware of in hardware that I have not yet run up against. For example I am using Free software, but I am aware that with commercial CAD you can cross over price tier thresholds. Or for another example there are sales quantities where with electronics you might end up needing compliance testing, consumer safety testing etc.
Which ones haven't you crossed yet that you expect to have to navigate?
I make a physical product, akin to a guitar pedal. Possibly the most scary threshold would be if I'm successful enough that I need to quit my day job, but not successful enough for the business to support my family. That's kind of a no mans land where I don't want to be.
Another similar threshold would be having to hire people, which changes the complexity of the business in a variety of ways.
Having too many orders is a good problem to have (unless it gets cloned). Worst case, you pay an external contractor to sort compliance/fulfillment/whatever.
I guess, though I am not sure that this truly is the worst case, if some new compliance thing required a redesign or worse.
You hear about firms that go over certain thresholds, get noticed and then find out that their production facility is no longer "small" or exempt for example.
Some amount of defensiveness in planning and design can mitigate but I'm interested to know if there are thresholds I didn't know about.
How did you navigate the world of compliance testing and certification, with all the different countries involved (FCC, UL, etc). Are there any markets you've decided not to sell to as they're not worth the paperwork?
I chose to do FCC only and CE self-certify. If you use pre-certified radios it's not as expensive as you think. $5K should be plenty if you ask around. Just make sure you design your board so you actually pass, and don't let the labs over-sell you. They'll try to!
99.99% of cheap Chinese products you buy on Amazon don't actually have this testing done at all. So by doing any testing you're already way above them.
You can’t self certify any products including a radio (almost everything today due to WiFi and BLE), products for children or medical equipment. An accredited lab is required.
> 99.99% of cheap Chinese products you buy on Amazon don't actually have this testing done at all. So by doing any testing you're already way above them.
Yeah, but those Chinese dropshippers don't have significant local presence. If they are caught doing shady stuff they'll just let their $100 letterbox company go bankrupt and start over.
You, on the other hand, would actually have to pay whatever fines some regulator charges you with, because you are physically present in a jurisdiction they can apply power to. This makes self-certification a bit of a footgun: you essentially pinky promise that you fully understood all the relevant rules and regulations, and otherwise pay what in the worst case might be a hundred-thousand-euro fine. Quite a bit of a gamble!
The main saving grace is of course that the authorities are way too busy to investigate some random guy selling a handful of devices from his kitchen. But get too successful, and some competitor might just decide to give them a little hint on exactly what part you missed because you didn't even know you had to comply with it.
Hardware isn’t hard if the hardware is easy? There’s very few components, one of which is a pre made module, and it took 3 years to make essentially a text logger.
And the RF is a pre-certified module. Of course hardware is easy when you've offloaded the hard part to the supplier. Not to mention, a three year turn around? For this? Three months, six max with mistakes and reworks would be industry expectations "pre-LLMs". Everything is easy when you have 6x to 12x the timescale your competitors expect.
"Do things that don't scale!" is standard founder advice for a reason. The fact that no one else has put in the work means you get to sell $150 MIDI recorders... for a while. Which, fair enough, might just sustain a one-person business.
Seriously, microSD cards are the second worst hardware component to have to deal with (first being labels). For being a "standard" you end up with cards that are subtly but significantly different from each other, the slots are ALL poorly designed, and microSD cards are just inherently unreliable. Plus with the current flash shortage, the major manufacturers don't care at all to support any issues with the product.
The number that stuck out was 200K lines of code. Can you expand on why so much code had to be written and which parts were the longest (time and/or code) and hardest bits?
The app is about 85K lines: device connectivity, first-time setup, syncing, MIDI playback and visualization, library management, audio/video export, and OTA workflows.
The firmware is about 110K lines: MIDI recording + streaming, USB, Bluetooth, Wi-Fi, web APIs, storage, OTA updates, diagnostics, security, peripherals, provisioning, and an embedded web interface.
There’s a lot required to make a full-featured product.
From the photo in the link it looks like he's using an esp32-s3.
I suspect that 110k number might include the ESP-IDF libraries as well as his own code.
I've written a fairly feature-complete handheld device based on the esp32-s2 and the codebase is about 9k sloc of the C I've written, but that number explodes to almost 40k sloc if I include the esp-idf's imported libraries.
I recognize the "esp32 perched on top of a circuit board" from the picture. I've got a couple of those at my house right now, I'm on the second version of one board and the third of another. I think I'm going down a very similar road for a different product. Would you be willing to some paid advising? I'm an EE so I don't need hand-holding on the actual boards or programming, really just looking for more information on everything else around the edges. Either way, thanks for the article. It was nice to get some validation of my development process.
Interested. I got far emough on the site to have a couple of questions. (Maybe the answers are on the site?)
1) Does device record ALL MIDI sent to it? (Including e.g. SYSEX and non-registered parameters?
2) I edit MIDI on a Desktop (NOT a phone).
a) Are sessions recorded into separate files? Named and/or dated?
b) Can I inspect & load sessions from the card?
>>> Have a strong anti-counterfeit strategy. Don’t overlook this.
Can you expand? What counterfeits do you see (literally someone selling boxes labelled jamcorder? How do you handle that? Lots of scanning amazon and sending cease desist letter?
Congrats! Happy for your success. Your mix of ingredients is impressive (the hardware alone is probably simple). Your product idea came from actual personal need (validation!), and you are able to tie the hardware to your software to widen the moat -- which is great.
Your anti-counterfeiting tech hopefully / probably prevents your Chinese manufacturers / suppliers / related entities from free-riding on your work. (If your volumes start hitting say 50K+, things may change, you may be entering dangerous territory then, so I'd suggest you spend some time on beefing up the moat).
I think "hardware is as hard as you make it" would've been a better title. The author made the smart decision of keeping things very simple on the hardware side, and that happened to be possible for the kind of product he wanted to make.
Interestingly I've heard a very similar story and sentiment about hardware vs software from another single-person maker (also a software engineer by trade) of a hardware product, also in the music space. And this one was comparatively a more complex product on the hardware side, and did face some supply challenges during covid and tariffs, forcing at least one redesign and price raise. But in both cases, I'd say they made smart choices about keeping the hardware simple. By not pushing the envelope on that front they gave themselves the freedom to invest a lot of time and effort into the software. But not every hardware product is like that (which the author also does acknowledge).
Hardware is hard! Because of certifications and organizations like the WEEE. There are many different acts for electronic devices world wide. In Germany you have to spend about $ 20k per month even if you did not ship any product yet - just for regulations, certificates and things you have to register for to be able to sell a electronic device.
That makes hardware hard! The manufacturing and packaging is the easy part.
How did you market it? I'm trying to get into my own production stuff and I don't want to participate in the parasitic Amazon or overcrowded Etsy ecosystems. Looks like you're doing sales through your own website, which I want to do myself. But I haven't yet figured out how to bring legit traffic to my own website. I don't have money to throw at advertising and that's a minefield of fake traffic anyways. Any advice to share please?
Long time customer! I bought one after your original post on HN. Congrats on the milestone. Honestly, it's such a good product and I'm such a bad and inconsistent piano player that I completely forget it exists for months at a time. Then I remember about it, open the app, and everything is there: my attempt to figure out a song, my kids smashing the keys as hard as they can, my cat walking across the keyboard. It's such a joy.
I've had a Jamcorder for 2 years on my digital piano, have been learning to play. Love the tracking data on the calendar and playback. I plugged it in and it's been running and updating itself perfectly the entire time. Thanks so much Chris
Part of the reason I wanted this in the first place was to have the data, a few hundred hours of all my learning and playing. At some point I or someone else will start thowing all this midi into an LLM.the jamcorder has been saving everything I've played in a very tiny amount of space with no effort by me, ultimately will be even more useful.
Hardware's reputation derives from the reality that a lot of companies spin out the hardware before the software is even written - so all hardware bugs have to get fixed in software.
Yeah, hardware is indeed not too hard if you have a trivial hardware project and ignore all the hard stuff.
Complexity-wise this is probably the easiest board one could imagine. It's an off-the-shelf MCU module, a 1:1 copy of the MIDI circuit from the specification, and some ports wired straight to the MCU. Throw in a trivial I2C-connected RTC and HSM for good measure. You could probably design this in an afternoon. But indeed: that is a good thing. Not everything has to be complicated, and plenty of people are willing to pay for simple products.
On the other hand: what is the cost for that?
The USB-A Host port has ESD protection, but as far as I can tell MIDI Out and SD do not. Sooner or later this will result in some static-prone user frying their expensive board. Have you got a proper Customer Support / aftersales pipeline yet? How many units did you reserve for warranty replacement? Luckily you've got a huge margin, so a few replacement boards shouldn't bankrupt you.
Similarly, the MIDI ports seem to be using low-double-digit series resistors for the MIDI Out current loop - in 0402 form factor. As the spec says: short the port and they'll draw over 0.5W, which a 0402 can't dissipate. To be fair, the exact circuitry is a bit hard to tell from the image, but will this mean they'll catch fire?
The AMS1117 is also an interesting choice. It's a classic option so it is often seen in beginner tutorials, but it is absolutely terrible[0], and with the capacitors used you shouldn't be surprised to eventually run into stability issues. It might work Just Fine for 99% of units, but the 1% will have weird undiagnosable heisenbug issues.
From a UX perspective I'd also question the use of a coin cell battery for the RTC: it'll eventually run dry or even start leaking. A supercap would've been a more durable and convenient option - especially considering the "always leave it plugged in and forget it" use case. Or, if you need a battery anyways: go for li-ion so it can be used on-the-go. Similarly: USB-B for Power In in 2026? That's just lazy. USB-C is trivial to add with a 5-minute-guide and would've been cheaper. The USB-A Host port is just about excusable, though: doing that in USB-C is a bit harder. And the Power In port not being usable for a connection to a host PC and telling people to buy some sketchy adapter on Amazon? Understandable considering the MCUs peripherals, but a disappointment.
And then there's the elephant in the room: certification. It seems like you just... didn't? Which is understandable for a small hobby project! But making it EMI/EMC compliant is by far the hardest part of designing market-ready products. You can't just completely ignore all the stuff involved in making it compliant with FCC/CE/UKCA/whatever rules and call it "not so hard". It's the difference between baking a pie for your birthday party, and opening a bakery.
Your hardware project wasn't hard because you've only done the easy stuff. And kudos for shipping - many people don't make it even remotely this far. Especially using an injection-molded housing is quite the achievement! The startup costs for that make it a real showstopper for many small-scale projects, and making mistakes can easily bankrupt you.
But this is where the actual adventure starts: scaling it to 25k / 250k units. You basically have to start from scratch and do 10x as much work. Meanwhile, China is pumping out $10 clones for your $250 recorder. Sure, you put DRM in it, but is your software moat really wide enough to protect you?
Many congratulations on your achievement, but please understand that writing this blog post is almost naively premature. The hard part hasn't even started yet.
First, so far, there have been 0 failures in the field. My email address is on the website, the app, and the first page of the instruction sheet, so I'd probably know if there were.
But since it's fun, I'll address some of these :) I'm not flying by the seat of my pants here as much as you expect.
- The ESP32-S3 includes ±2 kV ESD, which is respectable. Adding more is a bit precautionary IMO, but I did add it in some places where the user is more likely to touch metal (like the USB ports). The sdcard's metal housing is not exposed.
- The AMS1117 is just more available than the alternatives. Again, no failures yet so seems like the right tradeoff was made here.
- Supercaps don't last long enough for my liking. A CR2032 can go for 10+ years. A supercap, only weeks. I want correct dates even if the device is left unpowered for months.
- The 0603 47ohm resistor is a good callout. Worth beefing that up. But at 3.3v and 232 mW it's not a fire hazard. It will fail open.
- USB-B for power was very intentional. It's a great firm connector and more importantly prevents users from plugging it into their piano wrong. Many of my customers are in their 70s or older.
- USB-A for data was made for manufacturing simplicity, but again, USB-C is too complicated for many of my users. I'd only switch to USB-C if both ports could be used interchangeably, but they can't be / it's not worth the complexity.
- As for the software moat, time will tell. You can't stave off competition forever!
Spending too long on the firmware. I almost ran out of runway. I should have cut features faster. And I should have built the firmware cross platform so I could run it my local machine. Every compile + flash loop took 2+ minutes.
I don't know what the timeline is here, but to me this sounds like he either got lucky, or he's in the grace period when you begin a project and the strong enthusiasm for it, and the fact people are not seriously trying to copy it yet, work together to make everything just that much easier...
I'm an EE with main expertise in IC design but I design a lot of the chip packages, PCBs, mechanical stuff like custom made sockets etc and write a ton of SW, be it tools for myself for development and testing, be it the firmware of the chip I'm designing or another chip I use on the board. For me it never felt like SW was the hard bit, because you can write and test it pretty immediately and pretty much for free. HW felt harder because of the tooling costs, lack of documentation and examples, things that aren't obvious at the beginning (EMI/EMC) etc etc but these are very minor compared to the actual issue: long and expensive development cycles. Now, that doesn't apply if your HW is extremely simple and just a glorified uC and rhe development time is mostly the code running on it. This is why this is such a poor take. One can argue for anything at extremes. SW can be very very complex and much harder than HW, and vice versa at different extremes.
I'm usually not an Ai shill, but I found Fable to be the first LLM that could actually provide useful feedback on a KiCAD PCB design. I paired it with a KiCAD MCP, but it tended to reverting to raw KiCAD scripting. If you ask it to review a PCB design, and provide feedback relevant to PCB design best practices, it will probably give you something useful. I wouldn't trust it to do a full design, but it's pretty good at finding issues. I'd add a few clauses to the request regarding checking components against JLCPCB/PCBWay/etc available components, as well as checking copper layer thickness and distances from the main components to the supporting components.
I did this as an experiment on my current project and it found a bunch of minor, non-critical, but completely valid problems with my deisgn.
If you're building with KiCad then I've found the folks on the KiCad discord[1] very willing to take a look over a design and provide feedback. There's also a subreddit[2] for PCB design posting and review, but I haven't personally used it.
>>> The hardest part of building Jamcorder was still, by far, the software -- roughly 200K lines of code spread across the firmware, app, and manufacturing tooling. It took over 3 years and many long nights in a pre-LLM world.
>>> When compared to that, the hardware was undeniably smooth sailing.
>>> For the record, I don’t think I’m special. It’s just that hardware’s reputation for being difficult is, IMO, overstated.
For me, when I complain about hardware, its actually usually complaining about drivers, compatibility, underdocumented interfaces, firmware etc. If one were to put firmware and manufacturing tooling in a separate bucket, that is indeed the problem!
Congratulations! I bought one after reading your post on here announcing it. It's fun to mess around on my keyboard and be able to go back and listen to what I played. Great for learning
It's not that hardware is simple, but the fact that we have inexpensive micro-controllers that pack a giant amount of complexity and let us turn a lot of electronic problems into software problems.
Try building such a device only with non programmable TTL logic.
I am also on a similar boat. After writing softwares for almost 13 years now, I am now working on a privacy focused and universally compatible casting device.
Would love to talk to you more about hardware supply chain issues and challenges.
Meanwhile if anyone is tired of their smart TV being a spyware or showing ads, I would love to talk to you. This is what I am building: https://soljacast.com
I have a old keyboard (Ensoniq SQ1-Plus) where the battery doesn't work right (even when changed) and I was going to put ML Studio on a Raspberry Pi or Mini PC with a USB MIDI device to record. But this thing is exactly what I'm looking for.
When I want to record for real, I'm going to use my DAW. But I want a way to quickly record tracks and this looks pretty great.
I hope the author can break down the recommendations in a future post. I'd love to learn how to build this kind of hardware (what tools are needed), how to iterate on the results, how to find a supplier. Also it'd be interesting to know what the author means by having an counterfeit strategy.
I'm in the middle of my first hardware project right now and I can recommend the videos on the "Phil's Lab" channel on YT. He mostly uses Altium, but he has a few videos on KiCAD which really helped me. He also has generally good throwaway comments in his videos with regards to PCB design / component placement, as well as the order of operations for good PCB design.
The only problem I have with these tutorials is that they're already outdated... I don't think anyone covers kicad 10 yet, and its quite a bit different than 9. (Individual dialogs might not have changed, but where they're located etc might have)
I'm using an STSAFE chip - the same IC they use in StarLink terminals. Essentially the digital equivalent of a holographic barcode. I have some other protections too. e.g. Random 128-bit per-device IDs / product-keys. iMessage uses this strategy.
This is (literally) none of my business, but would you consider a cut down or basic open source version (hardware and software, with open software running in the proper hardware). Yes it'll be cloned by factories, and yes it will cut into sales no matter what proponents claim. (And yes it's probably more work than I imagine it is).
But also yes, it'll be genuine open hardware and might out live your interest in the project.
Reading your comment it sounds like you're asking the author to do more work to potentially/likely undercut their own sales. They are already offering a quality device at a reasonable price without any untoward restrictions.
If you want a Free work-alike, why don't /you/ put in the work and make it happen?
Please do, that'd be very interesting. I imagine it's doable to use random per-device I'd when you're hand-flashing, but probably harder on a huge production run.
Almost all commercial devices need a unique ID, private key, etc burned in on the production line. For a big enough production run, you'd likely ship an HSM to the factory
Depends on where the ICs originally come from. No point shipping your ICs from China -> US, flashing them, shipping them back US -> China for assembly, and then ship them China -> US again to sell
> For a big enough production run, you'd likely ship an HSM to the factory
I figure that the factory is exactly the adversary in the whole threat model? So why give them the keys to the castle so they can moonlight their own genuine batch?
A few ways, if I understand them correctly. On-site people you employ (if you can afford it) auditing the process, connectivity to the HSM to record every key assigned (makes it easy to trace duplicated keys to their origin), and ideally assigning these keys at the very last possible step after the rest is assembled (to minimize 'defective' parts wandering off and being assembled elsewhere).
Yeah, it's important that your own people are doing regular inspections of the production line, keys get burned at the final station (use temp keys for QA stages before that point), and you retain software control of the HSM.
You probably aren't going to do this whole rigmarole for small runs of devices like in the OP.
You want a unique ID so that you can track which units are experiencing issues, you want private keys to be able to securely connect to your backend service and/or mobile companion app.
A local-only device with no telemetry can probably skip some of those
From a financial perspective, what were your biggest challenges? What was the working capital cycle like? Were you forced to do a certain level of minimum order quantities and did the cash constraint limit other decisions?
500 units was my first run, and it worked out really well. None of the suppliers complained about that order size. I recommend starting with a smaller quantity until you've validated the market. The "economies of scale" between 100, 500, or 1000, units are not all that dramatic. Perhaps 30% cost difference.
I was originally planning to do 4000 units as my first run. Boy I'm glad I started to run out of money and cut it way back. That would have been way too much as a first run.
This is not a criticism but I am curious about what the trade offs are in terms of cost/bom etc of using usb-c. I found it surprising that that wasn't a given in 2026,curious where it hasn't caught up as an option.
If you consume power over USB-C, 2 resistor are enough.
But for providing power over USB-C, you generally need a dedicated IC to handle VBUS switching. It wasn't worth it.
Also, once you ship a consumer product with a USB port on it, you'll realize a lot of people really don't understand how USB works, and USB-C doubly so. Square holes for square pegs goes a long way.
Sure, but your power input should be a USB-C. No reason to use the clunky USB-B for that. Labeling as Power In and leaving a regular USB A for the output seems fine to me. Given that most older keyboards use USB-B for their input, A is a perfectly fine solution and solves the “input vs output”.
Not technically custom, but made to order (I gave them a spec sheet). If they had reasonably priced connectors on LCSC or DigiKey, etc, I would have used them!
Unlikely to happen any time soon. The problem is mask manufacturing costs: you spend a lot to make a set of masks, but after that making the chips is incredibly cheap. Great for mass production, not so great for prototyping. And there's a lot of proprietary 3rd-party IP involved in chip production: fabs are not very eager to make that publicly available. Heck, even FPGAs are still mostly proprietary!
That doesn't mean it is completely impossible, though. Fab2 (formerly Atomic Semi, of Jim Keller and Sam Zeloof fame) is trying to do exactly this by aiming at making small-scale production affordable. The trick is to replace the whole mask-based lithography with electron beam scanning: way slower, but no mask costs.
But they are now targeting selling mini-fabs to R&D labs rather than offering an affordable ASIC-as-a-Service. Let's hope one of their customers makes it available to the public!
It’s actually not hard to hack this together as a .net application and run it on a laptop, but I suspect your target market has a bit of money to spend.
Learning piano is already largely an upper middle class active and after that what’s another 200$ or 300$.
A higher end digital piano is easily over 2k.
Making sure your target market has money is the key take away.
Not sure if this is in scope, but I’d love an easy way for the community to share midi files. I can somewhat do very basic piano progressions, but I still can’t play well.
I’d be grateful if someone would share midi files for me to plugin to my music software. Of course I’d provide full credit
The anti counterfeit strategy is that the volumes here aren't worth it for someone to clone, even if the board and code are dead simple.
These niche hobby products are usually reasonably safe because they rely on community network effects, becoming the darling of a random subreddit or discord group and people aren't going to save $20 to get some device of dubious origin.
Another happy customer, bought two Jamcorder units. Not just the hardware is simple, the software as well: it just works, quietly in the background. I just had to enable daily auto-reset otherwise it eventually had issues. Whenever someone starts playing piano, it records. The iOS app is so nice, playing back on the phone or on the piano, and keeping track of total hours played and organizing favorites.
Congrats, if only more projects kept things simple and useable!
Ok are you riding with two huge boxes containing all your work on an electric unicycle and I guess the hi-vis top means you're headed into traffic and the box-cords seem to be balancing at the halfway point of the boxes and this is too much anxiety for me. But hey, glad you optimized for minimalism on the PCB ♡
Very much appreciating the sentiment in the article.
Is it just me, or is there some kind of unusual photo editing going on in the photo at the bottom of the article? Something looks uncanny valley, related to the bottom of the box on the left side of the photo, and related to the background. Did some kind of "erase background" mechanism go wrong here?
If I may ask for your advice on a related subject.
I have an old electric piano, it doesn't register dynamics, the strength with which I hit each note. Which is a huge bummer.
I can't think of a simple way to hack dynamics onto the keyboard, I thought of adding an additional sensor and using the time delta between touching a key and hitting the bottom, but that's not really correct, as you can hit a pianissimo key fast in staccato.
Maybe a basic spring that decreases resistance as it becomes compressed, but it might make keys quite hard, and it's not very simple to implement.
Well, hardware-wise you made equivalent of hello world project so of course it is not hard in absolute terms (not to piss on your parade, it's a very cool project, just to have point of comparison).
Just that hardware equivalent of 200K of lines of code would take far, far more time and resources and with way longer debug cycle, especially when you hit the complexity point where bodging few wires to fix the prototype gets harder and harder.
That's what people mean when they say hardware is hard - if you need to start iterating on a board and not just board's software it gets complex and expensive really quick
But it is far better than it was before - I got my 5 board prototype of similar complexity (also esp32 based) within a week, assembled board, for like $100 (and it was my design mistakes that made it so expensive, like picking screw connectors in places that could totally use far cheaper generic part JLCPCB had in stock, i just didn't know any better), just a decade ago that would probably be order of magnitude more expensive.
So yeah, for those that always wanted to build a hardware project, it's probably best time in the history to do that. Both PCBA and mechanical part got cheap and commoditized enough.
Hardware has a reputation for being hard for three reasons. First, it scales differently than software. It's far harder to design something you want to make a million of than something you want to make ten of. Second, it's harder to anticipate, test, and correct all the things that can go wrong on the user end. Some people will put batteries the wrong way, some will drop the device on the ground, some will connect it to some vintage equipment you have never seen in your life, etc. And third, there are just more failure modes in an unfamiliar domain - sometimes, your code will intermittently crash not because you have a software bug, but because you put the decoupling capacitor too far from the chip. Or, just as you finish your design, the chip you designed it around becomes obsolete, or impossible to find because a factory in Indonesia is on fire.
Another complication is that at least in theory, if you're selling electronics, there are actual regulations and third-party testing that needs to happen, and if you fail emissions, you might have to redo your design from scratch. Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB".
So, I'm happy for the author, but I think he had an outlier experience. When you look at Kickstarter stories, people repeatedly stumble over this. Manufacturing / cost difficulties, supplier issues, reliability issues, etc.
> "actual regulations...emissions"
yeah, and looking at their board I see they use one of "ESP32-WROOM" modules, which has the wifi & blutooth & antennae (pre-certified by Espressif for FCC, CE so itself doesn't need testing) & flash & processor (which even has its own RC oscillator), which takes care of a whole ton of difficult stuff so all the designer needs to do is plop that module down and power it up and wire some SPI/I2C peripherals which I'm guessing don't need super fast clocks or electrical constraints. Without something like those ESP32 modules, this would be much more difficult.
The pre certified module do not exempt the product from testing. It only means that you don’t have to do the conducted testing and that it’s a higher probability for passing the other tests. There are still lots of chances to fuck up and a full radiated test of the product is required.
>and a full radiated test of the product is required
legally?
In the EU (and UK with UKCA), CE certification is down to whoever makes the product available on the market. There's no get out for pre-certified modules. If you put a pre-certified module in a box and sell it, you have to be responsible for the CE mark.
You need evidence that the whole product complies with the EMC regulations. There's some judgement involved - if you put a certified circuit board in a plastic box, it won't change the EMC behaviour so you don't need to re-test. But if you solder a module onto a larger circuit board, you are almost certainly changing the EMC behaviour. You should definitely be re-testing something like that.
The pre-certified module does save you some time in the "intentional radiator" testing - assuming you use the same antenna it was tested with as a module, you can probably make the case that the behaviour is the same.
Will anyone ever notice or care for a few thousand niche devices? I doubt it. But to sell in the EU legally you do need to do that testing.
No, you actually don't have to do the testing, except in some special circumstances (e.g. childrens' toys). Generally, the "CE" mark is a self-certification done by the manufacturer or importer that certifies that the product meets certain (category-specific) criteria. You can do the proper thing, test your product and then certify it. But it is also possible and usually legal to just issue the certificate based on a self-assessment and deal with the fallout later, if there ever is any. That's how basically all non-EU manufacturers and importers get their CE mark...
https://europa.eu/youreurope/business/product-rules-complian...
> except in some special circumstances (e.g. childrens' toys)
Don't nearly all electronics fall under it too, this is the second item after children toys in the link you posted.
> Here is a non-exhaustive list of products that are included in EU laws about CE marking:
> Toys, drones, electrical and electronic equipment, pyrotechnic products, recreational crafts and watercraft
Depends on the legislation, but for most markets yes
Im not an expert in emissions testing but pretty sure it still needs CE certification testing. The module shouldnt cause any problems providing that the firmware for the transmitter is configured properly, and is placed sanely in the enclosure, but the entire product must still undergo the relevant testing for 2.4GHz emitters.
Just because you use a certified module doesn't give you a free pass.
> but the entire product must still undergo the relevant testing for 2.4GHz emitters.
To be fair, it's unintentional radiator testing that's required, rather than everything the module had to go through as an intentional radiator. So, it is a "free pass" for nearly all of it, and a much cheaper one, since you don't have to use a costly FCC accredited lab.
Modular Approval is an FCC thing only. CE doesn't have it.
It does still need CE certification and emissions testing. I’m guessing they didn’t do that and it will be fine because they only sold 2,500 units.
The ESP32-S3-WROOM1 module is FCC certified for its own Wifi and Bluetooth emissions when used by itself.
And, well -- that's certainly good.
But the FCC rules cover more than just Wifi and BT, and the whole rest of the widget also needs to comply with them. Of particular interest is FCC Part 15 Subpart B, which covers unintentional radiators. The device would need to comply with Part 15 Subpart B even if it had nothing to do with Wifi or BT.
Putting one part that is certified for one issue into a device doesn't extend a magical blanket of compliance to everything else that the whole of the widget contains.
Does the SPI or I2C bus (or anything else) leak RF beyond allowable limits? Eh, who knows. I certainly don't know. It's easy to say words like "it should be fine," but without testing then nobody actually knows.
The CE mark, meanwhile: That mark means exactly nothing in the US, where the author is located and the devices are sold from. The United States has zero regulatory recognition of any of the processes and/or tests that CE may cover. People often confuse this issue, wherein: They don't think it be like it is, but it do.
A fun fact of the CE mark, is that it's also used to signal "Chinese Export" deceptively, with the marks being almost identical beyond spacing.
Of course there’s no actual official ‘china export’ mark and that is just what some Chinese factories were claiming when they were caught slapping a (accidentally mis-spaced) CE conformance mark on their products! The EC made a statement on this back in 2008 [1] so everyone knows what game they are playing.
1. https://www.europarl.europa.eu/doceo/document/P-6-2007-5938-...
> Without something like those ESP32 modules, this would be much more difficult.
I don't disagree. It's important for us to recognize that we stand on the shoulders of giants, but I also think it's a little silly of a critique of someone happy about it being easier than he expected. It's true that hardware would be much harder if you had to do it all yourself, but is that meaningful? The wonders if the modern supply chain is that you don't need to do it all yourself.
Well the title and premise is a bit silly. If you're designing easy hardware by wiring parts together that already do all the hard stuff, then "hardware is not so hard" is something you might conclude, but that only applies for designing easy hardware like this. But if you are doing anything that pushes the limits or involves analog signals and having to worry about signal integrity and EMI and impedances and Laplace transfer functions all that other stuff that requires degrees, then "hardware is hard".
>your JS is too big, you can't ship until you get it under 50 kB
Back in the glorious past, the iOS App Store either didn’t allow apps larger than 100 MiB, or at least forbade them from being downloaded over mobile connections. There’s an old blog post/Twitter thread you can find on Hacker News where an Uber engineer describes the challenges they faced in trying to keep their app under that limit. They were also rewriting the app in Swift, so some compiler patches were necessary.
It still boggles my mind than such limits are a problem. Sure, a game with graphics and sound could easily burn past that.
But for a “boring” ride hailing app, it’s still beyond my imagination.
Microsoft Word was something like 8-10MB in the Windows 3.1 days. WordPerfect was about the same and even had a grammar checker.
The entire damn PC with DOS, Windows, and Word was 30MB.
We’ve fallen so far, we mistake the darkness for outer space.
There isn’t all that much actual first-party code in these apps, but if they made a “Hello World” but kept the same third party library deps, they’d be starting at 300MB, and once they add all the visual assets that’s another 200MB… I have a ton of apps on my phone that are absurdly large. Like Gmail is 706MB. The Gmail app for iPhone could not fit on a CD-ROM. A plain mail client. Compared to that, Facebook at 461MB is looking quite slim.
Overcast is 37MB.
I don't want to justify the space too much, but things like the Uber app are kind of amazing.
While the base functionality is fairly simple in terms of find location > send car + all the courier and different varieties of what they do. It manages do that while working in 70+ countries over 15,000 cities with multiple different languages and payment vendors and it is all done via a single application.
That is pretty neat.
Yes, it is still very bloated but it does a lot more than what it initially looks like.
But yes, I am endless impressed when you come across a binary that is tiny. Like a text editor that is 14KB, sure it is simply but it doesn't need to be anything more for most people.
>It manages do that while working in 70+ countries over 15,000 cities with multiple different languages and payment vendors and it is all done via a single application.
I'd assume almost all of that is done server side though. Most likely the app is mostly just a wrapped website with some gps and notification code on top.
And as someone who works on platform that makes use of numerous payment portals depending on the product and region you're buying in. It's all just wrapped up in logic AKA if statements.
Because it's all just API's?
The app just calls the GeoLocation API on the device, pings that off to a server and the server responds with services available in <distance>
With more RAM, Storage and Compute everyone just got super lazy.
We're at the point now that everything is written in some sort of javascript, with a JIT compiler and JS engine...
Even that isn't an excuse, when we compare the computers running Lisp and Smalltalk, versus what we have today.
Folks cared on how to make it all fit into what they had, maybe the RAM prices will help to bring back old practices.
Blog posts:
https://www.uber.com/us/en/blog/how-uber-deals-with-large-io...
Comments about a Twitter thread talking about the same thing: https://news.ycombinator.com/item?id=25373462
now App Store doesn't prohibit it, but it still asks you if you'd like to download an app that weights more than X mb or wait for a wifi connection to do so.
Apple UX used to be good, not anymore sadly
>Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB".
A man can dream.
Firmly agree. A lot of the lessons you mentioned have been discussed previously on HN threads for hardware startups. This is one of my favorites:
https://www.simonberens.com/p/lessons-learned-shipping-500-u...
HN thread: https://news.ycombinator.com/item?id=46848876
Yeah, I think a lot of the "hardness" of hardware is of a different flavor than software. The author mentions how many lines of code are in the software, but that really is more of a symptom of something that makes software "easier": you have way more flexibility to iterate, and try new things, at a relatively low risk and cost, even if it's embedded software (at least for non-critical applications). Hardware is just more unforgiving. There's no cheap way out of the kind of scenarios you mention.
Microcontroller and sensor bugs owe me a lot of sleep that I will never get back, to add to your point.
>> Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB
I work in games, we run into this problem all the time ("Your IPA binary is too big, fix it and resubmit", ditto for other publishers).
Maybe this isn't special in the era of pre-funding but there's also over manufacturing. You have to guess how many you'll sell. If under guess you leave sales on the table. If you over guess you lose money to all your undersold but already paid for inventory.
> Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB".
... But also that needs to be an official measurement, and if you're sloppy you can measure it wrong during your own testing and then be surprised.
> impossible to find because a factory in Indonesia is on fire
Has that happened to you?
Not this exact thing, but I make a hardware product akin to a guitar pedal. I designed around a component type that the semiconductor industry was phasing out. One day I noticed that the list of alternative parts at my distributor included many that were marked "obsolete." I panicked and bought the entire stock of the part number that I use.
At this point I have the only stock of this part in the world, and it's more than a lifetime supply, but otherwise I'd have been faced with a re-design and limited options.
For another of my products, during the pandemic, the part I was using became unavailable, and I had to re-design my board to accommodate a part of the same type in a different package. Then I couldn't buy either part, but found an odd lot at a Texas Instruments factory in China, which I bought.
Dealing with shortage and obsolescence issues is a constant battle. There have been crises in the industry caused by plants catching on fire.
One thing I've always said that with products, especially when they're parts. They should be required to be made "open" as soon as you stop making and/or selling them.
They're making you nothing, they're going to vanish into the nether if the documentation is lost....
Not literally, but I had two projects I had to fundamentally redesign due to multi-year chip shortages in the COVID years. And we're not talking about any fancy chips.
STM32 had this problem of disappearing for years. At least I was forced to move to ESP32 and have never returned back.
A power converter I designed 3 years ago needs redesigning because the company that made the transistors was bought out and all their packages were phased out. And they were some fucking good packages that allowed for very good cooling and very easy parallelling of transistors using both sides of the PCB.
Then something has to be said about digital/discrete hardware, which is not dissimilar to programming, and then the alien (to software devs) world of analog chips.
> Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB".
... that's a very normal constraint in many fields of SWE?
Nothing stops embedded work faster than running out of code space on a microcontroller!
AND shipping.
Shipping physical products can open you up to more fraud, because once it’s in the mail, it’s in the mail. The customer can say it never arrived or claim their card was fraudulently used in order to keep using the product for free. Whereas with a SaaS you just disable their access.
And also logistics is a race to the bottom, everyone is competing to get more and more packages through the system, and the customers are demanding lower and lower prices.
So there's a fair amount of stuff that just doesn't make it there, there's a whole business now on re-selling non-delivered packages.
And with that also comes the services, the reason they leave it at the door, or in the bin, or yeet it onto the roof. Is because there's no profit margin anymore for the delivery person to wait 30s each time for someone to answer.
>your JS is too big, you can't ship until you get it under 50 kB
Not only that but every single update you push requires paying $$$$$ to get certified. It is freeing that the cost of releasing a fix or improvement to a product is $0.
In the past I considered selling a custom adapter to hobbyists, but all the certification costs just did not make it a viable option to pursue. I didn't want to up front thousands of dollars to make like $100 if I was lucky.
>But for me the take away still is: “hardware is as hard as you make it”.
I dislike this statement. Hardware is as hard as the product dictates it needs to be. A 25 component PCBA and a clamshell of 2 injection molded parts is about as simple of a product as you can make. Heck, most people would just buy an off the shelf clamshell for that type of product.
That doesn't work for the vast majority of products, building a product with 20 COTS parts plus 60 custom tooled parts, and 4 complex PCBAs is what is hard. Getting everything to fit together, pass testing, arrive on time from dozens of suppliers, etc. it where the complexity comes in. Then consider that hardware is cash intensive, you need to pay ahead of time for all the tools, you need to pay to buy the individual parts and warehouse them somewhere while you build the products you hope are going to sell. If something goes wrong there, then your expensive parts are just sitting there waiting for replacement components before you can ship. Then even when you ship, that revenue goes into buying the next round of parts you are going to receive in 3 months. This is where many hardware projects fail as they run out of cash before the project breaks even.
This. A decade ago, during my summer internship in the first year of college, I got put on a hardware project, basically designing a remote monitoring device for a telco.
I wrote the software, and my friend designed the PCB for the digital side. Basically I had to be a decent C programmer, and read the datasheet for the MCU we were using (which was way more work than using something like an ESP, but still). My friend had to lay stuff out on the PCB and place secondary components according to various application notes.
Overall not simple, but not rocket science.
On the other hand, the guys doing the analog daughterboard were industry veterans with decades of experience. They had a million concerns, from signal integrity, to voltage protection, back-EMF, etc. I was not even near the ballpark of that skill level.
Later on, I worked on more complex HW projects, stuff with FPGAs, DRAM integration and 8 layer PCBs, where you had to run full electromagnetic simulations because when you run at 1+ GHz, suddenly signal propagation is not instant, and traces behave like antennas.
I also did software there (a smaller slice of it this time), but there was an army of engineers working on the whole project which took a year, and not a second of it was spent in vain.
I agree with everything you're saying, but if you consider that this is a single-person company, the "hardware is as hard as you make it" statement makes sense. He saw a need, found out that it would be feasible to make a product to fill that need with very simple hardware, and chose to make the product. If solving the problem would've required hardware outside beyond their budget or skill level to make then presumably they wouldn't have pursued the whole project. Which I guess is sort of the point, but of course the title of the blog post doesn't really convey that.
Very happy JamCorder customer here. I've started playing in improv shows since I bought it too, and it's nice to have those on record!
It's rare that I come across a product I have literally zero complaints about, or any feedback to offer. Even my concern that it was tied to an app that might disappear one day is of course covered by the fact that it's all just MIDI files on a card.
Thank you so much for making this, it's basically a perfect product for me and I love it. No notes.
Ditto here. I was an early customer and it's just flawless. It powers right off my piano USB so it's basically silent.
If I ever get good at piano it'll be handy
>Even my concern that it was tied to an app that might disappear one day is of course covered by the fact that it's all just MIDI files on a card.
I was sorta surprised when the blog mentioned it was like 200k lines of code for an app. I wouldn't think you'd even need an app for something that puts midi files on an sd card.
This is very flattering. Thank you.
Inquiring minds want to know: what is your anti-counterfeit strategy or is the fact that you're keeping it under your hat part of the strategy?
Also, pretty cool that you set up your website real fast. Would you mind adding your Twitter link onto the site?
My guess is that it’s on the software side partnered with the app.
Yes the anti-counterfeit is primarily app enforced (though entirely offline). I do use the firmware encryption features of the ESP32-S3, whatever that is worth, and the firmware is tied to the HSM.
What happens when app is outdated and can't be installed to current android os?
The device does not require the app. It still records MIDI 24/7 to sdcard.
It's more the opposite. The app requires a genuine device.
I think that highlights one of the reasons why, in this case, hardware has not been hard. (besides the fact that you are very clever)
The value you have created is actually more in the App than in the hardware.
As a maker of small devices (mostly open source) including MIDI - and putting aside commercial aspects like injection molding - I could recreate the hardware side of this project without much issue. The necessary components are likely already in this room with me. (I won't - I'm not in the business of copying things that people don't want copied)
But I'm not a software engineer, and therefore could not produce software of the scope and quality that you have, which is where the unique functionality of your device sits high above the relatively simple "receive MIDI data from MIDI devices" principle of the hardware by itself.
Are we talking about the app operationally day-to-day, or the app vis a vis the way it helps end users flash encrypted firmware images OTA to the ESP32 (like Chip alludes to in gp comment)?
If there are no more app updates, presumably there are no more firmware updates either, so the flashing part probably doesn’t matter (and you can probably flash the last published image to an authentic device by other ESP32-y means if you really need to).
As to the day-to-day: Pretty sure the hardware still records regular ol’ MIDI files to the SD card. The app seems incredibly well-thought-out and ergonomic but, at the end of the day, nonessential to the device’s core function.
Somebody could presumably build and sell their own “MIDI Recorder Loop Nonstop Device Digital Piano Upgraded New 100%,” but it wouldn't be a Jamcorder, you couldn’t flash Jamcorder firmware updates to it just by slapping an ESP32 in a case, and the official Jamcorder companion app would not talk to it. Which… fair enough, right?
For that matter it wouldn’t surprise me if somebody could write their own client for the real Jamcorder, if they felt so inclined… but with the official stack so absolutely perfect from a design perspective, why would they?
But even things like SDCards move on, we've already seen that with SDHC. I've had EOL kit in the past that just doesn't support it because it's that old, and thus EOL and doesn't support that standard.
Saying "It's just writing to an SD" is today
Oh good, you're not pulling a Cricut where the app interactively proves to the cutter that it has an AES key and then encrypts all the G-code with it before transmitting over Bluetooth.
Right?
Congrats on an impressive achievement and milestone. This is a great outcome, great work, and an indication of how far the hardware industry/tooling has come.
This feels though a little to me like building a simple SaaS service, and deploying it on a managed cloud service, and concluding all software is really easy!
This project is near to (if not at) the easy end of the hardware product difficulty/complexity spectrum. Some great choices were made to keep it simple and therefor easy.
An alternate take-away: "If you keep things simple, hardware doesn't have to be as hard"
That underrates the difficulty in keeping things simple.
It is mentioned elsewhere here that a lot of time was burned on unused firmware features. It takes surprising discipline to cut stuff and still deliver.
Agreed. At someone who works primarily in hardware, it is definitely hard. A midi-to-bluetooth recorder is practically a software project in a fancy box. There is very little physical complexity to deal with here, which is what makes hardware difficult- the interaction between firmware and the "real world".
Congrats though, making a half-million a year business is a massive accomplishment! The headline just irked me a bit, haha (but, it got my attention, so I guess you win there)
I don't entirely disagree. Just one sample point. But there are certainly much more simplistic hardware products out there. I'm often envious of them.
Here's a good example: https://duckduckgo.com/?q=brick+smartphone+blocker&ia=web
Hey man, you made a successful product, wrote a great article, and are now getting attention for it. You don't need to respond to every person who wants to nit pick at your title :)
I think there's a lot of people talking past each other here. Sourcing parts internationally, preventing counterfeiting, slow iteration time, inventory management...all this logistical stuff is hard enough that the conventional wisdom in the software business world is to never attempt it. You're here presenting a counterexample and that's wonderful. The people criticizing aren't talking about this though, they are talking about whether logging digital inputs on an esp32 counts as a real hardware project and they act as if you've insulted their expertise in [signal processing/antenna design/insert specialty here]. You didn't do that, most of us know you didn't do that, but the word "easy" sets a lot of engineers off.
Just ignore the noise and keep writing great articles. My personal request, if I may - I'd like to hear how you did injection molding since I always assumed that was out of reach for small business.
I wanted to ask the exact same question. 2500 is a very low order size for injection molding am I wrong?
Not super low. It starts to make sense around 1000 units. I’ve gotten runs of 2500 done domestically. But it is pretty hard to find domestic injection molders for consumer work - they will give you an FU quote at best because they cater to high volumes and industrial customers.
And they’ll make the molds in China anyway. Chinese molders are hungry — they will work with low volumes and offer a bunch of integrated services. But if you don’t know what you’re doing you will end up with bad parts over schedule.
Easiest way to get started is to use ProtoLabs. They charge lower prices on molds in exchange for higher part cost, are way faster than China, and have way better customer service.
Very happy to hear about your success!
I'm curious to hear more about your anti-counterfeit strategies beyond just enabling encryption. I'm curious if you feel like anti-counterfeit and open source firmware are mutually exclusive. I made the choice to embrace an open firmware approach on my project while keeping the hardware closed, while knowing that if someone tries hard enough they can completely reverse engineer if they put their mind to it. Desoldering caps and x-raying PCB layers etc.
I'm also very curious to hear more about your adventure in injection molding. What starting resources do you recommend, how much did it cost? Would you do it the same way today, or have the recent innovations in 3D printing forms for injection molding present superior paths?
Finally, I'd love to hear about your certification process. What certs did you get, how much did it cost, what were the gotchas?
You don't need an X-ray for a board this simple. Every component has well defined input and outputs. Give a mildly competent freshman EE student or high quality high school student you could have the board recreated in a few days.
Low product quantity and low quality/fake products resold on amazon from AliExpress are the biggest roadblocks at this point. The juice isn't worth the squeeze.
Right... except I'm asking so that I can apply his techniques to my PCB, which you know nothing about.
Will do a write up on injection molding and anti-counterfeit!
Sounds great! Can I subscribe to an RSS feed/mailing list?
Wow, congrats, I remember reading your HN post. I hope you will continue writing blog posts on your journey, I expect quite a lot of software engineers would be very interested going though a similar journey now that LLMs removed most of the fun of programming. It’s neat to work on something physical for a change
> now that LLMs removed most of the fun of programming
Never understood this, was the "most of the fun of programming" the literal typing for you? For me it was about solving problems and building things, and I get to do that more now than before, and without all the literal typing.
I reject the idea that programming is „just typing“, so we are very unlikely to understand each others. Writing the code and thinking about the exact logic you want to apply and all its implications are part of the same problem solving process in my mind. You can for sure plan things at a different layer of abstraction but putting things together in code is a very satisfying and IMHO is the actual building part of the job. It’s full of decision making and thinking.
LLMs move me away from the implementation, which is more a managerial role, something I personally have zero interest in.
> I reject the idea that programming is „just typing“, so we are very unlikely to understand each others.
I'm sorry if I gave the impression I think programming is just typing. For me "programming" is the whole activity of creating software with code, you can do programming without the literal action of typing.
> Writing the code and thinking about the exact logic you want to apply and all its implications are part of the same problem solving process in my mind.
That's really interesting perspective to me, as these two activities for me are two completely things, and "thinking about the exact logic" happens way before I actually write any code at all, sometimes weeks/months even.
> putting things together in code is a very satisfying and IMHO is the actual building part of the job.
I agree that it's satisfying, but I guess "putting things together in code" still for me is more about being able to mash two concepts together in an elegant way, and none of that actually requires actual typing still.
> LLMs move me away from the implementation, which is more a managerial role, something I personally have zero interest in.
This is also interesting, because it feels like LLMs give me the opportunity to do more implementation, and not get stuck in the minutia so much, but rather focus on how the design and architecture actually fits together. Refactoring no longer is "I want to but also I don't want to spend the time nor get stuck in more rabbit-holes", so being able to focus on architecture/design more feels like it lets me care more about the implementation than before.
I’m just wondering why it’s bothersome that someone else doesn’t like coding with LLMs.
Maybe they just like doing it the old fashioned way. You can both exist.
Unless you’re getting a commission to sell LLMs to people I struggle to understand what you’re trying to achieve.
> why it’s bothersome
It's not bothersome, I'm not bothered by it at all, everyone gets (in my mind) to do things that makes sense to them. When I write comments here disagreeing with others, it's more from a "Please explain further your perspective so I can understand it, which hopefully I trigger by challenging it" view than anything else, not "You should do as I am doing things".
> Maybe they just like doing it the old fashioned way. You can both exist.
Completely fair if that is the perspective, just to re-iterate, I'm not trying to convince anyone of anything, only to understand other perspectives better.
Fair, I understand better where you're coming from now. Perhaps I read into more of an implication than there was.
Maybe you haven't fully explored coding with AI, yes a lot of people will say "Make me a pretty website with user accounts" and have a working poc they'll use as finished product. But there's so much more you can do with programming knowledge to restrict and control AI to build it exactly how you want it without having to write thousands of lines of scaffolding yourself
Rather than "managerial" I tend to view it as more "professorial". Maybe it's my academic training (but I got out before I became a professor), but I tend to like to think about my problems in terms of abstractions and invariants and common ways to represent things. I just now describe them in English rather than code. But I do find that LLMs do a much better job the more clearly and completely I express what's in my head. I get that same satisfaction that you mention, but now it's when the LLM does what I want on the first try rather than fighting with it all day.
In the past when my junior engineers were fighting with a bug all week, I always told them the dopamine hit of solving the bug is what keeps you coming back to work for 20 years. Half joking, but the dopamine hit of from the satisfaction getting complex working software in a weekend is like crack to me, we'll see how that plays out long term :)
Did solutions to problems just pop into your head when you were programming before LLMs? Did you not pause and think about the code you were writing before?
Most of the time by the time I reach the problem, the solution already been thought of, yeah. The literal typing and editing was behind compared to where my mind wanted to go I suppose. But also I spend long time considering the design/architecture before even attempting to write the code, so most of the time when I was literally typing code I'd know pretty much how it should be. Unknowns-unknowns being explored as separate prototypes before solidifying on any design choices, and so on.
I think you just have a much narrower definition of programming. Others seem to be including the "long time considering the design/architecture before even attempting to write the code" in the programming, while you are only counting the time spent at the computer. You both agree much more thinking time than typing time is involved, just not that thinking about programming counts as programming.
Literally typing is definitely part of the fun for me. I’m a mechanical keyboard nerd though so that might explain a lot.
Beyond the typing though, I find enjoyment in perfecting the structure of the code, thinking deeply about how the pieces fit together. I enjoy the process of iteratively refining the code so that it clearly represents the program using the optimal level of abstraction and minimizes superfluous code/syntax. I find that using an LLM eliminates all of this and produces code that lacks all of the elegance and readability that I aspire to in my own code.
> Never understood this, was the "most of the fun of programming" the literal typing for you? For me it was about solving problems and building things, and I get to do that more now than before, and without all the literal typing.
Your take is so reductionist it's hard to believe you actually like to solve problems.
The LLM tempts to just write the thing you want to write with just few prompts.
Some people fall to that temptation instead of using LLM to just do the menial stuff and do the fun stuff themselves.
> For me it was about solving problems and building things, and I get to do that more now than before, and without all the literal typing.
The problem at least I have is... when something goes wrong, often enough even you as the original author / LLM slave-driver have no idea what is going on where, and completely forget trying to dig into someone else's pile of vibe-coded garbage. For every single problem you now are completely beholden to the AI agent.
programming is thinking while typing. its not like llm think, chill, think. very unatural.
Thinking while typing? Can you just keep generate code at typing speed? I spend a lot more time thinking than typing, and my most productive days are usually when I throw out a heap of code and replace it with a few highly factored functions.
While I'm typing, I'm not just thinking about which keys to hit. I'm thinking about how I'm using a function and what the inputs and outputs are. I'm debugging in my head, I may realize the code isn't going to do what I thought it would. Or I'm realizing that what I'm doing isn't going to scale and that I need a more rigorous approach. Often, I'm thinking "wow I'm going to have to type this same block a bunch of times, I should make a new method/function to handle this."
With code, I'm not planning everything down to the finest detail before I start writing. I know what I ultimately want my code to do but there are many unknowns I hadn't considered. Coding with an LLM is different depending on how you use it. When I'm using code completion, that's usually just helping me prevent syntax errors or to write an efficient snippet of code without having to check docs. But when I tell Claude "I want a web app that does xyz" and it creates it whole-cloth, that takes away the challenge of learning something new and building. I'm not a web developer and anything I could create is going to take me a long time to make (and it probably won't work well or look good) but Claude cranks it out with ease. I get to play software project manager and let the expert do the technical work. It's kinda fun being able to quickly get resulrs. Rather than debugging individual lines of code and thinking about the best way to implement code, I get to test features and think about better ways for the overall system to operate.
That’s a very nice way to put it, thanks for that comment
> quite a lot of software engineers would be very interested going though a similar journey now that LLMs removed most of the fun of programming.
I suspect we will see a reversal on this. LLMs are flat out worse than humans at programming (yes, even your latest favorite frontier model). I am faster (once you factor in the time fixing its inevitable mistakes) and better at programming than Claude is, and I'm not a particularly exceptional programmer. People say "they aren't going away", but I disagree with that - already we've seen people disenchanted with the lack of results compared to what they pay, and that is only going to grow once the AI companies raise prices in an attempt to turn a profit rather than lock people in. Eventually the industry will wake up and stop drinking the kool-aid, and what matters will once again be the results you deliver, not the tools by which you deliver them. But it's hard to say when that will happen, and it's going to be rough in the meantime.
A question:
Are you still below any significant scale thresholds and are there any you dread crossing?
I ask this because I tend to find things are simple until they are not. e.g. it's easy to write an e-commerce platform until you have to deal with shipping, duty, tax, tax on shipping, etc., for multiple countries.
There are scale thresholds I am aware of in hardware that I have not yet run up against. For example I am using Free software, but I am aware that with commercial CAD you can cross over price tier thresholds. Or for another example there are sales quantities where with electronics you might end up needing compliance testing, consumer safety testing etc.
Which ones haven't you crossed yet that you expect to have to navigate?
I make a physical product, akin to a guitar pedal. Possibly the most scary threshold would be if I'm successful enough that I need to quit my day job, but not successful enough for the business to support my family. That's kind of a no mans land where I don't want to be.
Another similar threshold would be having to hire people, which changes the complexity of the business in a variety of ways.
Having too many orders is a good problem to have (unless it gets cloned). Worst case, you pay an external contractor to sort compliance/fulfillment/whatever.
I guess, though I am not sure that this truly is the worst case, if some new compliance thing required a redesign or worse.
You hear about firms that go over certain thresholds, get noticed and then find out that their production facility is no longer "small" or exempt for example.
Some amount of defensiveness in planning and design can mitigate but I'm interested to know if there are thresholds I didn't know about.
How did you navigate the world of compliance testing and certification, with all the different countries involved (FCC, UL, etc). Are there any markets you've decided not to sell to as they're not worth the paperwork?
I chose to do FCC only and CE self-certify. If you use pre-certified radios it's not as expensive as you think. $5K should be plenty if you ask around. Just make sure you design your board so you actually pass, and don't let the labs over-sell you. They'll try to!
99.99% of cheap Chinese products you buy on Amazon don't actually have this testing done at all. So by doing any testing you're already way above them.
I wrote a bit about this in CrowdSupply write up - https://www.atomic14.com/2025/07/21/crowd-funding-retro
CE is all about self certification. The lab testing gives you the confidence to do this.
It can be expensive - but Chinese test labs are very affordable and do a really professional job.
There is now quite a good EU based service - https://early.smander.com/ I used them to get some advice early on (disclaimer, I know the founder).
How did you go about finding a Chinese test lab? Asking for a friend. ;-)
You can’t self certify any products including a radio (almost everything today due to WiFi and BLE), products for children or medical equipment. An accredited lab is required.
> 99.99% of cheap Chinese products you buy on Amazon don't actually have this testing done at all. So by doing any testing you're already way above them.
Yeah, but those Chinese dropshippers don't have significant local presence. If they are caught doing shady stuff they'll just let their $100 letterbox company go bankrupt and start over.
You, on the other hand, would actually have to pay whatever fines some regulator charges you with, because you are physically present in a jurisdiction they can apply power to. This makes self-certification a bit of a footgun: you essentially pinky promise that you fully understood all the relevant rules and regulations, and otherwise pay what in the worst case might be a hundred-thousand-euro fine. Quite a bit of a gamble!
The main saving grace is of course that the authorities are way too busy to investigate some random guy selling a handful of devices from his kitchen. But get too successful, and some competitor might just decide to give them a little hint on exactly what part you missed because you didn't even know you had to comply with it.
Hardware isn’t hard if the hardware is easy? There’s very few components, one of which is a pre made module, and it took 3 years to make essentially a text logger.
And the RF is a pre-certified module. Of course hardware is easy when you've offloaded the hard part to the supplier. Not to mention, a three year turn around? For this? Three months, six max with mistakes and reworks would be industry expectations "pre-LLMs". Everything is easy when you have 6x to 12x the timescale your competitors expect.
"Do things that don't scale!" is standard founder advice for a reason. The fact that no one else has put in the work means you get to sell $150 MIDI recorders... for a while. Which, fair enough, might just sustain a one-person business.
Yeah I mean this hardware isn't hard because its a fricking breadboard.
(Although I spy an SD card slot, a favorite of the "hardware isn't hard" faction that will explode in their face)
Seriously, microSD cards are the second worst hardware component to have to deal with (first being labels). For being a "standard" you end up with cards that are subtly but significantly different from each other, the slots are ALL poorly designed, and microSD cards are just inherently unreliable. Plus with the current flash shortage, the major manufacturers don't care at all to support any issues with the product.
I'll be sticking around in the comments so feel free to ask questions. AMA!
What are some examples of good anti-counterfeit strategies? And, if you’re comfortable, which applied for JamCorder?
+1
The number that stuck out was 200K lines of code. Can you expand on why so much code had to be written and which parts were the longest (time and/or code) and hardest bits?
The app is about 85K lines: device connectivity, first-time setup, syncing, MIDI playback and visualization, library management, audio/video export, and OTA workflows.
The firmware is about 110K lines: MIDI recording + streaming, USB, Bluetooth, Wi-Fi, web APIs, storage, OTA updates, diagnostics, security, peripherals, provisioning, and an embedded web interface.
There’s a lot required to make a full-featured product.
This seems like an incredibly large codebase. Did you use an existing RTOS or something similar for this product, or was this all hand rolled?
What is the manufacturing tooling that you mention?
3 main components: flashing, provisioning keys, hardware testing.
Nearly every component gets tested: sdcard, clock, battery, anti-counterfeit IC, led, buzzer, the tactile-switch!
Yeesh, please tell me you didn't write all of that yourself. Which uC is it targeting, and which language?
From the photo in the link it looks like he's using an esp32-s3.
I suspect that 110k number might include the ESP-IDF libraries as well as his own code.
I've written a fairly feature-complete handheld device based on the esp32-s2 and the codebase is about 9k sloc of the C I've written, but that number explodes to almost 40k sloc if I include the esp-idf's imported libraries.
These numbers do not include ESP-IDF :)
I recognize the "esp32 perched on top of a circuit board" from the picture. I've got a couple of those at my house right now, I'm on the second version of one board and the third of another. I think I'm going down a very similar road for a different product. Would you be willing to some paid advising? I'm an EE so I don't need hand-holding on the actual boards or programming, really just looking for more information on everything else around the edges. Either way, thanks for the article. It was nice to get some validation of my development process.
I can/try to give you some advice if you need - email is in my bio. I did a semi successful CrowdSupply project based around the ESP32S3.
Really cool project. As someone from the software side who is just getting into hardware, this is very inspiring!
How did you find customers?
How did you get your hardware design verified?
Have you considered supporting other MIDI instruments like e-drums and pad controllers?
They should just work! You can replace the soundfont that the app uses with your own too.
Interested. I got far emough on the site to have a couple of questions. (Maybe the answers are on the site?)
1) Does device record ALL MIDI sent to it? (Including e.g. SYSEX and non-registered parameters?
2) I edit MIDI on a Desktop (NOT a phone). a) Are sessions recorded into separate files? Named and/or dated? b) Can I inspect & load sessions from the card?
The website gives a very nice and captivating intro to the device.
But why do you spell MIDI in lowercase there?
> plugs into your piano via midi
The marketing answer: all lower-case looks modern and opinionated
The real answer: I got tired of deciding what should and shouldn't be capitalized. Sounds easy but it gets ambiguous fast.
I'll revisit this decision at some point. Capital letters do make reading easier.
>>> Have a strong anti-counterfeit strategy. Don’t overlook this.
Can you expand? What counterfeits do you see (literally someone selling boxes labelled jamcorder? How do you handle that? Lots of scanning amazon and sending cease desist letter?
Is the app Apple-only?
Android too! Built with Flutter. Flutter is great highly recommend it.
Congrats! Happy for your success. Your mix of ingredients is impressive (the hardware alone is probably simple). Your product idea came from actual personal need (validation!), and you are able to tie the hardware to your software to widen the moat -- which is great.
Your anti-counterfeiting tech hopefully / probably prevents your Chinese manufacturers / suppliers / related entities from free-riding on your work. (If your volumes start hitting say 50K+, things may change, you may be entering dangerous territory then, so I'd suggest you spend some time on beefing up the moat).
Good luck towards 10K volume!
I think "hardware is as hard as you make it" would've been a better title. The author made the smart decision of keeping things very simple on the hardware side, and that happened to be possible for the kind of product he wanted to make.
Interestingly I've heard a very similar story and sentiment about hardware vs software from another single-person maker (also a software engineer by trade) of a hardware product, also in the music space. And this one was comparatively a more complex product on the hardware side, and did face some supply challenges during covid and tariffs, forcing at least one redesign and price raise. But in both cases, I'd say they made smart choices about keeping the hardware simple. By not pushing the envelope on that front they gave themselves the freedom to invest a lot of time and effort into the software. But not every hardware product is like that (which the author also does acknowledge).
Hardware is hard! Because of certifications and organizations like the WEEE. There are many different acts for electronic devices world wide. In Germany you have to spend about $ 20k per month even if you did not ship any product yet - just for regulations, certificates and things you have to register for to be able to sell a electronic device.
That makes hardware hard! The manufacturing and packaging is the easy part.
How did you market it? I'm trying to get into my own production stuff and I don't want to participate in the parasitic Amazon or overcrowded Etsy ecosystems. Looks like you're doing sales through your own website, which I want to do myself. But I haven't yet figured out how to bring legit traffic to my own website. I don't have money to throw at advertising and that's a minefield of fake traffic anyways. Any advice to share please?
> Have a strong anti-counterfeit strategy. Don’t overlook this.
Would like to see this highly non-obvious point expanded upon.
Long time customer! I bought one after your original post on HN. Congrats on the milestone. Honestly, it's such a good product and I'm such a bad and inconsistent piano player that I completely forget it exists for months at a time. Then I remember about it, open the app, and everything is there: my attempt to figure out a song, my kids smashing the keys as hard as they can, my cat walking across the keyboard. It's such a joy.
I've had a Jamcorder for 2 years on my digital piano, have been learning to play. Love the tracking data on the calendar and playback. I plugged it in and it's been running and updating itself perfectly the entire time. Thanks so much Chris
Part of the reason I wanted this in the first place was to have the data, a few hundred hours of all my learning and playing. At some point I or someone else will start thowing all this midi into an LLM.the jamcorder has been saving everything I've played in a very tiny amount of space with no effort by me, ultimately will be even more useful.
I've been using an Anatek Pocket Record for the past 34 years. Bought it when I was 14. That's value!
https://www.izcorp.com/wp-content/uploads/pm_Pocket-Record.j...
Yes I've seen a few people mention that! All of the best MIDI hardware recorders are ancient, for whatever reason. Well, apart from Jamcorder ;)
The audio hardware industry is much more easy due to the gear addict people buying up everything.
Hardware's reputation derives from the reality that a lot of companies spin out the hardware before the software is even written - so all hardware bugs have to get fixed in software.
Yeah, hardware is indeed not too hard if you have a trivial hardware project and ignore all the hard stuff.
Complexity-wise this is probably the easiest board one could imagine. It's an off-the-shelf MCU module, a 1:1 copy of the MIDI circuit from the specification, and some ports wired straight to the MCU. Throw in a trivial I2C-connected RTC and HSM for good measure. You could probably design this in an afternoon. But indeed: that is a good thing. Not everything has to be complicated, and plenty of people are willing to pay for simple products.
On the other hand: what is the cost for that?
The USB-A Host port has ESD protection, but as far as I can tell MIDI Out and SD do not. Sooner or later this will result in some static-prone user frying their expensive board. Have you got a proper Customer Support / aftersales pipeline yet? How many units did you reserve for warranty replacement? Luckily you've got a huge margin, so a few replacement boards shouldn't bankrupt you.
Similarly, the MIDI ports seem to be using low-double-digit series resistors for the MIDI Out current loop - in 0402 form factor. As the spec says: short the port and they'll draw over 0.5W, which a 0402 can't dissipate. To be fair, the exact circuitry is a bit hard to tell from the image, but will this mean they'll catch fire?
The AMS1117 is also an interesting choice. It's a classic option so it is often seen in beginner tutorials, but it is absolutely terrible[0], and with the capacitors used you shouldn't be surprised to eventually run into stability issues. It might work Just Fine for 99% of units, but the 1% will have weird undiagnosable heisenbug issues.
From a UX perspective I'd also question the use of a coin cell battery for the RTC: it'll eventually run dry or even start leaking. A supercap would've been a more durable and convenient option - especially considering the "always leave it plugged in and forget it" use case. Or, if you need a battery anyways: go for li-ion so it can be used on-the-go. Similarly: USB-B for Power In in 2026? That's just lazy. USB-C is trivial to add with a 5-minute-guide and would've been cheaper. The USB-A Host port is just about excusable, though: doing that in USB-C is a bit harder. And the Power In port not being usable for a connection to a host PC and telling people to buy some sketchy adapter on Amazon? Understandable considering the MCUs peripherals, but a disappointment.
And then there's the elephant in the room: certification. It seems like you just... didn't? Which is understandable for a small hobby project! But making it EMI/EMC compliant is by far the hardest part of designing market-ready products. You can't just completely ignore all the stuff involved in making it compliant with FCC/CE/UKCA/whatever rules and call it "not so hard". It's the difference between baking a pie for your birthday party, and opening a bakery.
Your hardware project wasn't hard because you've only done the easy stuff. And kudos for shipping - many people don't make it even remotely this far. Especially using an injection-molded housing is quite the achievement! The startup costs for that make it a real showstopper for many small-scale projects, and making mistakes can easily bankrupt you.
But this is where the actual adventure starts: scaling it to 25k / 250k units. You basically have to start from scratch and do 10x as much work. Meanwhile, China is pumping out $10 clones for your $250 recorder. Sure, you put DRM in it, but is your software moat really wide enough to protect you?
Many congratulations on your achievement, but please understand that writing this blog post is almost naively premature. The hard part hasn't even started yet.
[0]: https://www.reddit.com/r/esp32/comments/1m7ne4i/psa_avoid_us...
I appreciate the critiques!
First, so far, there have been 0 failures in the field. My email address is on the website, the app, and the first page of the instruction sheet, so I'd probably know if there were.
But since it's fun, I'll address some of these :) I'm not flying by the seat of my pants here as much as you expect.
- The ESP32-S3 includes ±2 kV ESD, which is respectable. Adding more is a bit precautionary IMO, but I did add it in some places where the user is more likely to touch metal (like the USB ports). The sdcard's metal housing is not exposed.
- The AMS1117 is just more available than the alternatives. Again, no failures yet so seems like the right tradeoff was made here.
- Supercaps don't last long enough for my liking. A CR2032 can go for 10+ years. A supercap, only weeks. I want correct dates even if the device is left unpowered for months.
- The 0603 47ohm resistor is a good callout. Worth beefing that up. But at 3.3v and 232 mW it's not a fire hazard. It will fail open.
- USB-B for power was very intentional. It's a great firm connector and more importantly prevents users from plugging it into their piano wrong. Many of my customers are in their 70s or older.
- USB-A for data was made for manufacturing simplicity, but again, USB-C is too complicated for many of my users. I'd only switch to USB-C if both ports could be used interchangeably, but they can't be / it's not worth the complexity.
- As for the software moat, time will tell. You can't stave off competition forever!
- The device is FCC and CE compliant.
Again, I actually do appreciate your critiques!
What was the biggest mistake you made in the early days that almost killed the business?
Spending too long on the firmware. I almost ran out of runway. I should have cut features faster. And I should have built the firmware cross platform so I could run it my local machine. Every compile + flash loop took 2+ minutes.
I don't know what the timeline is here, but to me this sounds like he either got lucky, or he's in the grace period when you begin a project and the strong enthusiasm for it, and the fact people are not seriously trying to copy it yet, work together to make everything just that much easier...
Wow, congrats on this project! Really cool. I majored in piano performance many years ago and will definitely check this out.
It's a poor take to be honest.
I'm an EE with main expertise in IC design but I design a lot of the chip packages, PCBs, mechanical stuff like custom made sockets etc and write a ton of SW, be it tools for myself for development and testing, be it the firmware of the chip I'm designing or another chip I use on the board. For me it never felt like SW was the hard bit, because you can write and test it pretty immediately and pretty much for free. HW felt harder because of the tooling costs, lack of documentation and examples, things that aren't obvious at the beginning (EMI/EMC) etc etc but these are very minor compared to the actual issue: long and expensive development cycles. Now, that doesn't apply if your HW is extremely simple and just a glorified uC and rhe development time is mostly the code running on it. This is why this is such a poor take. One can argue for anything at extremes. SW can be very very complex and much harder than HW, and vice versa at different extremes.
I’m working on my own PCB and it’s my first time working on a hardware project.
Any tips on how or where I could get my design reviewed?
I'm usually not an Ai shill, but I found Fable to be the first LLM that could actually provide useful feedback on a KiCAD PCB design. I paired it with a KiCAD MCP, but it tended to reverting to raw KiCAD scripting. If you ask it to review a PCB design, and provide feedback relevant to PCB design best practices, it will probably give you something useful. I wouldn't trust it to do a full design, but it's pretty good at finding issues. I'd add a few clauses to the request regarding checking components against JLCPCB/PCBWay/etc available components, as well as checking copper layer thickness and distances from the main components to the supporting components.
I did this as an experiment on my current project and it found a bunch of minor, non-critical, but completely valid problems with my deisgn.
If you're building with KiCad then I've found the folks on the KiCad discord[1] very willing to take a look over a design and provide feedback. There's also a subreddit[2] for PCB design posting and review, but I haven't personally used it.
[1] https://www.kicad.org/community/chat/ [2] https://www.reddit.com/r/PrintedCircuitBoard/
Congrats. I did want to respond to this
>>> The hardest part of building Jamcorder was still, by far, the software -- roughly 200K lines of code spread across the firmware, app, and manufacturing tooling. It took over 3 years and many long nights in a pre-LLM world.
>>> When compared to that, the hardware was undeniably smooth sailing.
>>> For the record, I don’t think I’m special. It’s just that hardware’s reputation for being difficult is, IMO, overstated.
For me, when I complain about hardware, its actually usually complaining about drivers, compatibility, underdocumented interfaces, firmware etc. If one were to put firmware and manufacturing tooling in a separate bucket, that is indeed the problem!
> strong anti-counterfeitting strategy
The reality for a product at this scale is that nobody is going to spend the time or money to copy it.
I thought 'hardware is hard' is a VC statement to apply a broad stroke for why its hard to make succesful hardware companies (that gives 100x returns)
For reasons other commentors have already mentioned-scale, logistics, revisions. And for reasons they havent mentioned-cash flow
Vast majority of the hardware, especially as it's running on ESP has already been done for you
>Assembly is just a single screw, for a single PCB. The injection mold has generous draft, no slides.
Says everything
The article doesn’t mention certification, which is expensive and demanding, but required for any product containing a radio to be legal to sell.
Congratulations! I bought one after reading your post on here announcing it. It's fun to mess around on my keyboard and be able to go back and listen to what I played. Great for learning
It's not that hardware is simple, but the fact that we have inexpensive micro-controllers that pack a giant amount of complexity and let us turn a lot of electronic problems into software problems.
Try building such a device only with non programmable TTL logic.
I am also on a similar boat. After writing softwares for almost 13 years now, I am now working on a privacy focused and universally compatible casting device.
Would love to talk to you more about hardware supply chain issues and challenges.
Meanwhile if anyone is tired of their smart TV being a spyware or showing ads, I would love to talk to you. This is what I am building: https://soljacast.com
I have a old keyboard (Ensoniq SQ1-Plus) where the battery doesn't work right (even when changed) and I was going to put ML Studio on a Raspberry Pi or Mini PC with a USB MIDI device to record. But this thing is exactly what I'm looking for.
When I want to record for real, I'm going to use my DAW. But I want a way to quickly record tracks and this looks pretty great.
> Have a strong anti-counterfeit strategy. Don’t overlook this.
Would love to hear more on that but I suppose the omission is not an accident.
Love the breakdown here. It's refreshing to see someone build a physical device instead of wrapping everything in another app.
I hope the author can break down the recommendations in a future post. I'd love to learn how to build this kind of hardware (what tools are needed), how to iterate on the results, how to find a supplier. Also it'd be interesting to know what the author means by having an counterfeit strategy.
Interesting that is has ESP32 in there - looks like it's becoming the default choice whether or not wireless is involved.
This is cool! Thanks for sharing.
What understanding about hardware did you start with, and what tools did you use to learn what you didn’t already know?
I started with having watched ~100 hours of EEVBlog :)
Electronics, PCBs, CAD, injection molding was all new to me.
I'm in the middle of my first hardware project right now and I can recommend the videos on the "Phil's Lab" channel on YT. He mostly uses Altium, but he has a few videos on KiCAD which really helped me. He also has generally good throwaway comments in his videos with regards to PCB design / component placement, as well as the order of operations for good PCB design.
The only problem I have with these tutorials is that they're already outdated... I don't think anyone covers kicad 10 yet, and its quite a bit different than 9. (Individual dialogs might not have changed, but where they're located etc might have)
As always, "It Depends™".
There was another post, a year or two ago, about someone that really tried to manufacture a webcam, and gave up.
I spent my career at hardware companies.
Glad this worked out, but past performance is no guarantee of future success...
What was your anti-counterfeiting strategy? That sounds interesting.
I'm using an STSAFE chip - the same IC they use in StarLink terminals. Essentially the digital equivalent of a holographic barcode. I have some other protections too. e.g. Random 128-bit per-device IDs / product-keys. iMessage uses this strategy.
Maybe I'll write an article about that.
Sounds like that'll be a great read.
This is (literally) none of my business, but would you consider a cut down or basic open source version (hardware and software, with open software running in the proper hardware). Yes it'll be cloned by factories, and yes it will cut into sales no matter what proponents claim. (And yes it's probably more work than I imagine it is).
But also yes, it'll be genuine open hardware and might out live your interest in the project.
Reading your comment it sounds like you're asking the author to do more work to potentially/likely undercut their own sales. They are already offering a quality device at a reasonable price without any untoward restrictions.
If you want a Free work-alike, why don't /you/ put in the work and make it happen?
How do you verify the ID? In the software? What if the software is hacked? I'm curious how this can be safe.
Please do! Trying to imagine how this works.
Yes, please do!
Please!
Please do, that'd be very interesting. I imagine it's doable to use random per-device I'd when you're hand-flashing, but probably harder on a huge production run.
Almost all commercial devices need a unique ID, private key, etc burned in on the production line. For a big enough production run, you'd likely ship an HSM to the factory
IMO it's better to ship preprogrammed ICs to the factory, so you can do your secure burning in-house.
Depends on where the ICs originally come from. No point shipping your ICs from China -> US, flashing them, shipping them back US -> China for assembly, and then ship them China -> US again to sell
Yet people do this all the time. Ask me how I know.
Can reply to the reply below but yeah, i have done that, lol
> For a big enough production run, you'd likely ship an HSM to the factory
I figure that the factory is exactly the adversary in the whole threat model? So why give them the keys to the castle so they can moonlight their own genuine batch?
A few ways, if I understand them correctly. On-site people you employ (if you can afford it) auditing the process, connectivity to the HSM to record every key assigned (makes it easy to trace duplicated keys to their origin), and ideally assigning these keys at the very last possible step after the rest is assembled (to minimize 'defective' parts wandering off and being assembled elsewhere).
Yeah, it's important that your own people are doing regular inspections of the production line, keys get burned at the final station (use temp keys for QA stages before that point), and you retain software control of the HSM.
You probably aren't going to do this whole rigmarole for small runs of devices like in the OP.
> Almost all commercial devices need a unique ID, private key, etc
Serious question: why?
You want a unique ID so that you can track which units are experiencing issues, you want private keys to be able to securely connect to your backend service and/or mobile companion app.
A local-only device with no telemetry can probably skip some of those
From a financial perspective, what were your biggest challenges? What was the working capital cycle like? Were you forced to do a certain level of minimum order quantities and did the cash constraint limit other decisions?
500 units was my first run, and it worked out really well. None of the suppliers complained about that order size. I recommend starting with a smaller quantity until you've validated the market. The "economies of scale" between 100, 500, or 1000, units are not all that dramatic. Perhaps 30% cost difference.
I was originally planning to do 4000 units as my first run. Boy I'm glad I started to run out of money and cut it way back. That would have been way too much as a first run.
This is not a criticism but I am curious about what the trade offs are in terms of cost/bom etc of using usb-c. I found it surprising that that wasn't a given in 2026,curious where it hasn't caught up as an option.
Assuming this is just standard 2.0 speeds, it should be nothing. It adds a slightly more expensive connector and 2 resistors… and that’s it.
If you consume power over USB-C, 2 resistor are enough.
But for providing power over USB-C, you generally need a dedicated IC to handle VBUS switching. It wasn't worth it.
Also, once you ship a consumer product with a USB port on it, you'll realize a lot of people really don't understand how USB works, and USB-C doubly so. Square holes for square pegs goes a long way.
Sure, but your power input should be a USB-C. No reason to use the clunky USB-B for that. Labeling as Power In and leaving a regular USB A for the output seems fine to me. Given that most older keyboards use USB-B for their input, A is a perfectly fine solution and solves the “input vs output”.
These are the hardest cuts to make in design, being so incremental, but they add up!
the amount of crapping on the author that I'm reading bothers me.
whole lot of manufacturing experts on HN today.
Great write up!
Why custom MIDI connectors of all things? What requirement couldn’t be met off the shelf?
Not technically custom, but made to order (I gave them a spec sheet). If they had reasonably priced connectors on LCSC or DigiKey, etc, I would have used them!
I can't wait for ASIC manufacturing to become as easy as ordering a PCB.
Unlikely to happen any time soon. The problem is mask manufacturing costs: you spend a lot to make a set of masks, but after that making the chips is incredibly cheap. Great for mass production, not so great for prototyping. And there's a lot of proprietary 3rd-party IP involved in chip production: fabs are not very eager to make that publicly available. Heck, even FPGAs are still mostly proprietary!
That doesn't mean it is completely impossible, though. Fab2 (formerly Atomic Semi, of Jim Keller and Sam Zeloof fame) is trying to do exactly this by aiming at making small-scale production affordable. The trick is to replace the whole mask-based lithography with electron beam scanning: way slower, but no mask costs.
But they are now targeting selling mini-fabs to R&D labs rather than offering an affordable ASIC-as-a-Service. Let's hope one of their customers makes it available to the public!
We’re at approximately where PCB pricing was 20 years ago, which _is_ a big deal: https://wafer.space
Very very cool!
It’s actually not hard to hack this together as a .net application and run it on a laptop, but I suspect your target market has a bit of money to spend.
Learning piano is already largely an upper middle class active and after that what’s another 200$ or 300$.
A higher end digital piano is easily over 2k.
Making sure your target market has money is the key take away.
Not sure if this is in scope, but I’d love an easy way for the community to share midi files. I can somewhat do very basic piano progressions, but I still can’t play well.
I’d be grateful if someone would share midi files for me to plugin to my music software. Of course I’d provide full credit
That's a super interesting device. Definitely pondering ordering one.
Good to see some hardware love! Congrats on hitting 2500 units. How’d you decide to make the first jump and actually build your first prototype?
> Have a strong anti-counterfeit strategy. Don’t overlook this.
Sounds like a story. What parts of it can you share?
Yeah, I'm working on a hardware project and would like to know more about this.
> Have a strong anti-counterfeit strategy
What is this strategy? You're building this in China, it's already over.
I would assume the 200K lines of software and the firmware is presumably flashed after receiving the product from the assembly house.
The anti counterfeit strategy is that the volumes here aren't worth it for someone to clone, even if the board and code are dead simple.
These niche hobby products are usually reasonably safe because they rely on community network effects, becoming the darling of a random subreddit or discord group and people aren't going to save $20 to get some device of dubious origin.
> Have a strong anti-counterfeit strategy. Don’t overlook this.
Hope we can read more about this.
I would be curious what “ Have a strong anti-counterfeit strategy.” looks like in practice
Does anyone know what kind of anti-counterfeiting techniques he used?
Another happy customer, bought two Jamcorder units. Not just the hardware is simple, the software as well: it just works, quietly in the background. I just had to enable daily auto-reset otherwise it eventually had issues. Whenever someone starts playing piano, it records. The iOS app is so nice, playing back on the phone or on the piano, and keeping track of total hours played and organizing favorites. Congrats, if only more projects kept things simple and useable!
Reading these kinds of stories always make me happy. Well done!
Ok are you riding with two huge boxes containing all your work on an electric unicycle and I guess the hi-vis top means you're headed into traffic and the box-cords seem to be balancing at the halfway point of the boxes and this is too much anxiety for me. But hey, glad you optimized for minimalism on the PCB ♡
Ahah good eye. It was only 4 blocks down the road! I too was surprised by how well a single cord worked to balance the 45lb boxes.
I've been wading through comments (offering upvotes) looking for comment on this photo. Excellent inclusion. Very fun. People are great!
> 3. Partner with a Chinese assembly house and suppliers. Alibaba is your friend.
Oh, if that’s how you build hardware then sure, hardware isn’t hard to do at all.
How is fulfillment not a nightmare?
It sort of is. I'm at an annoying scale where most 3PLs don't want to deal with me yet.
At the same time, it doesn't take much time at all, and is a good excuse to get out of the house!
That is 3pls in that context?
3rd Party Logistics, apparently
Thanks!
Very much appreciating the sentiment in the article.
Is it just me, or is there some kind of unusual photo editing going on in the photo at the bottom of the article? Something looks uncanny valley, related to the bottom of the box on the left side of the photo, and related to the background. Did some kind of "erase background" mechanism go wrong here?
Nice.
If I may ask for your advice on a related subject.
I have an old electric piano, it doesn't register dynamics, the strength with which I hit each note. Which is a huge bummer.
I can't think of a simple way to hack dynamics onto the keyboard, I thought of adding an additional sensor and using the time delta between touching a key and hitting the bottom, but that's not really correct, as you can hit a pianissimo key fast in staccato.
Maybe a basic spring that decreases resistance as it becomes compressed, but it might make keys quite hard, and it's not very simple to implement.
Any ideas?
Thank you.
As usual for these posts. No certifications. No proper markings. Probably non compliant. Will probably go unpunished.
>>Now, granted, Jamcorder is -- very much intentionally -- a simple device. I get that.
And let's not forget that. And let's not just follow the headline.
Greetings from a hardware engineer with decades of experience building hard things.
This is so weird. I was in the process of trying to build something almost identical! Congrats, and good luck! I'll have to buy one now.
This article did not mention anything about the prototyping process (dev board, breadboard, perfboard?). @chipweinberger, please fix.
Well, hardware-wise you made equivalent of hello world project so of course it is not hard in absolute terms (not to piss on your parade, it's a very cool project, just to have point of comparison).
Just that hardware equivalent of 200K of lines of code would take far, far more time and resources and with way longer debug cycle, especially when you hit the complexity point where bodging few wires to fix the prototype gets harder and harder.
That's what people mean when they say hardware is hard - if you need to start iterating on a board and not just board's software it gets complex and expensive really quick
But it is far better than it was before - I got my 5 board prototype of similar complexity (also esp32 based) within a week, assembled board, for like $100 (and it was my design mistakes that made it so expensive, like picking screw connectors in places that could totally use far cheaper generic part JLCPCB had in stock, i just didn't know any better), just a decade ago that would probably be order of magnitude more expensive.
So yeah, for those that always wanted to build a hardware project, it's probably best time in the history to do that. Both PCBA and mechanical part got cheap and commoditized enough.