Why I'm building one platform for research, teaching and supervision
Academic work is one system pretending to be three. The tooling should admit that.
Most academic software is organised around departments, not around the work. Research lives in one set of tools, teaching in another, supervision in a third — and the person doing all three spends their time copying context between them.
I don't think that split is real. A supervision meeting produces a reading that belongs to a paper. A paper seeds a lecture. A lecture surfaces a student who should join the lab. The work is one graph; only the software insists it is three silos.
One record, many views
The platform I'm building treats research, teaching and supervision as views over a single record, not as separate applications. A publication, a course, a thesis stage and a reference letter all hang off the same people and projects. When something changes once, it is correct everywhere.
The goal isn't more features. It's fewer places where the truth can disagree with itself.
Rules that live in the data
The hard part isn't the screens — it's the rules. Who may see an unpublished grant? When can a supervisee move to the next stage? Those guarantees can't live only in the interface, because an interface is just one way in. They belong in the database, enforced for every caller.
That constraint is slower to build and much harder to get wrong later. For academic data — student records, draft grants, reference letters — harder-to-get-wrong is the whole point.