This is a writeup of the project I built for my A-Level Computer Science coursework. It was my first real software project and looking back at it now, a lot of the instincts were right even if the execution was rough in places.
The Problem
The idea came from a simple scenario — what if the internet goes down on a large site like a school or office? Everyone still has a LAN connection but all the usual tools (Teams, Slack, email) stop working because they depend on external infrastructure.
The goal was to build a messaging application that worked entirely over a Local Area Network with no WAN connection required and ideally no central server either.
What I Built
The project was developed across three iterations, each building on the last.
Iteration 1 — Text-Based Prototype
The first version ran entirely in the terminal. No GUI, just Python sockets sending messages between two machines on the same network. The goal was to prove the core idea worked before building anything on top of it. SQLite handled message storage and routing data.
Iteration 2 — Minimum Viable Product
Added a basic Tkinter GUI on top of the working backend. Users could log in with an identifier, see a contact list, and send messages. Still rough around the edges but functional as a real application.
Iteration 3 — Alpha Release
The final version added encryption for messages in transit, file sharing, group chats, user status (available, do not disturb), and a significantly improved interface. Passwords were hashed before storage rather than stored in plaintext.
Technical Decisions
A few things I'm still happy with in retrospect:
Encryption. I added message encryption so that without the correct key, traffic intercepted on the LAN couldn't be read. For a school project this was probably overkill but it was the right decision.
Iterative development. Splitting the project into three distinct stages — prototype, MVP, alpha — meant each stage had clear success criteria. This made testing structured and gave natural checkpoints to evaluate what was working before moving on.
SQLite for local storage. Each client kept a local database of messages. Simple, zero-configuration, and appropriate for the scale of the project.
What I'd Do Differently
The biggest thing is the architecture. I aimed for serverless peer-to-peer but ended up with a hybrid that still relied on a central node for some routing. A proper distributed approach — where any node can route messages to any other — would have been more robust but harder to implement in the time available.
The GUI was functional but not particularly good. I built it with Tkinter which is fine for getting something on screen quickly but produces interfaces that look dated. If I were rebuilding it today I'd use a web-based frontend, which would also solve the cross-platform problem.
I'd also write proper automated tests rather than relying entirely on manual black-box testing. At the time I didn't have a good framework for this but testing is something I've focused on much more heavily since — the current version of this site has 107 automated tests, which tells you how much that mindset has shifted.
What It Taught Me
This project is where I learned to actually think about networking rather than just using it. Sockets, ports, LAN vs WAN, concurrent connections, data consistency across multiple clients — these weren't abstract concepts anymore after spending months debugging them.
It also taught me that the hard part of software is rarely the code itself. Thinking through the problem properly, designing the data structures, and making something that a real person can actually use without a manual — that's where most of the work goes.
The coursework was assessed and submitted. The code is available in the repository linked on the projects page.