In every introduction to a potential client, partner, or other associate, the first thing I do is give a brief overview of my history. I know this is common in just about any business or social interaction, but its especially important in my line of work, since communicating my curriculum vitae is so critical to demonstrating my technical competence. And in truth, a technical lead can be as charming as you’d like but unless they are extremely technically competent, nothing else matters. But its hard to compress a lot of data into a short introduction!

I’ve worked on projects for some of the biggest companies in the world — not just Fortune 500 companies, but Fortune 50 companies! — as well as launched dozens of startups, some that didn’t work, some that did, and some that were extremely successful. Those larger companies include industry giants like Disney (three divisions — Disney Parks, Disney Channel, and Disney film!), Dreamworks, Warner Bros., Accenture, CBC, Sega, Sonos, and many more, as well as successful, venture backed startups like Graphite Comics, for which I currently serve as CTO.

I’ve also been written about, and my projects (both professional and personal) have been written about, by publications like the New York Times (which covered the launch of Graphite Comics, and the AI recommendation system I built for it, on the front page of the Business section), The Guardian (twice!), Fortune, TechCrunch, USA Today, AdWeek and many other internationally known outlets, in addition to multiple smaller but no less influential blogs and online journals like PocketGamer, TouchArcade, VentureBeat, and many, many more.

Just typing up that last paragraph and linking to all of that old press was a proud moment. In addition to mainstream press, I’ve also published papers on game related AI, including writeup of my graduate thesis on Hebbian learning in artificial neural networks — a topic I want to get into in more depth later.

That being said, I get asked a lot to dive deeper into my background — not only what I’ve worked on in the past, but why and how, which, to me, are much more interesting questions!

I usually like to keep my posts more positive-focused — here’s what you should do vs. here’s what you shouldn’t do. But this week alone I had three potential clients relay to me a very common experience:

I thought I finally found a good developer, but then they suddenly just disappeared!

I’ll admit its hard to explain to entrepreneurs sometimes why that developer ghosted them — usually the explanation feels personal, or accusatory. But in my experience its just a matter of communication! Often its something that comes up in the initial conversations that seems innocuous to the person looking for a developer, but to that developer, its a huge red flag.

In this post, I’ll try to give a few of the reasons that developer may have disappeared into thin air.

One of the advantages (if you can call it that) of being in this industry as long as I have is that I’ve been through multiple economic disasters, technological paradigm shifts, and — it’s not all bad! — economic and technological boom periods.

So I figured I might as well throw out a few predictions as to how I feel technology, and more specifically the app world, is going to change after this is over. What kinds of apps will consumers want, what kinds of apps will entrepreneurs build?

Keep in mind this is just my opinion based on my own experience, and should not be taken as anything but that. That being said, lets start with the big question: what sorts of apps are going to be big after the coronovirus scare of 2020?

I’ve had an increasing number of conversations over the past few weeks about both React Native and Firebase — mostly with non-technical founders who have been advised by those they trust that, before they embark on their app development, they should choose one (or both) of these technologies at the core of their stack.

I want to very briefly give my take on both of these, as a developer who has used both, and advised both for and against both.

Big things start with a simple idea. But what I want to talk about today is how that simple idea grows bigger successfully. Specifically, I want to look at the very first step I believe all entrepreneurs should take before setting out to turn their grand vision into reality!

The vast majority of projects I have worked on in the past have come to me in one of three states:

• The founder has an extremely simple, short and concise idea, and they are ready to build on that idea with the help of a technical consultant
• The founder has an idea, and a big roadmap of features they eventually want to build — and they’ve been turning this idea over in their head for months or even years, refining and adding and removing features along the way
• The founder has already started building, and along the way things got complicated, convoluted, confused or chaotic in some way and they need help getting it back on track.

My dream client is in that first state, of course. But more often than not, the founder is in state two, and has a big list of features they want at launch. But in order to avoid walking blindly into state 3, we need to take a step back and ask a couple questions first…

For a lot of non-technical founders setting out to build their product, it can be hard to understand just how much work needs to be done before you write a single line of code! In this post, I will break down much of the ground work that needs to be done by your tech team before you start to actually build out your product.

This initial setup involves getting the following ready:

1. Setting up your accounts with the app stores you plan to launch in
2. Setting up your cloud hosting and database hosting plans
3. Setting up your domain and configuring your SSL certificates
4. Setting up your code repository
5. Setting up an alpha/beta testing process for pre-release testing
6. Setting up your task and bug tracking system
7. Choosing the framework(s) you plan to leverage to build out your technology

While all of these steps are fairly straightforward, and common to just about every development project, they are nonetheless absolutely critical, and in some cases the decisions you make here can affect your company in the future — sometimes even very far into the future!

So let’s take a look at them one by one…

Hands down the most terrifying phase of building a new tech startup is launch. So many pieces of a very complex puzzle have to come together at exactly the same time in exactly the right way for things to go right.

If you’ve never gone through it, you may be wondering what on Earth I’m on about. After all, isn’t the goal just to get the product out the door as fast as possible? Release early, release often and all that, right? Well, not in my experience. I have actually witnessed many products that launched way too early! But more importantly, I’ve seen teams that launched way too wrongly.

While experience is helpful in getting all of those moving parts in sync and timed up perfectly, it also contributes to that overall dread. The more products you’ve launched, the more you know how many things can go wrong, and just how slightly one variable can be off to throw the whole machine into chaos and, worst of all, how much luck is actually involved!

The March update of Graphite Comics just went live. It’s one of those updates that is very significant, with major changes under the hood — but which users will almost certainly not notice at all.

This makes for an interesting opportunity to talk about balancing needs in software development. In this case, we are looking at balancing speed and efficiency against operating costs. And even more interestingly, we can look at an example where a technical decision that improved efficiency and user experience evolved, over time, to actually have a detrimental effect on user experience!