Once the serial path was reliable, I wanted the bridge itself to stay as simple as possible.

I did not want the ESP32 trying to understand ECU tables, tuning commands, or any of the application-specific protocol.

Its job was just to move bytes.

That sounds simple, but there were still a lot of details hiding underneath it.

The ESP32 needed to create the WiFi connection, accept a TCP client, read data from the network, push that data out through the UART, then take whatever came back from RS232 and send it back over TCP.

In other words:

TCP in → UART out

UART in → TCP out

The less interpretation the bridge did, the better.

That separation ended up becoming one of the most important design decisions in the project.

If the bridge tried to understand the ECU protocol, then every new ECU or software change could turn into a firmware change.

If it only moved bytes, then the intelligence could stay in the application.

That also made debugging easier because I could think about the system in layers.

Is the WiFi connection working?

Is TCP connected?

Are bytes reaching the ESP32?

Are those exact bytes appearing on the UART?

Are the returned serial bytes making it back to the client?

I spent a lot of time testing those boundaries independently.

There were firmware revisions where one part worked and another part didn’t.

There were timing issues.

There were cases where communication looked fine for a few messages and then failed under a longer test.

And there were plenty of times where the most useful thing I could do was strip the problem back down and verify one direction at a time.

That is another place where AI was useful.

I could work through firmware ideas, networking behavior, buffer handling, serial settings, and debugging approaches quickly.

But again, a code snippet looking reasonable did not mean the bridge worked.

The real test was whether I could pass actual binary traffic through it reliably.

Eventually the firmware became boring in the best possible way.

Connect to the bridge.

Open the TCP socket.

Send bytes.

Get bytes back.

That was exactly what I wanted.

The more invisible the bridge became, the better the design was doing its job.

At that point I had working hardware and working transport.

The next problem was much bigger:

I still needed an iPhone application that actually knew what all those bytes meant.

That became GhostTune, and it pushed me into React Native, Expo, ECU protocols, mobile UI design, and eventually the App Store.