• Part 1 : Planning 
• Part 2 : Hardware configuration
• Part 3: Manual testing
• Part 4  : Software UI and testing
• Part 5 : PCB fabrication
• Part 6 : 3D printing
• Part 7 : Final integration

Absolutely.

In today’s world, the art of making has never been more accessible. You don’t need a degree or a big budget. All you need is curiosity, persistence, and the willingness to learn as you go.

I’ve been building things for as long as I can remember. We grew up poor, and as kids, we made our own toys, and maybe that’s where the passion for building started. Over the years, I picked up carpentry, shoemaking, and jewelry-making, among other things.

But for this piece, I want to talk about making gadgets.

Last year, when both Fido and my mom’s health began to deteriorate, I wanted to build specific health trackers. But Fido got too sick too quickly towards the end. Thankfully, my mom’s health has been improving, and since I won’t be around as much next year, I thought it was time to build it for her.

When I first started working on this, I over-complicated everything. I thought the tech had to be fancy to matter. There are already so many health trackers out there, so what makes mine special, right? I had some familiarity with wireless engineering, so I figured bumping it up from milli to nano wouldn’t hurt. Turns out, graphene is a complete bitch. Expensive, finicky, and for an indie builder on a low budget, it’s the perfect way to get stuck before you even begin.

Then I read about how Jack built Bitchat in two days. It was so simple yet functional. It reminded me how easy it is to complicate things and how much harder it is to simplify. So I took a step back and instead of worrying about the market, I focused on the use case: our parents.

That shift led to a much simpler first prototype and cost me < $50.

I’m also going to build a drone with my 13-year-old twin nephews. Austin loves aerospace, and Ashton is obsessed with cars. And that’s just it. There is no age or talent requisite when it comes to building. You can build anything. A voice-activated home assistant. A heat-recycling miner. A Chitty Chitty Bang Bang breakfast robot. Or a health tracker for someone you love.

And all of this is possible mainly because of the open-source community in both hardware and software. Mine relies on Esp32, Arduino breakout boards for hardware and Goose for software. 

There are many ways to prototype. I’ll walk you through the one I took, including the mistakes I made, so you can skip the drama and focus on building.

There are 7 parts to this :

1. Planning

2. Hardware configuration

3. Manual testing

4. Software testing & UI design

5. PCB fabrication

6. 3D printing

7. Final integration

§Part 1 : Planning 

First, decide what gadget you want to build. For example, say you have a Proto Rig and want to set up a mining system, but you also want to take it up a notch. If you live in a tropical country, residential rooftop solar panels can generate around 5 to 6 kWh per day, and for industrial setups, systems between 12 kWp (single-phase) and 72 kWp (three-phase) are typical. You can also build your own tools to monitor power efficiency between solar and the grid.

Then there is the heat from miners. You can build a simple gadget with thermocouples or temperature sensors to read both miner and room temperatures. Add relays, MOSFETs, or PWM switches to drive fans, pumps, or manage airflow and AI can help optimize the system over time for better efficiency.

If you live in a cold country, the approach changes slightly. You can measure the heat and redirect it to your home or greenhouse. It will not heat your entire home, but it can offset heater use and lower electricity bills.

You can also turn heat into electricity and store it in a battery for later use. For this, you will need thermoelectric generators (TEGs) or a heat engine with a generator. Once electricity is generated, store it in lithium-ion batteries or supercapacitors. There will be some efficiency loss, but experimenting with that is part of the fun. Creative problem-solving is where we learn and innovate. 

So for Step 1: Planning, go wild with ideas, research, and figure out what works. Once you have a decent plan, we can move on to Part 2: Hardware Configuration.

§Part 2 : Hardware configuration

When people talk about prototyping, you’ll often hear three names: Arduino, Raspberry Pi, and ESP32.

Raspberry Pi** **is a microcomputer. It has its own operating system and can run more complex programs. You can use Python, Node.js, or Java for things like AI projects, Bitcoin full nodes, or smart home hubs.

Arduino** **is low-power, has limited memory, and is best for controlling hardware, which makes it ideal for IoT devices. It has no OS and runs on C/C++ or Arduino’s simplified language. I mainly use it for sensor control and its IDE. Qualcomm recently bought over Arduino, so there may be changes ahead.

The ESP32 microcontroller** **, made by Espressif, is the brain of many systems. It’s a single chip with processing power, memory, and built-in wireless connectivity, which is great for beginners and quick prototypes.

Because they’re mostly open source, you’ll find a lot of clone breakout boards that are cheaper and easier to get outside major tech hubs, as the goal is to make innovation accessible to anyone, anywhere. Or you can also buy directly from the source if you prefer.

§Brain

Any company can take the ESP32 and build its own board around it. I went with the T-Display-S3 (ESP32-S3 + LCD) by LilyGO . I like the fact that a woman founder (Lily), built a whole range of gadgets around this.

My device has WiFi and BLE, costs about $15, and includes a JST connector for a lithium battery plus two header extensions. The LoRa version is around $10 more, and the touch screen adds another $10. Prices vary depending on location, shipping, and which government decides to hike it up.

If you want to try Bitchat over LoRa, you’ve got a couple of options. The simplest is to use a board with LoRa built in so your messages ride directly over the radio. From there, you’d just need to modify the software to integrate LoRa into the transport layer. Bitchat’s modular protocol makes this easy to extend, and it’s a fun way to explore long-range, low-power communication for your project.

§Power

During development, you can power the ESP32 directly through your laptop, so do invest in a good USB-C cable for programming and debugging. I had to swap 3 out.

For standalone use, I used a 3.7 V 1000 mAh LiPo battery (about $5), which gives roughly 6–8 hours of runtime.

My first prototype runs on a breadboard with a T-Display board that already includes a charging circuit and voltage regulator down to 3.3V, so power is handled out of the box. My second version of my prototype uses a custom PCB daughterboard that plugs into the T-Display, so we’re still good.

But once I move to a fully custom device with an integrated ESP32 and LCD panel, I’ll need to add my own charging circuit (like a TP4056) and a voltage regulator. This matters because USB supplies 5 V and LiPo cells can go up to 4.2 V when fully charged and we don’t want components acting up.

Also the opposite is true. Don’t let LiPo batteries drop below 3.2 V if you want them to last.

§Sensors

For both the health tracker and the drone, I needed an accelerometer and a gyroscope, so I used the classic MPU6050 (around $2). These come as breakout boards, meaning each sensor IC already has a stable circuit built around it and can be used standalone.

To measure heart rate, I added a photosensor with an LED that beams light into the skin. A photodetector measures how much light bounces back, and those tiny variations reveal your heartbeat. For my daughterboard, I’m adding a skin interface to make the sensor more accurate.

There are hundreds of breakout boards available, which can turn sensor shopping into a fun little spree. I added a few low-cost ones ($0.50–$3) for elderly-specific use cases. I’m still tempted to add more, but you have to weigh manufacturing cost, circuit complexity, and software load.

If you’re unsure which components to pick, you can ask an LLM, Google it, or go old-fashioned - browse Reddit, watch YouTube tutorials, and read project guides.

For anyone looking for ideas, this is a decent resource

§Movement

If your device needs movement, you’ll need actuators. Here, it’s often an integration between mechanical and electronics engineering. For my nephews’ drone project, we’ll use DC motors with propellers, each connected to an ESC (Electronic Speed Controller) to regulate speed.

For robotic arms or claws, servo motors with servo horns or RC linkages are perfect. I’m also testing a small locking mechanism for another prototype. I haven’t mastered mechanical engineering yet, but it’s definitely on my list of interests as there’s so much you can do with it.

This might be a fun revisit

§Prototyping

To bring your circuit to life, the easiest way is a breadboard. You’ve probably used one in school. The top rails carry power, the vertical columns handle components, and the gap in the center keeps your T-Display from shorting across both sides.

I may be on a budget, but like they say in Tropic Thunder, never go full cheapskate. 

My $2 soldering iron couldn’t hold temperature and was glowing red. I upgraded to a proper soldering iron with the full set : holder, wick, and multiple fine tips. This came in handy because the T-Display header sits sandwiched between the PCB and LCD with only 2–3 mm of clearance.

The breadboard ensures your circuits, connections, and software work correctly.

Once everything checks out, I will move to a smaller custom PCB, the daughterboard. My mom will test it alongside the T-Display and I’ll use her feedback to upgrade to the next version and the next, until the product is decent.

§Testing tools

I used to be a tool snob. I had the whole stack: spectrum analysers, network analysers, oscilloscopes, and very expensive multimeters. But indie building humbles you fast. I thought I could skip a multimeter and MacGyver my way through a simple series circuits to validate signals, but there’s only so much hacking you can do.

I eventually bought a DT-830B for $2 (the battery cost more than the meter). It doesn’t beep for continuity, but reading values works fine. You can watch how to use it here

For jumper wires, I prefer solid single-core (from the breadboard pic above) over Dupont cables (pic below). Duponts look pretty, but are flimsy and slow down debugging. Pre-sized solid jumpers cost about $1.50 for 140 pieces and are plug-and-play. Or strip your own wires if you’re old school

§DIY fixes

A few home tricks helped too.

If you have unused nail polish, you can brush it on exposed wires for insulation. A soaked dish sponge is great for cleaning the soldering tip. Egg cartons can be your screw organizers. And I always kept a magnifying glass and tweezers nearby. 

By the end of Part 2, you should have your brain, sensors, power, actuators, and prototyping setup ready. Next step: Part 3 : Manual Testing.

§Part 3: Manual testing

Now comes the part where you find out if your creation wants to live or throw a tantrum. We start by wiring up the T-Display-S3, hoping nothing smokes, melts, or goes “pop.”

§Wiring up

You’ll want your pin diagram for this. The T-Display pins are picky little things, so it’s best to stick to 3.3 V to avoid overloading. If you’re pushing the limits on SPI or I²C, adding a 4.7 kΩ to 10 kΩ pull-up resistor helps stabilize the signal.

This is where Goose becomes handy. You’ll need to install drivers for your T-Display and sensors, usually available on Arduino or GitHub. Goose can read local files, which is a superpower when you want to map out pin connections quickly and accurately. The T-Display exposes 24 pins, including power, GND, and GPIO outputs. I’ve used about 10 so far.

§Power check

I began by making sure the power actually worked. A voltmeter comes in handy here. First, measure voltage from the extender pins, then cross-check the jumpers after plugging them into the breadboard. Once power flows, most sensors will give a tiny blink of life from their onboard LEDs. That’s your little victory moment.

§Sensor testing

Next is testing your sensors one at a time. You can get Goose to write a minimal test sketch and upload it through the Arduino IDE. For my accelerometer and gyroscope, I opened the Serial Monitor, moved the breadboard, and watched the X, Y, and Z values shift as I tilted it. You can run as many detailed tests as you need to match the precision and accuracy of your build.

Most sensors have either libraries or circuits that are well known, so this will be a fast part. 

§Button testing

I planned to add two soft buttons to my device, so I mimicked it with two square push buttons on the breadboard. Buttons don’t have polarity, but you do need to wire them right: one leg goes to the GPIO pin, the other to GND.

For my PCB, I will use a two-pin button instead of a four-pin one, so something to keep in mind is that you might make changes between the breadboard and PCB. 

I’m still deciding between a touch sensor and an additional button. My mom will be testing it to see which gives a better experience, which will help guide the final design.

§LCD pin mapping

By the end of this stage, I had verified every pin, tested every sensor, and stared at the board like it might just start levitating. This is also when the LCD pins need to be correctly identified. If you’re using LilyGO, the mapping is well-documented. Otherwise, pull out your schematics , trace each GPIO pin, and follow the signal.

§Integration sketch

Once everything lined up, I got Goose to write a basic sketch that tied all the sensors together. When it ran and everything responded, it was that little moment of magic. I thought, holy hell, we’re gonna pack this baby up.

That’s also when the next beast arrives, Part 4: Software Testing, building the app, and making it all actually do something.

§Part 4  : Software UI and testing

§

I’m not going to lie. I had a full meltdown here. I cried, made tea, and came back to it.

I’m a hardware chic through and through. In the past, I picked up a few coding languages just enough to debug, mostly because when I did system integrations for large companies, I tried not to piss off software engineers. Only recently, through vibe coding, did I start to appreciate programming.

I find Goose particularly helpful. I’ve built about ten tools with it for both work and daily life, and a few friends use them too. There are so many use cases that my friends and I talk about. One friend needed to find ten million in budget savings and a wild spreadsheet, but needed full privacy. Another builds games with his daughter. I started a recipe side project with my mom, and I’m working on a protocol on the side. You can build anything.

If you want the proper explanation of Goose, you can download it here and watch a good intro here.

But if you ask me what Goose is, I’d say it’s like a really good manager. The LLMs are the employees, and like all employees, each one has its own personality and strengths. Goose coordinates them all. Your local files are the office where the real work happens.

So, which are the best employees? If I had to chart them by efficiency and commitment, GPT lands in mid-efficiency and high-commitment. Claude is high-efficiency and low-commitment. Goose turns both into high-efficiency, high-commitment, so I juggle mostly between those two. I’ve not tried Llama or the rest of the gang. Gemini 2.0 unfortunately sits at the bottom. It’s like those people who say ‘trust me,’ and deep down you know you should walk away. But they make everything look so easy that you say yes. Then you get burned.

Goose is free. If you’re paying, it’s for the LLM API. Most people I know already spend around $10–$20 a month on OpenAI, Claude, or Grok unless they’re on an enterprise track. Indie builders, though, tend to be more cost-sensitive. I started with the cheapest option at $5 dollars for Anthropic, but every time an error popped up, the balance disappeared so fast I felt like I was feeding a slot machine. I switched to Gemini to save costs, and it completely destroyed my code. That’s when I stopped and had a good cry because I had not backed it up.

(In the spirit of not over-trashing, I did build another tool with part Gemini through Goose and part GPT, so maybe that’s some redemption for Gemini.)

Now I try to balance free LLMs with Goose. To be fair, if Goose ever profiled me as a user, I’d probably fall under the “pampered and spoiled” category. These days, I do more of the early thought process and get involved in detailed debugging, which I should have done anyway.

If your budget’s bigger than mine, go wild with Goose. Just remember that your privacy depends on the LLM provider. OpenAI and Anthropic don’t train on API data by default, but it’s smart to use separate API keys, sandbox your work, and enable enterprise settings when handling sensitive projects.

§How the code works

Coding is a lot like cooking a meal. Before you turn on the stove, you prep your ingredients. If you don’t have them, you buy them.

First, you initialize everything. Fonts, colors, icons, drivers, the essentials. You either pull them from libraries, grab them from free tools, or create them yourself. I did all three (well, Goose did).

Then comes the pantry, or your database. This is where the ingredients live. I used JSON parsing for this part, but ran into trouble burning it into flash. It would not work with LittleFS, SPIFFS, or FFAT. So for this first prototype, I simplified and stored everything as strings. 

Next comes the cooking itself, the instructions and steps that turn those raw ingredients into a dish. 

The structure of the project follows the classic Arduino and C++ format. There’s one main file, the .ino file, which is like the conductor of an orchestra. It runs the setup() and loop() functions and calls everything else.

Then there are smaller helper files. Think of .h files as the index or menu. They tell the program what functions and elements exist. The .cpp files are the recipes that explain how to actually make each dish. So I kept separate sections for things like tests, sensors, fonts, and UI. The main file just calls what it needs, keeping the logic clean and organized.

This structure may sound technical, but it makes the code easier to maintain. When something breaks, I know exactly where to look instead of digging through a giant block of spaghetti code.

I also added Bitchat into the mix, but kept it simple. It shows a QR code that lets you install the app on your phone and turns the T-display into a second screen. Bitchat is lightweight and flexible. It can be your camping trip communication line, a lost-and-found tool using Bluetooth pings, or, as several countries have shown, a lifeline when networks go dark. My mom travels with her friends, so this feature will help when they’re in different hotel rooms with poor data or Wi-Fi access.

I’m also getting a second-hand RTX card from a former altcoin miner, so at some point I can run my own local LLM. That will let me optimize performance and manage privacy better. I have a few more sensors and features I want to build in, but for this first version, it works just fine. Then I’ll test, refine, improve hardware and software, and repeat until it’s stable enough for mom to use.

Vibe coding makes life simple. The drama comes from the fact that I’m not a fan of programming. I don’t have the patience or emotional tolerance for it. I’ve never dated a coder, but given how consumed I was by this, I imagine he’d be incredibly patient and thorough for all the right reasons.

If you haven’t tried vibe coding yet, you’re missing out. Just start today. Build a tool that fits your work, your lifestyle, or your own curiosities.

§Part 5 : PCB fabrication

Thus far, the hardware part was fun, the software part was dramatic, and the fabrication part… well, a little dry. 

That’s because PCB work follows a lot of standard rules. If there was AI agent like Goose for fabrication, that could turn pin diagrams straight into schematics, it would take away 80% of the load and let builders focus on the creative bits. 

 I’m more familiar with high-frequency ranges, which means tweaking transmission lines for all sorts of fun things on a PCB. You can form simple antennas for Bluetooth, LoRa, or NFC, shape traces into LC filters, capacitive touch pads, or build cleaner power distribution.

For my daughterboard, most of that was overkill. I went back to the basics, spent half a day relearning how to draw schematics, another day completing them, and a bit more debugging. 

What I realised was that PCB fabrication is half skillset and half strategy. 

§Strategies 

The first is the fabrication option. You can either go for bareboard or PCB assembly (PCBA). Bareboard is just a bare PCB with conductive pathways etched in. The catch is that you have to solder all the components yourself. Soldering SMDs usually needs hot air and reflow tools to get clean joints. ICs are more delicate, so precision tips and controlled heat matter to avoid pad lift or bridging. PCBA comes with all components ready for you to plug and play. 

The second strategy to decide is vendor tradeoff. My local fabricator is just 20 minutes away, which makes it easy to speak directly with their engineers and get detailed feedback on my design. But they don’t stock all the components I need, and they are several times more expensive than ordering from China. Local proximity gives insight and faster iteration, while overseas gives cost savings.

The 3rd strategy is board design choice. You can select a single layer which is cheaper or two layer boards that give more flexibility for routing power and I²C lines. And if you’re mounting mechanical parts, plan footprints and holes early.

Here’s a summary of the trade offs : 

• Lead time vs. iteration speed: Local is faster, overseas is cheaper.

• Tooling vs. outsourcing: Doing it yourself requires skill and equipment. Outsourcing raises costs and minimum order quantities.

• *Component availability vs. design flexibility: *You may need to adapt your schematic to what’s in stock or source components at a higher cost.

• Upfront cost vs. future-proofing: Investing in a slightly more complex board now can save you from redesign later.

Now that you have some idea on what your strategy is going to be we can move on to the next step of drawing the schematics.

§Designing

To design the schematic I used KiCad . It’s free, open-source, and works on Windows, Mac, and Linux. It supports full schematic capture, PCB layout, and two-layer (or more) boards. ESP32 footprints are widely available, and the community is helpful. Tutorial videos are widely available as well.

Once you are ready, we’ll go through a simplified PCB Build Process

Step 1: Draw the schematic

Drop in your ESP32, sensors, buttons, and power. Wire them up, run electrical checks, and debug. For my daughterboard, I used header pins connected to the T-Display, which made things simpler. After that you will assign footprints. 

These was one of my earlier sketches.

Step 2: Turn it into a board

Here we switch to PCB layout. The goal is to arrange  components cleanly, keep power traces thick, signals short, and don’t let wires snake all over. Add a ground plane, run checks, and fix red flags. I’ll be honest, this part got a bit boring for me.

Step 3: Export the files

Generate Gerber and drill files, plus BOM and Pick and Place. Zip them up. This is where I’m currently at. Once I decide on a vendor and see how empty my pocket gets, I’ll test the daughterboard.

§Additional tests

KiCad has built-in checks for floating pins or missing connections. Breadboard any critical parts first. It’s easier to fix now than after fabrication. Also If you or your vendors have the components, you can print the board 1:1, and place your real components on it and check if everything fits. It’s the cheapest way to catch mistakes.

§Some PCB best practices

Power rails: Use 3.3 V and GND planes and keep traces short and wide to avoid voltage drops on small batteries.

**I²C Bus: **When sensors are off (open circuit), the pathway can act like an antenna and pick up noise. To prevent this, we use pull-up resistors (typically 4.7 kΩ) to minimally close the circuit without. Also, multiple devices can share SDA/SCL if each has a unique address..

**Group by function: **Separate traces into I²C, Analog, and Digital for easier routing and debugging

Trace widths: Signal: 0.2–0.3 mm, Power: .5 mm or wider

**MCU placement: **Put ESP32 (or other MCU) near the center and keep sensors/buttons at the edges and signals short. This was the mistake I made above. Place power and ground planes underneath to reduce noise

Component sizing: Stick to standard 0805 SMDs for easy hand-soldering. Smaller parts are cheaper but harder to work with

Nobody nails it on the first try. So don’t be too hard on yourself.

Now that we have a good idea of the PCB part, it is time to move to the outer layer. Part 6: 3D printing.

§Part 6 : 3D printing

§

At this point, I don’t need a 3D printer yet, but it’s been on my wishlist for a long time. Maker spaces make this easier since I can just send over a file and get a part printed without buying my own machine. Five years ago, 3D printers cost a bomb. Today, they’re so much more accessible. I love seeing how quickly technology spreads once it hits that tipping point.

So far, I’ve printed a bunch of parts for other projects. 3D printing opens up so many creative possibilities for hardware builders. I’m not sure what my final wearable will look like yet. Maybe a watch. My mom likes colourful things, so maybe a bracelet that can sync with an app and skip the LCD screen altogether. Or maybe it’ll be something else entirely. That’s the fun part of 3D printing, you can figure it out as you go.

I was talking to my nephews earlier, and just listening to them bounce around ideas was a reminder of why prototyping is fun. Ash is the more artistic one, so teaching him 3D design and print his first drone model is going to be exciting.

If you’re new to 3D printing, it’s actually a lot simpler than it looks. You design your part in a CAD tool like Fusion 360, Tinkercad, or FreeCAD. Export it as an STL file, run it through a slicer like Cura, and the printer does the rest. PLA is the easiest filament to work with for beginners. TPU is flexible and good for wearables, though it’s trickier to print.

You don’t need to own a printer right away. Many makers start by printing through local fab labs, universities, or online services. Once you’re ready, even budget printers under $200 can get surprisingly good results.

§Part 7 : Final integration

This is where everything comes together. Your PCB, your software, your components, and your casing. Then you cross your fingers and hope it actually works!

If you plan to make more than just a few units, it’s worth moving from 3D-printed parts to proper molds. They’re cheaper in volume, cleaner to finish, and more durable. Casing doesn’t have to be limited to metal or plastic, either. You can get creative with any material that protects the components and works for your product and users.

Testing is a big step here. If your product involves electronics, make sure it meets EMC standards and is tested under the right conditions. If it’s just a hobby build, you can keep it simple by making your own loop antennas from RF cables, keep a spectrum analyzer nearby, and have those ESD tapes ready.

If you’re selling to end users, plan ahead for packaging, drop tests, and overall durability.

In most companies, once a prototype is stable, it goes through regulatory testing first. Then it enters a pilot run. This is where manufacturing simulates the full production flow: assembly → testing → packaging → shipping.

Once everything checks out, you’re good to go.

This project has been fun, and it’s the kind of uplifting work that reminds me why I build in the first place. If you have the budget and time, you can finish a simple prototype in about a week and, give or take, another two weeks to get to a final product. The complexity will grow depending on the level of tech and how much you want to cover for user needs.

I hope this piece gives you a clear starting point.

Good luck with your build!