Most personal sites are a snapshot. A bio, some projects, a contact form, all frozen at the moment you last had energy to update them. I wanted mine to feel like a live thing. So when I revamped it, the one feature I kept coming back to was a real-time status: a small indicator that tells anyone visiting what I'm actually doing right now.
It sounds simple. And the core of it is. But getting it to update itself without me manually logging every context switch like it's a timesheet took a schedule, an API, and Apple Shortcuts quietly doing work in the background. Here's how it came together.
The idea: what makes a personal site feel like a person?
Most personal sites have the same problem. You build them in a burst of motivation, write a bio that's already slightly out of date, add a few projects, and then leave them sitting there for months. Anyone who visits gets a version of you that's frozen in time. It's less a personal site and more a personal monument.
I didn't want that. I wanted someone landing on my site at 11pm on a Tuesday to actually get a sense of what I'm doing right now, not what I was doing when I last had the energy to push an update.
The moment it clicked was when I thought about what I'd actually want to know if I visited someone else's site. Not their resume. Not their tech stack. Just: what are they up to right now? Are they working? Commuting? Watching something? There's something weirdly human about that small piece of information. It turns a static page into something that feels like a person is behind it.
So that's what I built. A status indicator that shows things like "working on side projects," "scrolling reels," "driving," or "at the day job." Small, specific, honest. The kind of thing that makes you feel like you almost caught someone in the middle of their actual life.
Layer one: the schedule
The first thing I realized is that most of my day is actually pretty predictable. I work my day job from 10 to 7. I work on side projects from 9pm to 1am. Those two blocks alone cover a significant chunk of my waking hours, and they repeat almost every weekday without much variation.
So the foundation of the whole thing is just a schedule. A defined set of time windows mapped to statuses. During the day job block, the status says I'm at work. During the late night block, it says I'm building something. Outside of those windows, it falls back to a default.
This alone handles the majority of states automatically without me touching anything. The reality for most people building something like this is that you don't need to engineer a complex system from the start. A simple schedule covers 80% of your life if you're honest about how predictable your routine actually is.
The schedule is boring on purpose. It's the base layer, the thing that's always running underneath everything else. The interesting parts come on top of it.
Layer two: the override API
Schedules lie. Not because they're wrong, but because life doesn't follow a timetable. Some days I'm not at my desk at 10. Some nights I'm not building anything, I'm just watching something and zoning out. The schedule can't know the difference.
So I built a simple API endpoint that lets me override the status manually. You hit the endpoint with a status value, and it immediately replaces whatever the schedule says. The override sits on top of the schedule like a layer. If there's an active override, that's what shows. If there isn't one, the schedule takes over.
The override also has a duration. I can set it to expire after a certain amount of time so it automatically falls back to the schedule when the override window closes. This matters more than it sounds. Without expiry, one manual override would freeze the status forever unless I remembered to clear it, and I would absolutely forget to clear it.
The API is the escape hatch for everything the schedule can't predict. It's also what makes the next layer possible.
Layer three: Apple Shortcuts doing the heavy lifting
This is the part that makes the whole thing feel automatic rather than just clever.
The override API is useful, but manually hitting an endpoint every time my context switches defeats the point. I'd be logging my life like a timesheet, which is exactly what I wanted to avoid. So I set up Apple Shortcuts on my iPhone to trigger the API on real-world events, with no manual taps required.
The one I'm most proud of is the CarPlay shortcut. When my iPhone connects to CarPlay, a shortcut fires automatically and hits the override endpoint with the status "driving." The site updates on its own. I don't touch anything. I just get in the car.
The Instagram one works similarly. When I open Instagram, a shortcut triggers and flips the status to "scrolling reels." When I close it, the override expires and the schedule takes back over.
Setting these up takes a little patience because Apple Shortcuts can be finicky about automation triggers, and some of them require you to confirm the first time they run. But once they're running, they just work. The iPhone becomes a passive sensor for what I'm actually doing, and the site reflects it without me thinking about it.
When it first worked
The moment the CarPlay shortcut fired for the first time and I watched the site update on its own, I got the same feeling I got the first time I built something that actually did a thing in the real world.
It reminds me of when I first learned to code and built a Notepad clone that could read text out loud. Objectively a small thing. But it felt alive in a way that a tutorial project never does, because it was responding to the real world, not a controlled exercise.
That's what this status feature does. It responds to the real world. I get in my car and my site knows. I open Instagram and my site knows. Nobody asked it to update. It just did.
There's a real psychological difference between building something that exists and building something that feels alive. The features that hit differently are almost never the big architectural ones. They're the small, specific ones that make someone visiting your site think "wait, did that just change?" That moment of surprise is worth more than a polished hero section.
What I'd do differently (and what's next)
Honest reflection: the schedule still gets things wrong more than I'd like. If I take a day off mid-week, the site still says I'm at my day job. If I'm sick and sleeping at noon, same thing. The schedule doesn't know about exceptions, and right now I have to remember to manually override it when my routine breaks, which I don't always do.
Some of the Shortcuts also misfire. The Instagram one occasionally triggers when I'm doing something adjacent in the app ecosystem rather than actually opening Instagram to scroll. Edge cases like this are annoying but not worth over-engineering a fix for right now.
What I'd like to add eventually is location-based triggers. Being near a specific location automatically flipping the status is more reliable than app-based triggers for things like "at the gym" or "out for a walk." Sleep detection is another one. If I could automatically flip to a sleeping status based on Do Not Disturb or bedtime mode activating, the overnight hours would be a lot more accurate than whatever the schedule assumes.
The core thing I'd tell anyone building something like this is to start with the schedule and add layers only when the schedule breaks down. The schedule is unglamorous but it carries most of the weight. The API and the Shortcuts are just there to handle the gaps.
The best part is that the gaps are actually the interesting parts of your day. The schedule covers the routine. The overrides capture everything else.