Server logic. Relational schemas. Deployed and holding.

Every architectural decision here is measured against one question: does it hold under real conditions? If it doesn't, the choice is wrong.

I studied UX-UI design and back-end development at Noroff School of Technology in Norway. I spent a while learning how people use software before I moved to building the parts they don't see. These days I mostly write JavaScript on the server side. REST APIs, database schemas, deployments. I like the kind of problem-solving where you figure out how data should flow and where things will break before they do. Having a design background changes how I approach back-end work. I care about who's consuming an API, not just whether it returns a 200. I'm a recent graduate looking for a junior back-end role where I can build real things and learn from experienced engineers.

Close-up of a terminal window on a dark monitor, Node.js server log output scrolling — green and cyan text on near-black background, screen glow casting cool light on the surrounding desk surface, tight crop showing only the screen and immediate edge of the keyboard

— Constraint-Driven Design

The problem defines the stack.

REST endpoints are structured around the resource, not the framework's convention. Database schemas are normalized to the query pattern, not the ORM's preference.

Deployment targets are chosen for reliability and cost at the project's actual scale—not for what looks good on a resume. Constraints are the spec.

See the Projects

Actively building. Available now.

Production-grade projects are live and linked. Review the architecture, read the code, run the tests. That's the full picture.