How KM/OS was made

This guide explains how KM/OS was built: what it is for, the decisions behind it, and the technical detail worth writing down.

KM/OS is the portfolio of Karim Masmoudi, a third-year engineering student at MedTech in Tunisia, built as a desktop operating system that runs in a browser tab.

The premise is simple: a CV is a list of claims, and an operating system is a thing you can use. Every section of a normal portfolio is an application here, and the applications work.

Project

Scope

The goal was a technically honest environment rather than a themed skin: conventions borrowed from macOS for the menu bar, dock and window management, from Linux for a terminal with real commands, and from mobile for the phone layout.

• A window manager with drag, eight-handle resize, maximise, minimise and focus order.
• Working applications: a file explorer over a virtual filesystem, a terminal, a visual editor, a word processor, a music player, a calculator and a local AI assistant.
• A live chat and a presence feed shared by everyone on the site at the same time.
• Three languages, English, French and Arabic, the last of them right to left.
• Five colour themes applied as token swaps, so no component knows which is active.
• Keyboard navigation and screen-reader labelling across the whole interface.

Project

Planning

The work ran in phases, each one finished before the next began:

1. Style guidePalette, type scale and design tokens before any component.
2. System architectureWindow manager, menu bar, dock and session state.
3. The shellThe operating system with no real content in it yet.
4. ApplicationsEach app built against the finished shell.
5. ContentProjects, stack, education and contact as dictionary data.
6. TranslationFrench and Arabic, including the right-to-left pass.
7. ServicesThe presence room and the contact endpoint.
8. PolishMeasured against the reference, screen by screen.

Project

Cost and infrastructure

The running cost is a domain name. Everything else sits inside a free tier, and that is a design constraint rather than an accident: the site is static, so there is almost nothing to run.

Hosting is Vercel. The build produces a directory of files served from one origin. Two serverless functions handle the only things a static file cannot do: the chat room, and the assistant - which has to run on a server so that the language-model key never reaches the browser.

There is no database. The chat room lives in the memory of a single warm function instance, which is the right size for the traffic a portfolio gets and resets harmlessly when it goes cold.

Project

Risks

The interesting risks in a project like this are not technical failures. They are the ways it can quietly stop being useful:

• An operating system metaphor can hide the content. Every application is reachable in one click from the dock, the desktop or search, and the first window that opens is a plain introduction.
• A site made of moving parts can become unusable on a phone. The mobile layout is a separate design, not a squeezed desktop.
• Recruiters do not read documentation. Nothing important is behind a discovery step.
• Animation can become noise. Motion is short, and it stops entirely for anyone who has asked their system to reduce it.

Project

Quality

There is no test suite. Instead, checks run against the real thing in a real browser: every application opened in every language, watching for console errors, broken images, horizontal overflow and windows that land off-screen.

Layout work is measured rather than eyeballed. Computed styles and geometry are read from the running page and compared against expected values, and only the differences are reported.

Design

Concept

The visual direction is a warm noir: near-black surfaces, ivory panels and a single champagne accent. It is deliberately quiet, because the interface already asks a lot of the visitor.

Restraint is the rule. One accent colour, one serif, one sans, and a small set of spacing steps. Anything that wanted to be decorative had to justify itself as information first.

Design

Desktop and mobile

The desktop build is a windowing environment: a menu bar, a dock, desktop icons, a widget rail and windows that overlap.

The phone build is a different product sharing the same data. A home screen with app icons and widgets, a paginated applications folder, and full-screen applications instead of windows. Applications that make no sense without a pointer are simply not on the phone.

Inside a window, layout responds to the window, not the screen. That is container queries throughout: the same page laid out differently in a narrow window and a wide one, on the same display.

Design

Colour

Every colour in the interface is a custom property. Components never name a colour; they name a role, and a theme supplies the value.

That indirection is what makes five themes possible without touching a single component: champagne, midnight, terminal, sandstone and ember are token sets, applied as one class on the root element.

Design

Typography

Two families. Source Serif 4 carries titles and anything that should feel written; Inter carries the interface. A monospace face is reserved for the terminal and for figures that need to line up in a column.

Arabic is not the Latin type at a different size. Right-to-left affects layout, punctuation and the direction of every icon that implies motion, and it was treated as a layout mode rather than a translation.

Technical details

Stack

Vanilla JavaScript in ES modules, bundled by esbuild into one file. Hand-written CSS over a single set of design tokens. Two dependencies in total, and both only at build time.

No framework. For an interface that is mostly bespoke, a framework would have added a runtime, a build step and a set of conventions, in exchange for very little that this project actually needs.

• Windows are cloned from a <template> and driven by state classes, so the motion stays in CSS.
• Pointer Events for every gesture, so a drag behaves the same with a mouse, a pen or a finger.
• A virtual filesystem shared by the Terminal, the file explorer and the word processor: an edit in one is visible in the others.
• A service worker that serves from cache and refreshes in the background.

Technical details

Security

Two things leave this site, and it is worth saying so first. A question typed into KM Intelligence is sent to this site's own server and on from there to a language-model provider, because that is where the model runs; the provider key stays on the server and is never sent to the browser. The contact form is posted to the service that forwards it as email. Nothing else leaves: a strict Content-Security-Policy means everything the page loads comes from its own origin, which is also why there is no analytics script and no font CDN.

There are no cookies and no tracking. A handful of interface preferences live in the browser's local storage, never leave the device, and are cleared by restarting KM/OS.

The chat room is the one place where text from the public internet is displayed to other people. Messages are length-capped, stripped of control characters and rate limited on the server, and written into the page as text and never as markup.

The visitor cities in the security widget come from the edge headers the host attaches to a request. Nothing asks the browser for a location, and no location is stored.

Technical details

Artificial intelligence

KM Intelligence answers out of this site's own records. Every project, technology, certificate and contact detail already lives in the source, written by Karim in three languages and kept current because the rest of the OS renders from it - so the assistant cannot be wrong about a fact it was never asked to invent.

A language model turns those records into a reply that reads like an answer rather than a retrieved paragraph. It runs behind this site's own server, so the provider key is never sent to the browser, and several keys are held in order: if one is out of quota the next answers, and if none of them can be reached the records answer on their own. Nothing is downloaded, and it works on a phone.

Technical details

Credits

KM/OS is designed and built by Karim Masmoudi.

Type is Inter and Source Serif 4, both under the SIL Open Font License. Interface geometry follows the Tabler icon set, under MIT.