Hey all! 👋 I’m Ryo, a Sr. Design Technologist at PlayStation. I do web dev with React/TS/Node and game dev with Unity/C#/C++/OpenGL/DirectX. Feel free to ask me any questions! 🤘
Use your own money. If you want to build a product, build it from a place of financial stability, because startups are moneysinks.
Use technology you've never used before. Get experience with it under your belt, or work with someone who has. Nothing worse than building a production stack with experimental tech.
Forget about marketing. It's easy to work on your product and get lost in a hole of development and not do the due diligence of marketing your brand and product properly.
Try to build a product from the beginning that scales to infinity. Build an MVP that works, and iterate from there. Every major company has had a rewrite or shift of their codebase, and like John Romero says, the future you will always be a better coder -- so leave it to him.
Do
Validate your idea before you develop your product. So many people leap into startups with a problem they'd like to solve, without ever creating small-scale experiments or interviewing potential clients.
Organize your development and fundraising in separate rounds. You're either making your product, or you're looking for investment. Never both at the same time. Spend a week building out your product, then another week reaching out to investors. Then keep alternating. If an investor reaches out during dev week, tell them to wait until investment week. It's a great strategy to see who takes you seriously.
Talk about it your idea as much as possible. It helps flesh it out, iron out any kinks with your plan, and it's a marketing tool (depending on who's ear you bombarde).
Partner up with a business/money person if you're not good at it. If you're the CTO of the company, who's going to be the CEO or COO? Those are usually the roles that lead the business and it's operations, and help guide the product in a profitable direction.
I'm a programmer who likes games, and wants to make games for a living. At the same time, there are some really cool non-game things I want to work on -- especially if they use C or C++.
I wholeheartedly remember talking about your product, especially with people who are experts in the area. It's a great way to see the holes in your idea before they become showstoppers. So many things can be fixed at early stages that'd be unmanageable beasts later down the line.
1.Going full blown on the tech and writing code without a clear validation of an existing problem you are solving. Or not having a clue what your potential customers are. 2.not taking sales and marketing as serious. Kills most startups.
I'm an extrovert developer, but I still am in the process of creating a business that provides massive value to the world, so take whatever I say with a grain of salt.
I've work in startups with and without VC. What I've seen is that there is a lot of chaos and on the manager level, an astonishing lack of understanding about what technology can do.
That usually drives to really poor hiring decisions and ask for vague requirements that usually are incomplete, not a great solution and late.
DON'T
Assume you know everything.
Play finite games.
Try to get more funding just because you have a startup.
I'm a cross between a developer and product manager and I've been bootstrapping a business for a year now. This is great timing as I just wrote a retrospective on it. It's fairly long but here's my TL;DR:
(1) Don't quit before you have serious traction. It's really easy to burn cash building a product and it might take a few iterations to find something people want.
(2) Put your coding skills on the side and focus on validating your idea with mockups, landing pages, fake PR release. See if people would use what you're showing. Even better, ask them if they'd pay for it.
(3) Work on a vision that goes beyond the features. It'll allow you to cut scope, find help, talk to investors. Features live and die, stories stay.
(4) Don't go stealth. Show your work early and seek feedback. There's very little chance that someone will be able to steal and execute on your idea.
(5) Set some targets before you start. It's easy to think that you have more time, more money, etc if you don't do that. Having goals will help you understand what's realistic because you'll see if you miss them or not.
(6) But don't panic if you miss your targets at first, everyone does. What's more important is to evaluate if you're constantly missing or if you're getting better at it.
(7) Accept that things will be slow. You'll see plenty of articles talking about such and such project that got in 6-figures revenus in one year. Don't worry about it and focus on having a steady growth and a great relationship with your users.
I think that coming from development (1), (2) and (3) are the hardest because if you have the skills to build something it's very tempting to do that first. I'm constantly reminded of a quote of Stephanie Hurlburt that said something like "If you know you can build it, focus on selling it first".
Know very well your industry and only build things that solve a real need not one you may think exist, in other words if your building a solution to "scratch your own itch" probably you're not the only one that has it and some market research could help you validate the idea.
Get a partner who you can have a proper professional relationship with. They will keep you motivated and honest about what you can achieve. This not always possible with friends.
Try to make money as soon as you can (obviously). Having to chase investers and deliver unrealistic scope to keep them happy will burn you out.
Don't chase the mythical "exit". Try for a sustainable income for yourself and your colleagues. This is an enviable and realistic goal (one I haven't managed to achieve but would f-in love to)
Know your strengths and weaknesses. This will change over time, but self-awareness is key in entrepreneurialism.
Don't rush into partnerships, and expect that nobody will care about your idea for a long time. Even friends and family won't really care.
Listen to feedback, but take it with a grain of salt.
Thanks for your insight, Ben.
Don't
Do
I wholeheartedly remember talking about your product, especially with people who are experts in the area. It's a great way to see the holes in your idea before they become showstoppers. So many things can be fixed at early stages that'd be unmanageable beasts later down the line.
this comment was pure gold
1.Going full blown on the tech and writing code without a clear validation of an existing problem you are solving. Or not having a clue what your potential customers are. 2.not taking sales and marketing as serious. Kills most startups.
I'm an extrovert developer, but I still am in the process of creating a business that provides massive value to the world, so take whatever I say with a grain of salt.
I've work in startups with and without VC. What I've seen is that there is a lot of chaos and on the manager level, an astonishing lack of understanding about what technology can do.
That usually drives to really poor hiring decisions and ask for vague requirements that usually are incomplete, not a great solution and late.
DON'T
DO
Here are some great books that I strongly recommend:
Just yesterday I was reading this article: What Tech Stacks are Indie Hackers Using for Their Apps, and Why?
The general theme is to keep it simple :-)
I'm a cross between a developer and product manager and I've been bootstrapping a business for a year now. This is great timing as I just wrote a retrospective on it. It's fairly long but here's my TL;DR:
(1) Don't quit before you have serious traction. It's really easy to burn cash building a product and it might take a few iterations to find something people want.
(2) Put your coding skills on the side and focus on validating your idea with mockups, landing pages, fake PR release. See if people would use what you're showing. Even better, ask them if they'd pay for it.
(3) Work on a vision that goes beyond the features. It'll allow you to cut scope, find help, talk to investors. Features live and die, stories stay.
(4) Don't go stealth. Show your work early and seek feedback. There's very little chance that someone will be able to steal and execute on your idea.
(5) Set some targets before you start. It's easy to think that you have more time, more money, etc if you don't do that. Having goals will help you understand what's realistic because you'll see if you miss them or not.
(6) But don't panic if you miss your targets at first, everyone does. What's more important is to evaluate if you're constantly missing or if you're getting better at it.
(7) Accept that things will be slow. You'll see plenty of articles talking about such and such project that got in 6-figures revenus in one year. Don't worry about it and focus on having a steady growth and a great relationship with your users.
I think that coming from development (1), (2) and (3) are the hardest because if you have the skills to build something it's very tempting to do that first. I'm constantly reminded of a quote of Stephanie Hurlburt that said something like "If you know you can build it, focus on selling it first".
If you want to read the full post to see what my journey has been it's here: medium.com/@stenpittet/a-retro-on-...
Know very well your industry and only build things that solve a real need not one you may think exist, in other words if your building a solution to "scratch your own itch" probably you're not the only one that has it and some market research could help you validate the idea.
Some lessons I’ve learned from a start-up I worked at which failed :)
Get a partner who you can have a proper professional relationship with. They will keep you motivated and honest about what you can achieve. This not always possible with friends.
Try to make money as soon as you can (obviously). Having to chase investers and deliver unrealistic scope to keep them happy will burn you out.
Don't chase the mythical "exit". Try for a sustainable income for yourself and your colleagues. This is an enviable and realistic goal (one I haven't managed to achieve but would f-in love to)
1) Identify the domain of the problem you are trying to solve
2) choose the tools accordingly don't jump on the hype bandwagon