How to correctly assess the technical complexity of your bootstrapped product?
We discussed why it's so important to correctly assess the technical complexity of a product (watch the discussion here). Especially for bootstrapped companies. There’s always going to be more edge cases than you’d think initially but your MVP should be simple and not buggy.
One of our earlier products didn’t even reach the MVP phase because we underestimated this phenomenon. And we did the same mistake with Welder. Now we have to face this problem again. Too many bugs, drawbacks, and unexpected edge cases. Too little development manpower to fix all of these in a reasonable timeframe.
Your customers won’t always follow the green path and your product should not fall apart and disappoint them because of that.
Do your homework, spend a lot of time assessing the technical complexity and think about if you will be able to deliver it. It's really hard to build bootstrapped product with little resources that are technically complex.
I have 15+ years of SD and still do mistakes (usually underestimate :)
I think it's normal, but we should try and strive to improve that cause it leads to many issues.
Once we were working for this already established and scaling startup. There was a Chief Growth Officer who had a lot of respect cause she came from the corporate world and all the young devs were feared of her. But that was the issue. All the devs were afraid to say out loud how long will the delivery take. So not only that they tend to underestimate but were also pushed to underestimate.
Well, the issue it caused (and still causes) is insanely huge.
That's easier said than done. First of all, the more complex the project is, and the more you update its UI/logic on the go, the more it'll take.
Unless you know the technology inside out, you will run into sooo many issues. Each new framework/library will come with its limitations/bugs/etc. which you will have to somehow overcome (hopefully). And bonus points if you use several frameworks/libraries.
Trust me, I'm learning new ways to curse MS every day.
Exactly! And this is important to know before you dive into project like that.
If you just want to play around it's not an issue. But if bet high stakes (for us it's making a living for 4 people) it's like playing a roulette, and that's not what you should do with these stakes.
Thus it's maybe better to pick projects and products that are less complex and you are able to assess them properly to have the "luck" and "data" on your side.
If you're not too technical, that's insanely true.
Well, it still boils down to knowing what you're doing. I would say sometimes it's worth taking the risk, if you do it right (like, have some money put aside, so you can have a decent living, and then set some time to try your idea).
I guess it's a good idea to start off with smaller projects, however smaller projects will usually mean smaller rewards. So yeah, take it gradually I guess :D
A business project is not just it's technical implementation
It's like of you were writing a book, assuming you could assess a book or it's creation to being more "complex" do you you'd find a high correlation to reward?
Sure, but a lot of it will rely on the developers. The wrong ones can certainly bring your company down.
Perhaps the correlation is just in my head - I guess there will be "simple" projects that will yield insane rewards, but I think those are usually the exception (once again, this might be just in my head :D)
Don't eat the lie of reward is always linearly correlated to effort and than further complicate it by applying it to only one part of the equation - the technical part of a product (which is itself a part of a business)
Love this conversation!
And I agree with @hatkyinc, less complex technically doesn't need to mean smaller reward.
But if you believe your main skill (leverage) is in building tech products, complexity might give you some IP that can lead to higher rewards as well as it might differentiate you from many others who could do the next "info product" but aren't skilled enough to do something this complex.
Which is a big dilemma right. I think it boils down to finding the perfect mix, I believe that's the mastery of doing business, being able to find the perfect mix that fits your strengths as well as the market.
So maybe if you're great at developing tech products, you should pick something more complex than building a simple blog, but be realistic and not building the next WebRTC framework. Building something "in the middle" so you have enough time and ability to focus on other parts of the business (attention, distribution, design, customer care, and many more) and by that building a successful business.
Get out of you little bubble and look at the big picture.
If your a technical founder, your already in 1% - 10% of business started
Don't compete against your own peers, so you don't have to be the 0.1% out of tech
That's why I think it's easier to focus on non tech niches
You'd be already 10x more capable than the competition doing easy, simple things, your already the 1% there
Don't forget you also have to compete on all other business aspects that's hard enough don't exhaust yourself with tech
It's also likely to be used unknowingly as your escape from actuality dealing with all the businesses needs cause your tech calls on you
It's the easy place, not the most important thing
Busy work
I kind of see where this is coming from, and it's something I have experienced myself. It's an interesting phenome I see regularly, and there seems to be two ways to get through this;
The first one (and correct me if I'm wrong) is where most people seem to get stuck with. The second one is much more difficult, complex, but at the same time more rewarding.
The following part is completely hypothetical, and something I'd like to validate, but I feel like most bootstrappers starting a SaaS project or something with similar complexity are mediocre programmers at best (no insult intended). Sure, many can create interesting things, but at the same time I believe many do not understand how to create software which one can effectively maintain for a long period of time.
I'd be happy to share exchange some ideas about maintainable software with anyone interested! My mailbox, or Twitter DMs are open!
Exactly! Most people tend to go for investment to hire more manpower and they hope it will fix the issue. Sometimes it works, when the founders are experienced and smart. But mostly, at least for new founders who got their first funding this can cause a death spiral.
The second option is to focus on the right problems and smart solutions (that doesn't need to be complex actually) to bring in important data s you can do the right decision.
And a great hypothetical point, I see this many times. And I believe from that comes the "idea" that you can do complex products, the bootstrap way without issues.
What it brings me to, and sorry for being so lengthy, is that people tend to underestimate things that they do not have experience with a lot more than things that are easily generally understood.
Yesterday I watched this video where a math guy debunked Minecraft speed run by Dream. The speedrun in Minecraft is highly dependent on luck and they had INSANE luck, like INSANE, but I was like "Yeah, but it could happen".
He showed some math and some other examples like that in a game of Craps one woman had a streak of rolling 2 dice without hitting 7&7 154 times. Which is INSANE luck too. But on that I was like "fuck that can never happen!" and the Minecraft's luck was like 2 times higher than the Craps record luck.
What it brought me to is that if the concept is known for your brain, you are less likely to underestimate the complexity / possibility of happening.
Thus it's like saying yourself you can bootstrap building an automotive company. In just 2 people. Well, you could, but it's extremely unlikely. Why do you think you can build a technically complex product on your and succeed in it?
Uff.. I went a bit too far right?
P.s. following ya!
Those are some interesting viewpoints! Regarding hiring smart people to solve the problem, that's a great thing to do if you have the money, and even more importantly, if you can hand off the work to those smart people without telling them how to do it. I believe this is part of a crucial transition phase for most founders which will either make or break their venture.
(Un)familiarity bias is definitely a thing when judging solutions, though I'm not yet sure how to place that within the role of a bootstrapper. Personally I think it is highly dependent on the person. Those with excellent technical skill may pull it off, but may also have trouble on other areas such as marketing, support or accounting. It'd be amazing to be able to fulfil all those roles, but I think most should be more realistic about the time requirement to be able to do so (as in a multi-year dedication).
Love this @corstian! And yes, handing off the work is a challenge, quite a big one after you figure out how to pay those people haha! I believe this is why so many people tend to go through the "proven VC path" because the framework for all of this is already laid out. You get the money, problem one solved, you get the network and mentors to help you hire great people and how to hand off the work for them, problem two solved. Hopefully haha!
And the second point of yours - that's why I believe having co-founders is so important, and that's what we do. It's a super-strength if it works well.
We actually shot a discussion on that topic two: https://www.youtube.com/watch?v=yKvIxWn0W3w&ab_channel=CrazyMonkeys
Hi Corstian
I am a new follower of yours, no insult taken...
Maintainable software is a thing I am striving for. I would like to take advantage of your offer -- I think I will drop you an email when the time is right.
Thank you!
Christian
Unpopular Opinion: having a difficult product to build can be good for your business.
I'm experiencing this is I get started with TensorFlowJS development. We are pretty much on an uncontested network with powerful technology to play around :)
I wouldn't call it "unpopular" opinion, I would call it "unpopular approach" - because people naturally try to collect low fruits what eventually may fail in many cases (I mean their trials not fruits :).
You are completely right. Picking on the edge technology or challenging problem will help you be there "first" and also build stronger IP.
But it's really important to do the assessment before and do it properly, at least if you want to stay bootstrap and it's a product you expect to make a living for you so you have limited runway.
As in the discussion we mostly did technically complex products in the past exactly for those reasons, but we always got to a point where the product wasn't stable enough to earn us cash and we didn't want to go for investment. The investment would've given us 1-2 year runway which would allow us to find PMF properly and hire enough devs to fix the hard problems.
But in bootstrap that's a bit different from my experience. You need to be able to build a prototype really fast and then build an MVP that will already start bringing some cash in so you can continue working on it.
Thoughts?
We tend to over estimate the complexity needed to be special
I think for IH it's better to go simple in a place that has just been neglected as unpopular and not compete on tech
Furthermore you compete on a package of things that is the business not on a single dimension
A niche can have high low and medium priced products (never strive for competing on price unless you have an actual cost advantage)
The can be divided by communities that have been marketed to or align with a "celeb"/influencer or be sliced by what is found on different platforms
Can be easy to use vs advance
Or have a modern look/compatibility
The customers rarely care about what's under the engine unless it is by itself the product
Nor will your competitors sweat you exact tech choices to the letter
Is this a question? A rant? Or just sharing some story?
Complexity can usually be compressed to "have you done this before?" Or how close is it to something you have done before
The width is around how many screens/functions/processes
And depth around how many details/flexibility do you need
Always try to itterate on "what can I take our of this and still have a functional minimal MVP?"
haha, kind of everything together! It sparked a nicer discussion than I expected!
And 100% agree, you should feel dirty by releasing the MVP in "that" state.
This comment was deleted 2 years ago.