There was a point in this project where GhostBridge worked.

The PCB powered up.

The ESP32 firmware was stable enough to move traffic.

The RS232 side communicated reliably.

GhostTune could talk through it to a real ECU.

Technically, I had solved the original problem.

But I started realizing there is a pretty big gap between “this works on my bench” and “I would ship this to somebody and expect it to work for them.”

That brought a completely different set of questions.

How repeatable is the hardware?

Can I order five boards and expect all five to behave the same way?

Can somebody plug the connectors in without stressing the PCB?

Does the enclosure stay together?

Can the board move around inside it?

How am I going to power it?

What happens when somebody connects to the WiFi for the first time?

What information do they need before they can use it?

And probably the biggest one:

What assumptions am I making because I built the thing myself?

On my bench, I already knew the pinout.

I already knew which WiFi network to connect to.

I knew the TCP address and port.

I knew what the LEDs, firmware behavior, and serial connection were supposed to do.

A customer knows none of that.

That forced me to start looking at GhostBridge less like a project and more like a product.

Manufacturing More Than One

Ordering prototypes from JLCPCB was one thing.

Thinking about repeatable production was different.

I had to pay attention to part availability, substitutions, assembly, board cost, shipping, and whether the exact design I had tested could actually keep being built.

That is another lesson I did not really appreciate when I started:

A component can be electrically perfect and still be a bad production choice if nobody can get it.

The BOM became more than a list of components.

It became part of whether the design could actually exist outside of my own workbench.

Firmware Had to Become Predictable

The same thing happened with the firmware.

During development I could change a setting, reflash the ESP32, reconnect manually, or look at serial output if something went wrong.

That is not a good user experience.

I needed the bridge to power up and behave predictably.

The current setup creates its own local WiFi network and exposes the serial connection through TCP. No router or Internet connection is required for the basic link.

For my original use case that was exactly what I wanted.

Turn the bridge on, connect the phone, and communicate locally with the ECU.

The less setup required, the better.

I Had to Start Documenting the Limitations Too

This was also when I started getting more careful about what the hardware doesn't do.

GB-01 is a three-wire RS232 design.

It routes TX, RX, and ground.

It does not route RTS, CTS, DTR, DSR, DCD, or RI.

That means I cannot just say:

“If it has a DB9 connector, GhostBridge will work.”

That would be wrong.

A DB9 connector might not even be RS232.

And even if it is RS232, the equipment could require hardware flow control, a different pinout, a null-modem connection, or serial settings that need to be matched correctly.

That sounds obvious now, but productizing something forces you to think much harder about the difference between:

“I made it work in my application”

and

“I understand the boundaries of where it should work.”

I think that is an important engineering distinction.

Then Came the Weird Business Stuff

At some point I also had to deal with all the things that have nothing to do with UARTs or PCB traces.

Packaging.

Shipping.

Instructions.

A website.

Support.

Product descriptions.

Pricing.

App Store paperwork.

Privacy policies.

Terms.

Things I definitely was not thinking about when I first connected an ESP32 to an RS232 transceiver.

I even found myself worrying about whether a 3D-printed case that took around seven hours to print was practical if more than a handful of people ever wanted one.

That is a problem I still consider a good problem to have.

The First One Going to Somebody Else Felt Different

There is something very different about testing your own prototype and handing a device to another person.

Once somebody else is going to use it, “it works for me” stops being good enough.

That changed how I looked at testing, documentation, firmware behavior, and even small mechanical details in the enclosure.

The project had crossed another line.

It was no longer:

Can I build this?

It was becoming:

Can I build this repeatedly enough that somebody else can rely on it?

I am still learning that part.

But looking back, that might be one of the biggest differences between building a successful prototype and trying to turn one into a real product.

And it has already given me a pretty long list of things I would change if I were starting the next hardware revision today.