← Back to home

Journey

How the portfolios were learned.

This is the trail of putting work in front of other people. Not a product timeline - a record of what I did not know yet, and what I had to build in order to find out.

  1. First public site

    I shipped my first portfolio to Firebase in 2018. Two pages, different sets of CSS classes, animation libraries I was still learning by breaking them. JavaScript was new enough that every hover felt like a discovery.

    The hostname is still there. The real lesson was simpler than the animations: something I built could be opened on someone else's phone. Visibility - a URL that was not localhost - changed how seriously I took the work.

    • Firebase
    • JavaScript
    • CSS animation
    • public deploy

  2. CodePen as a sketchbook

    CodePen became the place I went to understand motion, not to collect output. I watched how other people timed a transition, how little CSS could carry a whole composition, how a layout held together when you removed color.

    That tab is still open in the way I look at UI. It is where the craft got stricter - spacing, easing, restraint - before I had language for any of it.

    • CSS motion
    • UI structure
    • restraint

  3. The animated one

    This one is still close. It went public in 2018 and I kept returning to it through 2019. There were no agents to ask, no model to draft a layout. There were other sites, photographs, a few fonts, and a stubborn want to make something that felt light.

    Minimalism, for me, started as a constraint I chose - fewer elements, more attention. I still think of this deploy when I talk about design that comes from looking, not prompting.

    • minimal layout
    • visual pacing
    • Firebase

  4. Windows, in the browser

    Then I tried to make the portfolio behave like a computer. Portfolio.OS was a Windows-like shell: static windows, overlays, my information sitting on a desktop that was only HTML. It looked like an operating system. Underneath it was Django, while I was learning Python, Postgres, migrations, and how a server actually holds a site.

    I put it on Heroku when that was still free. Another first: a process that stayed up overnight without my laptop open. The windows were theatre. The database and the deploy were the lesson.

    • Django
    • Python
    • Postgres
    • migrations
    • Heroku

  5. The quieter text version

    A simpler cut sat next to the desktop - mostly text, still opening through the window overlay. Same facts, less chrome. I moved that work onto AWS and learned the unglamorous path: EC2, Apache, Nginx, keeping a process alive after the laptop closed.

    The design got quieter. The operations did not. That gap - how a page looks versus how it stays up - is still how I think about shipping.

    • AWS EC2
    • Apache
    • Nginx
    • Django

  6. One dashboard for the name

    Around then I put DNS on Cloudflare. One place for the name, the proxy, the certificate, HSTS, HTTPS, and whether the site was even reachable. Instead of wiring a registrar, a host, and a cert bot as three separate jobs, the record, the shield, and the lock lived on a single screen.

    I used the same dashboard when I freelanced - other people's domains, same controls. It is still the fastest way I know to keep a name pointed, encrypted, and watched without collecting vendors.

    • DNS
    • proxy
    • TLS
    • HSTS
    • monitoring

  7. A Linux desktop that ran

    The later Web OS is the one I still run at raghavdhingra.com. Not a picture of a desktop - windows that move, a token grammar I invented so the built-in terminal could speak a small language of its own, settings, a browser inside the browser.

    I wired a camera through navigator.mediaDevices, then spent time inside navigator itself: permissions, devices, what a page will and will not be given. That is when the project stopped being a mock and started being a place I could sit in.

    • custom terminal
    • token grammar
    • navigator.mediaDevices
    • windowing

  8. This version

    This site is the latest cut. I already had the material. I used Cursor, Composer, plan mode, agents, debug, and more than one model to see how fast a version could move when the data was ready - tokens, temperature, pace. I treated them as tools, not as a substitute for looking.

    The work was still deciding what to keep quiet. After years of windows and motion, I wanted type, space, and a page that does not compete with the person reading it. You are on that page. It is also a record of how quickly the way we make things has shifted - and how the older deploys still explain why this one is quiet.

    • Cursor
    • Composer
    • models
    • editorial layout

The curve

A learning curve is not a straight climb. You forget the first animation until you open it years later and feel the same excitement, and the same embarrassment. You overbuild a desktop in the browser, then miss the two-page site that only needed CSS. The curve is the willingness to publish the unfinished thing, live with it, and start over without treating the old one as a mistake.

Tools change faster than taste. Firebase, Heroku, EC2, a terminal I invented, a model that writes a layout in a minute - each one shortened the distance between an idea and a URL. The slower part stayed the same: deciding what to keep, what to throw away, and whether the page still felt like me when someone else loaded it.

I kept the links because the person who made them is still in here. If you open them, you will see the seams. That is the point.

Live sites

The deploys from the story above. Some are dated. All of them still open.