The satellite part is only one layer
I joined CalgaryToSpace through the RF communications software team and started working around the ground-station side of FrontierSat.
My part of the project has mostly been about the data that comes through that system: how it should be stored, how the rest of the software accesses it, and how telemetry, commands, and mission-related information fit together.
It is connected to a satellite, but that does not magically remove normal software-engineering problems.
The database becomes an interface
A database schema is not just a place to put information.
Once multiple parts of the ground-station software depend on it, the structure becomes a contract. Names, relationships, timestamps, identifiers, and assumptions start affecting other people.
That made me think more carefully about data modelling than I had on smaller personal projects, because changing something later can break more than my own code.
Physical systems make assumptions visible
The other difference is that this software sits beside RF hardware and a real communications workflow.
In a normal web project, I can often reproduce an issue by clicking around locally. Here, the software is part of a bigger system with components I do not control.
That makes interfaces and observability matter more. If something goes wrong, it helps to know exactly where data came from and what happened to it along the way.
What I like about it
FrontierSat made systems work feel much less abstract to me.
The same backend skills still matter, but the context changes how seriously you take them. The database is not just serving a dashboard. It sits inside a chain that starts with hardware and RF communication.
That has been a useful reminder that good software engineering travels surprisingly well between domains.
This note covers the project as described in my portfolio. The linked source and demo are the best places to look at the implementation.