2 Approaches to Fast and Effective Software Development from a CEO-and-Solo Dev

Jason Grishkoff is the CEO and founder of the music community platform SubmitHub — and he’s also the entire development team. As a CEO-and-solo developer combo, Jason’s approach to developing features for his company is a little different to most.

In this article, Jason shares his strategies for developing and releasing new features as a solo developer who’s also the CEO. He discusses how not having a team of developers helping him decide which features to build means he relies a lot more on his relationship with his users, and how he has to timeblock his productivity in order to maximise the quality of time he spends coding when he’s not ‘CEO-ing’.

SubmitHub is a platform for up-and-coming musicians to promote their music to music bloggers, radio stations and record labels. New artists need people to hear their music, and bloggers, radio stations, and record labels need new music to share and promote. SubmitHub solves that problem by making it really easy for the two communities to connect and discover each other.

However, Jason says that the idea came from a very simple problem: Before launching SubmitHub, he ran a music blog called Indie Shuffle. At one point, he was getting hundreds of emails every day from artists asking him to listen to their song and blog about it: “I couldn’t pay attention to the new stuff anymore because it was too overwhelming and it was inconsistent.” He would get zipped files, Soundcloud links, YouTube links, and Dropbox links, which meant that he struggled to listen to it all. “My inbox was just unmanageable, and I wasn’t discovering music.”

In order to manage his inbox better, Jason built what was essentially a ‘thumbs-up-thumbs-down’ machine for his emails: “It started as a very simple form, with a few fields that musicians could fill out: Artist name, song title, and the link to your song. It all came through in a consistent format. I just had a list of songs with a thumbs-up button, and a thumbs-down button.” This eventually became a way to screen new curators and showcase new music, and evolved into what is now SubmitHub.

As both the CEO and the only developer at SubmitHub, Jason is in control of how his product functions and what he builds. While this is liberating, it also comes with its challenges. Here are two approaches Jason uses to set himself up to be able to operate effectively in both his roles, while always putting the product first.

#1 Users are his QA team

Jason doesn’t have a team of devs to check his code. Instead, he deploys new features quickly, and instead relies on his users for feedback:

“Every tweak I make tends to come from the users themselves… and the way they interact with the website. Users are really good at telling you when things don’t work. And sometimes it’s annoying, but they’re really good at it.”

When Jason launches new features, especially bigger ones, he posts the new features directly to the chat rooms on SubmitHub. That way, he makes it easy for users to give feedback on a specific feature. It also makes it really easy for users to interact directly with the person coding the platform — who also happens to be the founder — and gives Jason a way to gauge whether the feature he shipped is something people actually want.

He explains: “The chat rooms have upvotes and downvotes that users can use to interact with ideas, and I use that as a gauge: Someone makes a suggestion, or asks for a feature, or suggests something that could work smoother, and if it gets 10 thumb ups next to it, then maybe I should look into it.”

But getting feedback and working on changes or new features from his users’ suggestions takes time. This means that Jason needs to be really intentional about how he balances and splits his day between coding and CEO-ing.

#2 It’s important to block off separate time for coding, and for CEO-ing

Jason wears two hats: Sometimes he needs to be a CEO, sometimes he needs to be a software developer — and each has its own set of demands. If he isn’t intentional about how he spends his time, switching contexts from one to the other can slow him down, and reduce the amount of things he’s able to get done:

“You’ve got to get into a groove: If I’m coding, trying to knock out a bunch of to-do list items, and I constantly have to switch back and forth every half hour… it slows things down, and it’s harder to focus.

This is why Jason blocks off his time into chunks, based on what he needs to get done and when he’ll be most productive for that particular task. It lets him minimise the amount of context-switching he has to do on a daily basis, and more successfully get into a ‘flow state’ of work for each task he does.

Here’s how he blocks his time as a CEO and a solo developer at the moment:

Since a lot of Jason’s current client and user base sit in different timezones, his inbox stays relatively quiet until the afternoon. This makes his mornings perfect for coding: “I tend to not get very many emails between 7am and 3pm, so that time gets carved out for coding, and I try to tackle as many different items as I can.”

Then, in the afternoon, he switches to his CEO hat. This is when he starts getting emails again, checks in with his team, and when he needs to worry about feeding and bathing his children before bedtime. It’s much easier to juggle those two things, than trying to get a big chunk of coding done while running between family and work.

After his kids have been put to bed, he gets a second wind of focused coding and sets aside another hour and a half to work through some customer support tickets.

Following these two approaches has enabled Jason to enjoy the freedom that comes with being an only developer and a CEO, while working around the drawbacks that make it difficult at times. “You’re the bottleneck for things, and it’s easier to make mistakes when you’re the only developer”, he explains.

Although being a solo developer is something Jason really enjoys about his company, it does mean he has to be deliberate about how he sets himself up. By having a clear strategy for feature development, he can work through builds more productively and get more mileage out of the time he spends being a dev and being a CEO.