Student developer · Aarhus, Denmark
I build software around problems I actually have.
I'm Charlie, 17, an IB Diploma student in Aarhus. Most of what I build is full-stack web — TypeScript, React, Next.js, Postgres. Right now that's Syllabi, a calendar and study hub for the IB, used by a small group of students at my school.
- Focus
- Syllabi — a calendar and study app built around the IB Diploma Programme
- School
- IB Diploma Programme, Aarhus Gymnasium Tilst
- Stack
- typescript · next.js · supabase · postgres
- Direction
- Medicine and software engineering, deliberately both for now
Selected work
Unedited
Previous siteMy previous site, and an argument for taking things out. A minimalist portfolio built on the industrial-design idea that a product should contain only what it needs — which in practice meant deleting things until what was left had a reason to be there. It had a blog attached. This site replaces both.
next.js · react · typescript · tailwind
Bitless
Earlier projectAn admin dashboard for managing product and user data — the first project I had to write entirely myself. It taught me data modelling, CRUD architecture, writing TypeScript someone else has to read, and keeping a codebase legible past the fun part.
next.js · react · supabase
Syllabi case study
Syllabi
In use · small group
What should I actually do with my time right now?
It started as my own calendar and turned into a study hub: it syncs my school timetable, tracks assignments and assessments, and plans study time around the hours I actually have.
The difference from a normal calendar is what it tries to understand — school commitments, free time, workload and what I said I wanted to get done — instead of only storing events.
A timetable, a homework list and a photo of a slide — none of which know about each other.
Start from what a week already commits you to, and make putting something in nearly free.
Structure, capture, workload, planning and learning signals over a Postgres schema.
Failure behaviour, tests around scheduling, and better use of the signals already collected.
- school
- travel
- study
About
I found CS50 when I was about seven. I understood a small fraction of it and kept going anyway. For years after that I was mostly learning — reading, following along, rebuilding things that already existed. At some point that stopped being interesting on its own.
The change was an admin dashboard called Bitless: the first project I had to write entirely myself, with no tutorial to follow and no one else's structure to lean on. It's also where I learned that a schema shows through every screen you build on top of it.
Since then the pattern has been the same. I notice a problem I actually have, look at what exists, and build something if nothing fits the way I work. Syllabi started that way. So did the homelab. Building is also how I learn, which means I'm usually inside a system before I understand every part of it — and then going back for the part I skipped. I'm deliberate about the going-back. Otherwise it's a pile of code that happens to run.
I'd rather ship a working version than write a long plan about one. The version after it is where the thinking shows up: the same system, rewritten until it's understandable instead of merely working.
I'm at Aarhus Gymnasium Tilst, and my academic direction right now is medicine. Software isn't the fallback and medicine isn't the exit. Both come down to the same question — what is happening inside this system, and why — and I'd rather keep asking it in two places than pick an identity at seventeen.
On AI-assisted work
I use AI-assisted tools every day, and I'm specific about what they do. I design the architecture, the database, the product behaviour and the UX. The tools write code faster than I do. They don't decide how the system works, and I don't ship things I can't debug.
Things I work with
I'm strongest in full-stack web development. Most of the rest I picked up because something I was building needed it.
- Frontend
- TypeScript, React and Next.js. Where most of my code is and where I make the most deliberate decisions: the server and client boundary, data fetching, and the things that decide whether a page feels fast.
- Interface
- Less a tool than a bias. Fast, dense, calm, predictable. I'd rather remove a screen than add a dashboard, and I spend most of my design time on what an interface does while it's loading, empty or wrong.
- Data
- Supabase and PostgreSQL. I design the schema myself and write SQL by hand when the query matters. Auth, sessions, protected routes, row-level policies.
- Infrastructure
- Vercel, Cloudflare, GitHub Actions, Docker at a basic level, Linux. A homelab has taught me more about networking than anything else.
- AI
- The Vercel AI SDK and LLM APIs, used as an ordinary part of an application's architecture — a component, not a chatbot bolted on the side.
- Improving
- algorithms · cs fundamentals · databases · testing · security · linux · git workflows · system design
The last row is the honest one: it's what I'm working through now, not a list of things I've finished.
Experiments
Homelab
OngoingInfrastructure I own, so I'm allowed to break it. Self-hosted services in Docker, Scrypted bridging IP cameras into HomeKit, PoE and UniFi for the network, Cloudflare in front of anything exposed, and monitoring so I find out before something else does.
docker · scrypted · unifi · cloudflare
AI and agents
OngoingCoding agents, orchestration, local models and model routing, mostly to find out where an LLM belongs in an application and where it's just expensive. The useful cases so far are quiet ones: reading a screenshot, parsing a sentence, ranking something.
vercel ai sdk · llm apis
Small tools
OngoingThings I build because I want them to exist — automation, school workflows, a dashboard for one person. Most don't outlive the problem. A few turned into the parts of Syllabi I now rely on.
PC builds and hardware
OngoingBuilding machines and fixing them. Most of my troubleshooting instinct came from here.
What I'm learning
What I'm working on and reading about at the moment.
Reliability in Syllabi
Failure behaviour first: what the app shows when a sync fails or an import reads a date wrong, and which schema decisions would be expensive to change later.
CS fundamentals and system design
Algorithms, data structures, databases past getting the right rows back, and what happens when one piece of a system is slow, missing or wrong.
Testing and security
Tests around the scheduling logic, which is the most worth testing and the least tested. Auth edge cases, access rules, and storing less in the first place.
AI as ordinary architecture
Agents, human–AI interfaces, local models and routing. Software that holds enough context to be useful before you ask — the model treated like a database or a queue rather than a feature added at the end.
How software teaches
Games hand you a complicated system and you understand it an hour later without reading anything. Most software does the opposite: a tour, a tooltip, and a screen you still can't use. I'd like to know what the difference is.
How people plan
Cognitive load, decision fatigue and how study time actually gets spent versus how it gets scheduled. This is the part of Syllabi I find most interesting and understand least.
Contact
Email is the best way to reach me. If you're at my school and want Syllabi, or you've built something near any of this, write to me.
- GitHub
- @charliva
- not added yet
- X
- not added yet