Like many people, 2020 changed how I lived and worked. When the government forced us to stay home with lockdowns, the two-hour daily commute disappeared overnight. That time came back in unexpected ways! I returned to competitive basketball, coached my kids’ teams, and started training like an athlete again.
That shift had a compounding effect. Improving my fitness had a noticeable impact on my energy, focus, and overall productivity. I was training consistently, thinking more clearly, and ramping up what I could deliver in my day job.
But there was a problem. I was tracking my workouts using a spreadsheet on my iPhone and the built-in Apple timer. Logging weights, sets, and rest times like that was painful, slow, and just enough friction to make it annoying every single session. So, in my spare time, I decided to build something small to fix that problem.
That’s how Intrvl started, as a simple rest-set timer. I wanted something that enforced proper rest between sets so I could train consistently and recover properly. I found I was underresting, thinking I’d rested for two minutes only to discover I’d sat there for 30-40 seconds, but that’s another story.
Over time, it evolved into an entirely local iPhone training app that tracks weights, sets, and reps, includes Tabata and HIIT timers, and now even supports sport-specific intervals like basketball shot clocks. But one of the most interesting things I learned building Intrvl wasn’t about fitness at all.
It was about how AI fundamentally changes the way we should think about building software — and why so many AI initiatives struggle when we treat AI like a faster human, rather than a different kind of machine.
You can see the result of this thinking at https://intvl.app, but the app and the site are really just outcomes of a broader shift in mindset.
We’ve been optimising software for human capabilities.
For decades, software architecture has been shaped by human constraints. Writing raw HTML, CSS, and JavaScript by hand is flexible, but slow and repetitive for humans. That’s why we invented frameworks like React, Gatsby, and static site generators — to abstract repetition, enforce consistency, and make systems easier for humans to reason about and maintain over time.
Those abstractions make complete sense when humans are doing the work.
AI doesn’t share those constraints.
AI doesn’t get tired. It doesn’t forget patterns (well, kinda). It doesn’t mind repetition. It can generate clean, native code in seconds. How long does it take a human to write 1000 lines of code? Compare that to AI.
Once you really accept that, many of our default architectural choices start to look suboptimal — not because they’re bad, but because they were designed for a different worker.
Applying AI-native thinking to the Intrvl site
When I built the Intrvl website (https://intvl.app), I deliberately leaned into this idea.
The site is mostly static. The content doesn’t change often and doesn’t require user accounts, databases, or complex backend logic. Instead of reaching for a heavy framework by default, I used AI to generate clean, accessible HTML and CSS directly.
Because AI can reliably produce structured code, I didn’t need layers of abstraction to protect me from myself.
The result is a site that:
- runs on very cheap hosting
- has almost no moving parts
- and is easy to maintain and support
This mirrors how the Intrvl app itself works. The app is entirely local to the iPhone. No accounts. No cloud sync (other than iCloud for backup). No servers for me to manage. Your workouts, weights, sets, and timers live on your device.
Fewer dependencies mean fewer failure points — both in software and in training. The technology choices reinforce the product philosophy.
Static where possible, dynamic only where it matters
For the blog portion of the site, where content does change, I kept the same AI-native approach.
Blog posts are written as Markdown files. They’re edited locally — either in a simple text editor or using Cursor (https://cursor.com), which helps me draft, refine, and structure my content. The files live in GitLab (Git). A push triggers a simple CI/CD pipeline that rebuilds the site.
There’s no CMS admin panel. No database. No runtime complexity.
This is the same principle behind Intrvl’s training experience. Just as Intrvl makes it easy to log sets, track weights, and rest without fighting the UI, this workflow makes it easy to write and publish without ceremony.
Why do many AI pilots struggle
Building Intrvl this way reinforced something I’m seeing across industry: many AI pilots fail to deliver because we design them through a human lens.
We often ask, “How can AI help a human do this process faster?”
A better question is, “If AI had no restrictions, how would this system be designed from scratch?”
When we push AI into human-centric abstractions, complex workflows, layered tooling, and excessive approval steps, we limit its strengths. AI works best when:
- outputs are simple and native
- Repetition is embraced rather than abstracted away (Caching tokens is also great for cost)
- and humans stay in the loop for review, intent, and taste
Intrvl is a small example. AI didn’t just help me build the site faster — it changed the architecture choices I made in the first place.
Looking ahead
Next, I plan to extend this approach by introducing human-in-the-loop automation for blog content, likely using tools like n8n, where AI helps generate drafts based on topics and trends. I review, refine, and rewrite parts before publishing. AI handles the repetition; humans provide guidance and the tick of approval.
Intrvl will continue to evolve as a training tool. Still, it also remains a practical case study in AI-native thinking.
If you’re interested in the story and how it aligns with how AI actually operates, I’m always happy to share what I’ve learned. Reach out to me.
