Checklist for non-technical founders

Is a dev shop, agency, friend, or an offshore team building your product?

If you answered yes, then this article may help you.

I recently spoke with a few non-technical founders who were having their products built by others.

I noticed a trend, and my advice to these founders was always the same, so I decided to write it down in hopes that it might help you.

Here are the issues I noticed and the advice I gave.

Own the code

Some of the founders I spoke with didn’t know where their code was and had never seen it. One founder couldn’t even retrieve it from their last developer.

✔ It is important to own and control the code you’re paying for!

I recommend you create a github.com or a bitbucket.org account to store your code.

You will need to grant write access to the developers so they can upload the code.

In Github I recommend you create an organization and teams.

An organization is a collection of projects.

A project is what holds your code. For a mobile app, you might have a project for the Android code, a project for the iOS code, and a project for the app server code.

A team is a collection of users.

A team (set of users) can be given access to your organization and all of its projects.

Doing this makes it easy to add and remove developers.

Another perk is that you can see all of the activity. The files that were added, removed, or changed and by whom.

Own the accounts (app stores, SaaS integrations, etc…)

Most of the founders I spoke with didn’t have access to one or more of their accounts.

Your application will require many accounts. These might be app store accounts, software integration accounts, email accounts, etc…

✔ You should be the owner/admin of all your accounts.

If you’re developing a mobile app, you should be the account owner for both the Apple and Android app stores.

For both of these, you will be able to invite the developers and grant them access to your apps. Maybe you only want to grant developers the ability to upload new app versions but deny them the ability to publish them.

You should be in control of who can access your app store account and who can modify it.

You might have other accounts for things like 3rd party SaaS integrations. An example of this is Twilio. Let's say your application uses a Twilio phone number to send SMS messages. You will need to grant the developers access to your Twilio account so they can set up the integration.

Owning all the accounts puts you in charge of who can access what.

A good developer will ask you to create the accounts and invite them.

Own the cloud

Most of the founders I spoke with knew they were using the cloud but didn’t have the account information and didn’t know any of the details.

If your application includes a website, API, or backend, then you are using cloud resources, like AWS, Google, Azure, Firebase, Heroku, etc...

✔ You should be the owner/admin of your cloud account. You should also understand what resources are being used an why.

These resources have a monthly cost associated with them.

For the first 12 months, it is usually free. You should ask your dev team what the monthly cost will be after the free period is over.

You can grant developers read or write access to your cloud account.

Know your stack

Some of the founders I spoke with knew a little bit about their tech stack, but not many. Unfortunately one was using a, less than desirable stack.

✔ The application stack that is used to build your application is important.

An application stack is the programming language, frameworks, libraries, tools, and cloud architecture, that is used when building an application.

It would be bad if your application was built with an old, unpopular stack that not a lot of developers wanted to work on. It would be hard to find developers to work on it in the future.

It would also be bad if your application was built with a totally new stack that hadn’t been adopted by the community yet. Some devs just want to work on the newest language/framework/library. The problem is that this new language/framework/library might become unpopular or abandoned.

Before you pick a dev team ask them what stack they plan to use. Run this by a few developer friends of yours to see what they think. This is also a great resource to see what everyone else is using and what is popular, https://stackshare.io.

Get deliverables

None of the founders I spoke with were happy with the deliverables they have and were receiving, especially after I told them what was possible and in their best interest.

✔ It is important to get deliverables quickly and often.

A deliverable can be anything from an architecture document, design mockups, skeleton app, testing framework, new features, bufixes, etc…

Getting deliverables quickly and often is important because…

1.) It reduces your risk profile. If the developers you’ve hired are terrible you’ll know that sooner without spending all your money. Imagine if you only got one deliverable at the end of the project and that deliverable was awful. You would have spent all your dough for nothing.

2.) It forces your developers to implement a continuous deployment approach early, which is needed if you want to iterate quickly… which you do. The longer the time between when you ask your developer to implement something and when you actually see it the more money you will spend. This is because communication isn’t always 100% and things sometimes seem different when you actually use it.

Summary

The most important thing when building your product is to get to market quickly and with as little resources 💸 as possible in order to validate your product market fit.

It is also important to own everything and be able to switch developers when needed.

This list is by no means complete, it is just a list of the most common issues I found when advising non-technical founders. Please feel free to comment if you know of other major pain points that plague non-technical founders going it their own.

Thanks for reading my article. I hope it helped.

I know how much heart and energy goes into developing a product. Please don’t hesitate to reach out if you need help or just want to chat. I love helping founders.