Since the company started, we have been promoting 1–1 introduction meetings. A 30 minutes free space we make available for any founder to talk to us about the problems they are facing with their products to see if we can help them with some guidance or even collaborate together.
This allowed us to spoke with many first-time founders. During these conversations, what we’ve found is that most of them keep making basic mistakes that cause their product to attempt against the business soon after launch.
The top common scenario always is:
“Our product worked well for a few months, but now is hard for the team to make additions with the current code. A change over here breaks something over there and that delays our roadmap.”
From that point is when we notice the path repeats itself:
- The “team” is actually different contractors working in silos. Most of the time, one group creates and launches the product and another is required to make the future changes. Each group brings its own development patterns and principles onto the product
- There isn’t a staff person who is accountable for guiding the core engineering aspects. Contractors takes all the technical decisions by themselves
- The technology used on the product depends on what the company hires and that hiring is made according to the best price offer. Sometimes, changing a contractor means that a new part of the product is made with a different technology
- Since the contracts are usually hourly basis, founders prefer contractors to avoid creating or maintain any kind of documentation and focus on building only
Of course, we are all hardly perfect, and the product path doesn’t always work out exactly the way we want it to. There will always be economic, business and timing reasons that make founders take those decisions and that’s fine.
After hearing from so many people struggling with this scenario, we’ve have decided to put together three tips for new foundersto help them gain more control over their product paths. We’ll explain them in plain english so, you can understand the value and get a better analysis of your current situation.
1. Choose consciously the programming language
Here is the impact it has:
- Defines the budget you need to invest
- Limits the product possibilities
- Limits the development resources market in size and price
The market follows the trends. Some languages are considered olds or not practical for certain types of development, you will have a hard time finding a replacement if a contractor leaves you.
On the other hand, there are some languages that are relatively new or most-wanted for companies with only a few people capable of doing a good job. This makes them expensive to replace, you will need to pay $$$ or hire a trainee and let her/him learn it.
- Limits the support resources available
Let’s be clear, nobody holds all the answers. Every language has its own support community where developers can go to find help. Some communities are bigger and with more resources than others, this makes it easier to solve problems quickly.
If the help you want doesn’t exist, you will need to take the time to investigate and contribute.
What we suggest:
- Define a 3-year company roadmap
This will help you understand how’s the product expected to grow in order to support the business strategy. With this information, you can analyze the different phases the product will have and use the assigned budget accordingly.
- Research alike products
There are different ways to know which technologies were used on a product, for example: for web apps, you can use the chrome plugin Wappalyzer. This will let you know what is the most commonly used language.
- Look for an expert point of view
Just don’t take only the contractor recommendation, they will mostly offer you the languages they work with. Find an expert to ask if the language is recommended for the type of product you’re expecting to get and what are the variants that could be used.
- Get to know the market first
Ask local recruiters about the quantity and price range of resources available in the local and national markets. This will give you an idea about how the prices may change in the future and how many options you could find.
2. Use a development framework
It is a reusable piece of code that makes it easier for developers to build applications quickly, offers pre-built functionalities that are easy to adapt to the product.
Here is the impact it has:
- Makes your team build faster
There are certain tools, functionalities, and components that every website or app have in common. Developers don’t need to reinvent the wheel nor start from scratch.
- Push the team to be proficient in good practices
Every framework sets the way the developer should code, making them follow technical standards. It also defines how the project should be structured in order to be both, maintainable and scalable.
- Makes the project onboarding for new team members easier
Each framework has its own documentation were is explained every aspect of it. This also reduces the consulting time other members do to introduce the project.
- Gets you a specialized support community
When the framework support team founds a problem, the solution is shared with everyone and the code is updated with the fix. Usually, you can pay for premium support to help your team resolve any particular problem.
What we suggest:
- Choose an active framework with a support community
Not all the existing frameworks are active, it means that the team that built it doesn’t keep working on it. This will cause that some components will be outdated and may cause errors or limitations to the product.
- Avoid using a small framework
The main idea is to choose one framework that resolves all the components you need, or the majority. There are basic frameworks with only a few components available, this will make your team resolve the missing components with libraries that may not be aligned with the framework defined practices.
3. Keep a basic documentation
There are different types of information you need to document on a project: tool accesses, requirements, technical comments, business logic and code changes.
Here is the impact it has:
- Gives you total control over the project
As the owner of the product, your staff must have all the necessary information to keep control over who works on the project and what information they can access to. Also, it will give you access to dig more on the cost of each tool used.
- Makes any team change smooth
It allows you to avoid missing important information during a project hands-over between contractors. The documentation can speed-up the transition and ensures the new team will count with every they need from the beginning.
- Helps you keep an eye on important things
Documenting technical comments and business logic will guide you when addressing new requirements. It makes it easier to measure the impact the new requirement will have over the existing implementation.
- Helps you manage release problems easily
Tracking code changes gives you the autonomy to undo any change that may cause a problem, to go back to a previous version of the product or to identify what changed from one version to another.
What we suggest:
- Keep an internal record of tool and accesses
You should be in charge of keeping the accesses for the project in an excel file of your own. Also, you should control which email account is the team using to register on the tools needed for the project, because there is where the notifications will be sent.
- Keep a register of the requirements made and bugs left
You should keep track of the requirements developed by the team during development periods, it will help you to know when they were made. Also, it is important to track the bugs left to be resolved in the future. An easy-to-use tool for this is Trello.
- Make the team informs you about important technical comments
An important comment is something that can limit a product functionality. It is important to keep track of this because it becomes useful when analyzing new requirements.
- Use a repository to keep the code tracked
Github and Bitbucket are the top used code repositories tools. Make your team use it as part of their development process so you can track each change.
We know that the product path will ultimately look different for every startup, but we’ve found that these recommendations are a good common starting point. Understanding them, will allow you to make informed decisions on engineering definitions that can affect the future of your company and that today are being left for contractors to take.
¿Are you interested in participating in a 1–1 introduction meeting? you can present your product and comment on the problems that are stopping you from growing. If so, send us an email to [email protected]