In the last 5 years at LETO, we’ve gained a lot of experience building digital products, especially at early stages. In late 2011, we started as a startup agency, then slowly moved to building startups for enterprise clients. I want to share my thoughts and observations on what works and what to avoid in the early stages. Most tech decisions that save development time is good in the early stages.
Even if you run a product within a large company, there are still risks of running out of money, as your product can be killed easily.
Startups might be easier to keep alive initially, as you have founders who are likely to continue working on the idea part-time, even if there is no money left in the business bank account, selling cereal boxes to keep working on the product, Airbnb-style.
Build less than you need
Initial versions of your product might not need all the features you want to do. If you think your competitors have some feature, so you must have it, do the research and find the niche where you will have an advantage.
You can save time on parts of your admin panel, as your users won’t see it. Having a set of scripts you need to run manually and takes only 5 minutes of your time is a million times better than creating the same set of features that take a few weeks of work.
Also, if you build more than you can handle, it will be harder for you to remove these features, as users will expect these features to be there. Remember, any tech product has diseconomies of scales. The more code the project has, the harder it becomes to support and build on top of it.
Things will change
Lots of things can change in the first phases, especially with how things work on both the frontend and the backend. That’s why it’s important to start with a good code architecture. If you have a spaghetti code and the same code in 2-3 places, it will be harder to update or remove this code, and it might lead to more bugs.
Initially, you would need to invest in the process and tools that help you automate the development, testing, and deployment.
Automated tests enable your developers to run a command and see if the code works as expected. It’s helpful, but my general advice is to avoid automated tests for 90-90% of the code before you have a product shipped. It saves a lot of time, as these tests sometimes take the same code to write as the functionality they handle. Also, it doesn’t guarantee you will cover all the bugs.
However, it’s best to cover any code that handles payments and other critical parts that relate to legal or other regulations.
Make sure you have a good Developer Experience, and it’s easy to start working on the product. Ideally, you want to reach a point where it takes less than 10 minutes to start working on the project. There are a few tools which allow you to do so, for example, Vagrant and Docker. I used Vagrant for more than 3-4 years, and it works great; it saved a lot of time, especially with more complex projects.
Use the same environment for development and testing purposes. You need to have a reproducible environment, which is as close to your production as possible. This will help you to avoid many issues with different dependencies, especially if you develop on Mac or Windows, but the server runs Linux.
Focus on speed
Make sure your engineers understand it is crucial to have systems in place, so you don’t waste time you don’t have. Any product, whether in a small startup or even in a bigger company, is at risk of running out of money. If you are a startup and don’t hit the targets, your investors might pull the plug; if you build a project in an enterprise, your project might get killed if it doesn’t meet the KPIs.
Ideally, you want to get to the point where you ship new changes every day or two (from start to production). Some companies do 10-20 production updates a day. You need to have processes in place to do it.
It’s a bad sign when you hear from your engineers they found this new cool tech they want to use for the product. It’s even worse if they use it as a core tech of your product.
If you have a possibility of using a tested, proven technology, especially if your engineers are familiar with it, use it.
There is little benefit to using new technology simply because some big startup made it. If that company has released a new tech, it means they couldn’t find the solution to their problem, so they thought it would be cost-efficient to create the solution themselves.
Plus, the ecosystem might not be at the point where it’s easy to find solutions or support for the issues you run into.
Remember, Mark Zuckerberg used PHP, which isn’t a very elegant language. He simply had a product to build and focused on that. If instead, he spent the first 2-3 months learning some new cool programming language and then implementing Facebook in it, I doubt we’d have Facebook at all.
Don’t compromise on the User Experience (UX)
Good UX takes time to both design and build, but don’t save money on it; it will pay off in the long-run. Plus, good UX can create positive emotions that might create a better attachment to your product.
Business users are more tolerant to bad UX and bad UI. Corporate software is a nightmare to use, but this will change with time, simply because bad UX and UI take more time to complete the task.
Thanks for reading this far, I know it’s a long post. I plan to write more on the topics above in separate blog posts. Subscribe to my newsletter if you want to be notified when these posts go live.
Also, if you need any help with your project, get in touch with me at [email protected], and I’ll be happy to help.