10 things a non-tech founder should know to run a tech startup
Running a tech startup generally requires you to stay ahead of the technology curve and the business expects you to know all the jargons and nuances related to this ever growing tech industry. This is quite a task even if you are a tech wizard but becomes too difficult when you don't have a tech background. And the way world is moving even non-tech startups are dependent on tech. Maybe you are building an EdTech platform and you know how to sell, or you are building a FinTech solution and you are great at numbers, or it could be a food delivery app and you know how to run the business in FoodTech. So it's completely fine if you don't know the tech behind it, you can hire people or outsource to a technology partner. But I have seen things going wrong here many times. This comes from both the parties, I have seen impatient founders not listening to the tech team and dropping the ball and I have seen tech companies charging heavily and running around in circles finally leaving the founders with less money and a setback of months or even years at times. For impatient founders, I would say ask the right questions but trust the people you have hired. So here I will help you understand what are the right questions to ask.
It's very easy for someone to overvalue or undervalue something that they are completely unaware about. I can't tell what my dentist is doing or how my car will be serviced by a professional. There are too many details and specifics which are beyond my knowledge in these cases and so we reach out to professionals. Similarly we have people reaching out to us or other tech companies for tech solutions, they don't care what fancy language we use to write code or what fancy tools we use, all they need is a solution which can help them grow and add value to their business and although most of us try our best to keep that trust bestowed on us and work our hearts out there are companies/people who are breaking trusts. I am writing this because I have met many founders coming to me after a bad experience and I can empathize why they are so much wary to start with. All I want to say to people breaking trusts to make quick cash by delivering sub standard results is With great powers, comes great responsibilities
You know better.
I don't want you to become a tech expert, I am sure you are already good at what you do. All I am asking is to get familiar with few things so that you know what to look for.
- Server: Simply put it's someone else's computer running code for your project so that it can be viewed/interacted on via the internet on www.yourprojectname.com. You may also come across the term cloud a lot many times, and these are just providers running that server computer for you 24x7. Here are 3 most widely used cloud providers.
1. AWS by Amazon
2. Azure by Microsoft
3. GCP by Google
Choosing either of this can depend on the type of problem you are solving and the current stack you already have. Your tech consultants should be the better judge to choose from these but you can ask questions like a comparison of pricing for running your application on these.
2. Environments: All the tech projects go through a lifecycle from development to release. Environments are different servers to differentiate your features in development and the features already tested and shipped. Again depending on your team size and kind of work the number of environments can be following:
- Development environment: This can be the latest built version of your application hosted at something like dev.yourprojectname.com or test.yourprojectname.com. The idea is to have the features in development live on a server for you and your team to test before making it live for public. Since this environment is for you and other limited people you can keep this server configuration small (You can even use services like DigitalOcean which provide servers as cheap as 5 USD per month )
- Staging Environment: This will mostly come in handy if you have a separate team for QA(Quality Assurance)/testing, so once your development team has tested on development environment they promote it to staging environment for the QA team to test. Most early stage startups don't need this and can work with 1 and 3
- Production Environment: This is your live environment where you expect your application to be available to end users. You can make smart judgements by looking at costing of your environments and making sure you are putting your resources in production and cutting in other environments.
3. Version Control: Version control systems are used to keep your code safe and at the same time make it easy for the developers to collaborate and share code. The most common Version Control system is Git and it has many web interfaces available, most popular being GitHub. If you have hired a tech company to build your project or if you have hired freelancers, in all cases you should make sure your contract states that the code written will be your property even after the end of contract. You should start by creating an organization on GitHub and make sure all the code written is pushed to your organization. I have seen developers/companies writing code in their repositories leaving the client without code at the end of a contract, which means the client will have to restart the process of building the application again
4. Backend Code: To simplify you should know that if your website/application requires dynamic data like letting user's signup/login, create content, etc you are most certainly going to need a backend. Apart from static websites where you display information you will need backend code in most of the cases. You will come across the term API while working with your team a lot many times, they just mean a endpoint which does some action based on your business logic. There are many programming languages like Python, C#, Java, Node, Ruby, PHP etc to get this job done, and your tech partner should be the right entity to decide this but you should make sure when they choose language they have reasons backed with data and not preferences. All languages have pros and cons and ask your consultants to provide some facts and figures to justify their selection.
5. Frontend Code: Again simply put it is all the part of the interaction that you can see on the website or the app. The colors, fonts, images, buttons or the overall look and feel of website/app is the frontend code running. You will need people skilled in HTML, CSS, JS to take care of this part. You may ask them if they are building your frontend on React, Angular or Vue, if yes why, and if no why again.
6. Database: Database is a technical representation of all the data that you want to save and retrieve. You should ask your consultants about which DB they are using and why, you should also ask about backup policies so that if DB is deleted or corrupted what will happen to your data.
7. Development Process: It becomes quite a task to manage a work you don't understand. This may lead to frustration on your end or at times slacking off at the developers end. There are many ways to do this but a good start is giving your development team business requirements and then asking them to convert them to tech requirements and breakdown them into issues(term used on github)/tasks. One good rule of thumb is to make sure no task is longer than 8 hours of work, if it is longer than that ask them to break it down even further. Then create priority wise milestones and the development team can create a Kanban board to give you an overview of what is being done, what is done and what is to be done. This will help you understand the progress by just looking at the board and prepare for next steps in the business pipeline. You can set a clear and fare rule that no one can be working on something that does not have task created for it. It helps the team to be on track and for you to know the status. Also for communication I have seen many founders relying on WhatsApp groups, while it may be easy to use but for a proper organized communication you should switch to something like Slack or MS Teams.
8. Documentation: This is something almost all developers hate to do but miss the most when it's not given to them. With time your code base increases in size and it becomes difficult for a new developer to join and contribute so make sure you are constantly asking your tech consultants to create and maintain following development documents:
1. Architecture Diagram: A overview of all the different services and their connection and interaction
2. API Documentation: A documentation to define all the APIs with their input and output expectations. Swagger documentation will help you a lot in this and will also help you reduce dependency between frontend and backend teams.
3. Schema Diagram: Your database is one of the most important asset in your architecture and with time and requirement it will keep changing shape, make sure your tech consultants are updating the schema diagrams frequently.
4. Setup Documentation: For any new team or developer to start contributing it's important they are able to run the code on their system first, make sure your tech consultants are writing proper setup guide. Ask them to create docker and non docker setups. A quick check for this step is to read these steps and repeat on your system, you should be able to run it on your system even without any coding knowledge.
9. Testing: No matter how much you test, you will always have bugs because of unimaginable edge cases but having a proper testing strategy can always help. Ask your team to share a list of smoke testing items, which determine a bare minimum of steps that must be running at all times in your system. These steps can be tested after all releases manually by you or your testing team. You can also ask your tech consultants automate tests and create scenarios and test cases for major areas of your application.
10. Deployment: Deployment is the process of moving your code from one environment to other, so that it is accessible by the user group of that environment. When a code is deployed at dev environment the developers or testers can access it and test and when it is deployed to production it will be available to your user base. Make sure you ask your tech consultants to document to deployment process and incorporate CI/CD(Continuous Integration/ Continuous Deployment) pipelines, this helps in automating the process of releasing and rolling back. Your system should be capable to roll back to a previous stable version if things go south. All this is done smoothly and without a mayhem if the process is automated. So make sure you are asking the write questions regarding your deployment process.
We at Phyniks are committed to build long lasting partnerships while making amazing products, businesses and memories. We make sure we are following these in our projects on day to day basis. We are also learning, unlearning and relearning everyday and so we will keep on improving on the processes while keeping everything transparent and public. If you want to discuss how we can help you in your business, book a free consultation call at https://calendly.com/phyniks