The Starcraft-ification Of Boring Apps
Building applications has always been about building stuff that people want. But now there's even less of an excuse not to do it.
The Starcraft-ification Of Boring Apps
For the last few months, I've realized that with my coding harness Vbear, I'm able to work on 4 or 5 apps at a time. I can spin up 10-15 parallel agents per project, and manage them in batches. Each project is maybe 10% slower, but the volume of overall work done is much, much higher.
Until I got an odd request from a client. This client manages around 100 school busses, and I'm building fleet management and routing software for her company.
"Griffin, the stuff that you built works but it's really boring. I was watching my son play games yesterday, and I was thinking. Why can't you make my app feel more like a video game?".
My first answer was "well, this here is a data dashboard, and data dashboards are inherently boring". But she didn't buy that. So I started thinking - if I were to rethink this app from scratch, and I could make it feel like anything, what would I make it feel like? Well, I'd want it to feel like playing StarCraft.
StarCraft (for those of you who were probably more popular than I was in high school) is a real time strategy game where you and an opponent face off. In the game you have to manage a bunch of different things at the same time, like gathering resources, building structures, and controlling your army. The whole game is lightning fast.
One of the core statistics that gets measures is "APM" - actions per minute. I'm what you might call a competent amateur - my APM sits at about 80. So I'm pressing more than 1 button a second. The pro players can top 800 APM, or over 10 button presses per second.
While that's pretty impressive in my opinion (way cooler than running a ball across a field or hitting it with a stick), the application that supports this level of speed is equally impressive. It lets players set camera locations, hotkeys, etc. etc. So by the time that players get into a game, they've already spent hours engineering their setup to fit them like a glove.
Why couldn't a data dashboard feel the same way? Why did it have to be inherently slow and boring?
The rebuild with this new design philosophy is still in progress, so we'll see how it goes. But the core learning is this - being able to build product faster DOESN'T free up multiple product building channels - it means that you get to spend more time on the stuff that customers care about.
I can implement most UI changes that customers request in about 10 minutes of focus time (takes the LLM much longer, but who cares I've moved on to other things). So if before I spent 10% of my time to UI/UX work and 90% of my time writing code, the split is now closer to 70% doing UI/UX work and 30% writing code.
But really what this means is 70% of my time talking to customers and then doing UI/UX work - because so much less of my share of mind is wrapped up in programming, I can actually spend time going on walks and thinking about what I've learned from my user interviews.
The jury is still out on this approach - there will be a part II once this goes live. But I'm thinking that this is the new meta. More time for talking to customers and design, less time spent doing the stuff that customers don't care about.