iynk

Learn hardware without buying it. Wire, code, break and fly real boards, robots and drones for free in your browser, in your language, with an AI partner that finds you a friend

Comment

iynk — A Free Hardware Lab in Your Browser

Live: https://iynk.tech
GitHub: https://github.com/kushwahaamar-dev/iynk

Inspiration

I wanted to build robots. Robotics and computer engineering were what I wanted to do with my life, and I gave up on both. Not because I lost interest. Because hardware costs money every single time you learn something. A board, a sensor, a motor driver, a battery. Then you wire one thing wrong, the part is gone, and you buy it again. Learning hardware is mostly experimenting, and experimenting means breaking things. When every mistake costs real money, you stop making mistakes. Then you stop learning.

It's worse for a lot of people. In rural areas, and in countries where electronics are imported, a cheap sensor isn't cheap by the time it arrives, if anyone nearby sells it at all. There's often no lab, no makerspace, and nobody around who has done it before. Plenty of people with the curiosity for engineering never get to touch a breadboard.

I grew up knowing how much opportunity depends on where you're born and what resources you have around you. It bothered me that someone could have the curiosity and ability to become an incredible engineer but never find out, simply because they couldn't afford the equipment to begin.

My teammate is a computer engineer and knew the other side of it: even when you can afford the parts, you burn through them on experiments long before you reach the thing you wanted to build.

We started with a simple question: what if learning hardware didn't require owning hardware?

What if a student could open a browser, wire an Arduino, write actual code, deliberately break a circuit, understand why it failed, build a robot, and eventually design a drone that could fly? What if they could do all of that for free, in their own language, with other people helping them along the way?

That's iynk: a hardware lab in the browser where you can wire, code, break and fly real-world boards, robots and drones for free, in your own language, without learning alone.

The idea is to do all the experimenting in a virtual lab, so the only thing you ever have to buy is the final prototype.

What it does

iynk has three labs.

  • Board Lab: 12 real-world board models, from the Arduino Uno R3 to two FPGA boards, with 71 lessons. You write code (Arduino C++, MicroPython, Python on the Raspberry Pi, Verilog on the FPGAs) and press Run. The simulator drives the pins, the serial monitor and a hand-inked 3D figure of the board you can turn and see through.
  • Robotics Lab: 13 benches (motor drivers, sensors, power stages, a robot arm, a line follower), built part by part over 272 steps.
  • Drone Lab: 13 drones, from a Tiny Whoop to an octocopter. Build one, check its thrust and flight time, run the safety tests, then fly it through gates in angle or acro mode.

The best part is breaking things on purpose.

Leave the resistor off an LED and it flashes once and burns out, and iynk tells you why: about 113 mA went through a part that wanted 20. The resistor you should have used:

$$R = \frac{V_{\text{supply}} - V_{\text{LED}}}{I} = \frac{5\,\text{V} - 2\,\text{V}}{0.02\,\text{A}} = 150\,\Omega$$

There are 144 board failures and 106 bench faults to try, and every one of them is free.

We wanted students to understand why something breaks instead of just being told their answer is wrong. A broken LED isn't a failed lesson. It's an opportunity to understand current, resistance and the consequences of an engineering decision.

Then it gets social.

  • Rooms: Share a link and up to eight people build on the same bench, live, from any device.
  • A lab partner that finds you a friend (Meta): When you're stuck, the partner (Muse Spark) doesn't just answer. If someone in your room has already passed that lesson, it asks them first, with a question that makes them explain it. Room chat and voice messages are translated into each person's language, and voice goes through Muse Voice Transcribe, so you can talk while holding a breadboard. It can also plan a Build Night for a group, turn a session into a short story with a Muse Image cover, and suggest build buddies whose skills complement yours.
  • Build it for real (SerpApi): When you're ready for the final prototype, the parts list is priced live across Google Shopping, Amazon and eBay. On a drone, a budget optimiser re-runs the drone maths on every battery, motor and prop combination and picks the build that still flies within your budget. It also finds makerspaces, electronics shops and flying fields near you, and tutorials on YouTube.
  • Proof of Build (Solana): Pass the bench safety checks on a drone and the server re-runs your exact run before our Anchor program writes a credential to your wallet on Solana devnet. Anyone can verify it straight from the chain, and sponsors can lock bounties that pay out in the same transaction.

Everything is in English, Spanish, French, German, Chinese and Hindi, down to the 4,087 labels inside the 3D figures. No account, nothing to install.

A student in a small town with a basic laptop should have access to the same opportunity to experiment as someone studying in a university engineering laboratory. That's what we're trying to make possible.

How we built it

The first complete version of iynk was developed during HackTX. We had 24 hours and two people, so we planned before we built. The first hours went into contracts: the fixed decisions for the core, one owner for every file, and seams for features that didn't exist yet. Then we drove Claude Code, which ran more than 250 agents in parallel waves. Each agent owned its own files, and agents asked each other for changes by writing request files instead of editing each other's code.

  • Frontend: Next.js 16, React, TypeScript, Tailwind and CodeMirror. The 3D figures are hand-inked SVG made with Colorfigures, with our own engine running the circuits and benches inside them.
  • Simulation: Interpreters for an Arduino C++ subset, MicroPython, Python and a Verilog subset on a deterministic clock, a circuit solver that decides what breaks, and a drone calculator. A build only passes if it can lift itself with room to spare:

$$\text{T:W} = \frac{n_{\text{motors}} \times T_{\text{max per motor}}}{W_{\text{all-up}}}$$

  • AI: Meta's Model API (Muse Spark with tool calling, Muse Image, Muse Voice Transcribe), with Gemini as a fallback when Meta is busy. Some of the partner's tools run on the server, and some act on your bench in the browser.
  • Search: SerpApi behind a server-side engine whitelist, caching and a budget guard.
  • Realtime: A small Node WebSocket relay on a Vultr VM in Dallas, in Docker behind Caddy, that puts every shared action in the same order on every screen.
  • Data: Tiger Data (Postgres with TimescaleDB) for anonymous usage events, live leaderboards from continuous aggregates, and opt-in buddy profiles.
  • Chain: iynk_passport, an Anchor program on Solana devnet.
  • Checks: TypeScript, ESLint, 2,797 unit tests, 116 Playwright browser tests with axe accessibility checks, figure probes, a crawl of every route, and a table that runs every lesson's reference solution and starter code.

The idea, our hardware research notes and an earlier prototype came before HackTX. We used them only as knowledge: every line of iynk's code was written during those 24 hours.

Our contribution was designing the learning experience, researching the hardware behavior, defining the simulation architecture, coordinating implementation, integrating the services, and testing the resulting application. Claude Code and the AI models assisted with implementation, while the other technologies provided the infrastructure and APIs described above.

Challenges we ran into

  • Our agents ran out of usage, twice. At 2:19 p.m. on day one, a usage limit stopped 56 agents mid-task. We rebuilt how we worked: every agent commits its own files the moment it finishes, and every step goes into a handoff file, so either of us could pick up exactly where the last session stopped. That saved us again at 7:35 the next morning, when a session hit its limit in the middle of a check.
  • Solana fought us all night. The public devnet faucet refused every airdrop, so the program sat finished and tested but undeployed. We deployed it in the last hours with our own devnet SOL, and when the public RPC started rate-limiting us, we sent the deploy's transactions straight to the validators instead.
  • Bugs that only show up live. One database bug only happened on a brand-new server instance when two writes arrived at the same moment: the database client sent lists in the wrong format before it had finished starting up. Our tests ran queries one at a time and never saw it. We found it by testing the deployed site with real traffic, reproduced it 6 times out of 18, and fixed it. The same pass caught a Meta model version that sometimes answered "model not found", which was quietly breaking the Build Night planner.
  • Six languages, all the way down. Translating lessons is one thing. Translating 4,087 labels inside 80 3D figures, in Hindi and Chinese, without anything overflowing on a phone, is another.
  • Facts. A hardware lesson is mostly numbers: pinouts, voltages, currents, thrust. Some numbers on the sites we learned from were wrong, so every board and drone got a fact sheet with sources before its lessons were written.
  • Making complex engineering approachable. We wanted someone with no electronics experience to understand their first LED circuit, while also giving more advanced students room to work with FPGAs, robotics and flight systems. Keeping the beginner experience simple without stripping away the engineering was a constant challenge.

Accomplishments that we're proud of

  • Three full labs in one product: 12 boards, 13 robotics benches, 13 drones and 80 inked 3D figures, free and in six languages.
  • A simulator where students can make 250 different board and bench mistakes without paying for a single replacement component.
  • An AI that sends you to a person instead of replacing them. In our live tests, the partner asked the classmate who had already passed the lesson three times out of three.
  • A complete path from experimenting virtually to comparing real component prices, finding local resources and planning a physical build.
  • Every integrated service does a real job in the same story, and all of them are live: Meta, SerpApi, Vultr, Tiger Data and Solana.
  • A way of working where two people and a lot of agents could ship this in 24 hours without losing work when sessions died.

But what I'm most proud of is that someone can open iynk right now, without an account, and start learning something they might otherwise never have had the opportunity to try.

You don't need to own an Arduino to learn how to program one. You don't need to buy a drone to understand how it flies. And you don't need a university laboratory to start experimenting with engineering.

What we learned

  • Contracts matter more than prompts. A fixed list of decisions and one owner per file did more for quality than any clever instruction.
  • Test the real thing. Our worst bugs only appeared on the deployed site, with real keys and real traffic.
  • A hardware lesson is mostly facts, and facts need sources.
  • Cut what isn't ready. We started a hardware twin for a real Uno and left it switched off, because a half-working feature on stage is worse than none.
  • AI can be more useful when it connects people. Watching our lab partner direct a student's question to someone who had already solved the problem reinforced why we built the collaborative learning system.
  • Accessibility isn't just about making something free. The interface has to work across languages and devices, and the lessons have to make sense to someone who has never seen the equipment in person.

And for me, the biggest lesson was personal.

What stopped me from learning hardware was never ability. It was the cost of being allowed to fail. Make failing free, and you change who gets to learn.

What's next for iynk

  • Bring iynk to schools and community centres. We want to start with rural and underserved areas, particularly places where buying or importing electronics is difficult. A low-bandwidth mode is one of our priorities.
  • Connect real and virtual hardware. Finish the hardware twin so a real Arduino Uno on your desk and the one in iynk can run the same code. Students could prototype virtually and test their work on physical equipment when they have access to it.
  • Turn photographs into simulations. Photograph a real breadboard and have iynk reconstruct the circuit, using SerpApi's Google Lens API to help identify the components.
  • Make hardware kits more accessible. Move Proof of Build toward mainnet with sponsor-funded bounties, so a student who completes a verified engineering challenge could earn a physical kit.
  • Expand the labs. More boards, robotics systems, drones, programming languages and lessons, with support for students at different skill levels.
  • Let students build their own projects. Move beyond predefined lessons and benches toward customizable workspaces where students can design, program, simulate and share their own hardware creations.

Our long-term goal is for iynk to become a place where someone can go from knowing nothing about electronics to building something of their own, regardless of where they live or how much money they have.

I wanted to build robots when I was younger. I couldn't afford to keep experimenting, so I stopped.

I don't want another student to have to make that decision.

Share this project:

Updates

Submission history