Early in my career pretty much every product I worked on was an area for experiments. Some of them were successful, but most were not. My experiments usually involved using some new technologies to solve common problems.
Many times I failed.
For example, I’ve:
- used beta versions of frameworks which got abandoned.
- built product architectures which were too complex and unnecessary.
- did a lot of things that contributed to my personal knowledge, but not to the success of the product.
Every founder needs a technical co-founder or someone with engineering background you trust a lot. This essay is for someone who doesn’t have such a person.
The advice consists of three steps for non-technical founders to do in order to lose less time and money on engineering experiments.
1. Use a proven technology stack
To succeed, early stage founders are forced to build their product fast. To run experiments which often result in complete rework or dismissal of some features. The code of the startup is a battlefield and the startup itself is a war.
Adding new technology in the middle of the war is not a good idea.
Until you test technology in production, it is an assumption it’s going to work well. The first to test new technologies takes most of the risk. It’s smart to rely on something others built and tested in production.
Twice a year, Technology Radar publishes their notes on testing various tools. There are a lot of great starters, like Create React App, that solve common technical problems straight out of the box.
For 7 years we’ve built and maintained Ship to quickly and reliably build, launch and scale products.
So, to make sure you use a proven technology stack, check that whatever your team used is:
- popular (most of the time you can use Github stars as indicator)
- used by others in production for 1+ year (use Technology Radar and other trusted sources to validate this)
Your technology stack consist of two main parts:
- Frontend
- The framework (e.g. React)
- State management (e.g. React Query)
- App structure (e.g. Ship frontend)
- Backend
Write down notes for all the items on the list above and make sure your team uses popular and production tested solutions. Talk to your team or find someone outside your company to help you decide on your stack components if you’re not confident in your team’s choice.
Build less
Many founders do not realise the costs of software development. Your product and technologies grow old very quickly (Google rewrites products every 8 years). You get more and more code to maintain.
Every year you’ll invest significant amount of your budget into reworking the existing applications. If you choose to not improve your technology, your ability to release new changes quickly will slow down with time.
So… Build less! The less you build, the simpler it is to maintain and continue growing your product.
Here are a few ways to build less:
- Do not build a solution that scales: If you’re building the first version of your product, just build something simple that will only scale for 6-12 months. Solutions that scale to the level of the ambitions you likely have are way more difficult to build. You’ll end up spending much more time to build such solution, while you need to focus on just getting customers to use your product.
- Use no/low code tools: Like Retool for the admin panel or Webflow for a landing page. Research to find other no-code tools for big features on your roadmap.
- Do not automate simple things: Manual work is OK. If you choose to automate — use automation platforms like Zapier. By using automation tools, you can connect different applications together, but write as little code as possible.
- Use hosted product solutions: Like Stripe checkout, Plain Link Web SDK and others to quickly build parts of your product.
Here is a great overview of technology stacks that allow you to write less, build less and ship faster.
Monitor bugs and downtimes in production
These are two things every founder wants to avoid, but they still keep happening. Even the most successful companies in the world have bugs and fail from time to time.
It doesn’t matter how many tests your team write or how much time you manually tests things before publishing to production. Bugs and downtime are still going to happen.
Big companies know immediately when there is downtime or bug that affects their customers. It’s easy and important for you to know as well.
Just ask your team to help you understand if they:
- Implemented errors and info logging: So when there is an error, you always know the error has happened (be aware of the error) and have the context (can resolve this issue fast).
- Created software failure alerts: The alerts signal when something bad — something that affects your customer experience — is happening. Your customers might not able to create anything because the database is out of space. You might see 100s of errors in a few seconds because of a critical bug in your software. Regardless of the root cause — you should know about the problem immediately.
- Have a process for fixing production failures: Normally, when something happens there should be a designated person who is responsible to read, understand the error and deploy a patch if an error is critical.
If you log, monitor and fix unexpected errors your are on the right path to creating a great user experience for your customers.
To sum up, these are the steps I recommend to non-technical founders to build a better product and, as a result, a better startup! It’s best to follow them in order 💡
Logically, using proven tech and building less will reduce bugs and downtime. Letting you focus more on gaining, understanding and delighting your users.
Written by Andrew Orsich. Thanks to John McTavish for reading drafts of this.