This is a really awesome project! If you have time/interest, you could try to build a simple http server now, that your browser could communicate with. Then you could try to implement a simple version of TCP/IP, and look into how lower level networking works. Great job!
In my experience, not a good idea to write both the client and the server for a given protocol which use each other. Far too easy to misunderstand the protocol. I remember doing this for a training course I wrote for OLE (later COM) years ago. The client and the server worked perfectly together, just not with correctly implemented OLE clients and servers.
Just slap a new legally-distinct-but-still-confusing name on your client/server pair, and use it as a marketing tool to sucker in purchasing managers.
Like EtherNet/IP, where the IP somehow stands for "Industrial Protocol".
Ah, but what if one your clients needs to use, let us say, Excel...
My mistakes with the training course code would have been fixed if the company would have bought Excel licenses fof our customer workstations.
And I just remembered it was DDE (dynamic data exchange), not OLE. OLE was much better specced than DDE. Like I said, it was way back when. But the basic rule (don't test using both a home-grown client and server) still applies.
The real full stack engineering
But did they make their own CPU?
... did they mine their own minerals?
this could go into a sagan's "If you wish to make an apple pie from scratch, you must first invent the universe."
Like any self-respecting baker, I have a cabinet full of universes which produce various pies.
And ideally use your own philosophy, concepts and language when engineering everything. No English language, Latin alphabet or Arabic numerals!
> you could try to build a simple http server now
_simple_ http server is a few lines of code in Python. It's an easy way to add remote access to application. Just ask any advanced LLM.