Subscribe
Sign in
Should startups write good quality code or just worry about delivering the product asap?
53
Replies
Best
@mcflydev Amen to this. Focus on quality, but don't let it hinder your MVP tests, of course. It's better to create something very small that works well, than something big full of bugs and low-quality code that (may) hinder the product experience.
I think startups should write the minimum amount of solid code that delivers a good experience. If the app is too buggy, users will leave
@aorobator 100% - have to balance building out new features with cleaning up existing, both polish on features and fixing bugs too
I'd say a good architecture foundation is a must. Then I'd put focus on core 20% features which is used by 80% of your audience and made code for it rock solid and well tested. Then to trade time for quality and move faster, I'd consider reducing the quality bar for the rest of less used features and get an MVP or proof of concept faster.
I think it depends on your ambition. The try fast, fail fast doctrine is good if you are testing the market (and in that case shit code is adapted). In case you do have a Product Market Fit, good code means less technical debts that can just kill you at the worst moment...
What do you think?
@hugo_pochet1 yea this is spot on and well said - how ambitious you are and how confident you are that your product is actually something people want
Of course there's always a possibility that someone will be faster then you and no matter how good your idea is, the race winner takes it all. But also there's a big chance that with bad code your product will be unstable and then there goes the trust of the user. Nowadays the choice of almost anything is so big and the users are so picky, that it is extremely hard may be even impossible to convince a user to give your product a second chance.
I think a lot depends on your idea. If it's absolutely unique like you've created a new type of neural network for object recognition that performs times better than any existing analogs, you shouldn't worry about bugs in your UI at the start. Users will forgive. On the other hand, if you are building a new project management tool it should look very well and complete.
Also, you can make it simple, but it's better to make it right. If your code is terrible you won't be able to use it later. Or, what's worth, you can lose some user data because of a security problem and that may become the end of the story.
+1 to that. The more novel the product, the more you should focus on shipping fast to validate your "net new" idea. On the other hand, the more competitive the space, the higher your customers/users' base expectations will be, meaning you'll need to spend more time writing high quality code to avoid bugs in the short term and costly major refactors in the long term.
A very interesting question @andrei_gal. The most important thing is to build the audience who will be the users of your quality product. Quality code is great, but if the product doesn't serve your customer audience it wouldn't matter how quality it is. Focus on your customer first, deliver the product that you think they want as early as you can. Often people will not want what you think they want, and you will have to take a pivot after launch one.
PS what humans say they want, often isn't what they want in practice.
@natalie_furn good point! but if I give my prospects what they want, and it doesn't work, won't it backfire my startup?
Agree with @johan_duus_terkelsen but the other side of the coin can be ...
For me : code quality > more features
Code quality should be always a priority, even if you are releasing your MVP version because scaling becomes a factor when your idea is really helpful.
More and more people will start using your product if it is really solving some serious problem and saving huge time. so you won't get time to upgrade your code quality because you might become busy with programming new features for your customers.
The only way to improve code quality will be a complete revamp. 😛
I'd say it all depends on where you are at with your journey.
If you are still trying to validate your idea, see if you have a Product/Market fit or create an early prototype, then you may want to go 'quick and dirty'. Caveats on this though: the architecture should be properly done. It can bite you back nastily down the track if there is a critical architectural issue. And also, you have to keep in mind that the 'quick and dirty' will pretty much have to be thrown away and replaced by proper quality code to move forward.
When in a more advanced phase, where you have your grounds and you are starting to grow and eventually scale, then I would say good quality code is absolutely paramount. Not only because as @mcflydev mentioned bugs are a total deterrent to users, but also - and probably more importantly - because if you do not do it right, you create "tech debt" for your company.
As time goes that debt -like any other - can become extremely expensive and crippling.
This is dilemma... while you write a good quality code the environment changes or your competitor releases same thing in shit quality and get your users. So I thing the truth between this two statements
Actually it depends on many factors. I think the best way is release version 0 of any feature (product) validate the product (feature) market fit, then you have to make v.0 to v.1 and deliver better quality code
@max_kamyshev on the other hand, if you you work on product market fit and your tool works badly, the result won't be representative
Quality of product is #1 priority. Especially when app used sensitive user's info. Just one major bug in field of users private info and company's reputation is done
I think you should be working on improving product quality for the minimal version of the product. Make everything perfect for the first client. Then it makes sense to expand it.
Assuming you are still in the phase of trying to validate your idea and assumptions: I think you will always get a vague, "do something in between" answer to this question because the meaning of an MVP changes drastically from idea to idea and based on the judgement of the founders, etc. At this point if possible try to avoid code that invites bugs but make other sacrifices like building a backed that doesn't scale, etc.
If you have a validated idea and a growing user base, you cannot sacrifice the quality of your code anymore because that will most likely cripple your team in the future.
Just get the product out there! As long as it does what its suppose to - quality of code does not matter.
@ankit_dhawan1 @andrei_gal I think we need to clarify what bad code is. When i refer to bad code i mean code which is not clean, which would need to be reworked and de have issues in scaling but from a customer perspective it would get the job done and solve the problem you are trying to solve. Once you can prove you and have validated your idea you can worry about the code being good and clean. That is the best problem to have but why waste time otherwise? It's obv preferable to write great code from the getgo but it wont happen unless you are writing it yourself/know what you are doing.
Delivering the product asap. After you know that people are willing to pay for your product, you can then write good quality code. Point is: you can always improve later.
Writing good quality code in the beginning takes more time -- you should focus on making sure people want your product first.
@welly_mulia Yep but sometimes you can lose lot of time fixing the code you made at the beginning of the journey. I think to some extend, taking a bit more time to ship "OK" code is totally worth it.
I'd say it's also important to understand your target audience needs - if you code a B2B product got IT companies, then the quality might matter for them.
@andrei_gal If I will e.g., will order the food form your app, I'm not sure if I'll pay attention to code
I'll never forget how the CTO of Segment and PlanGrid referred to their early code https://youtu.be/tSW-GePDwn4?t=1360
I think it is better to write a small amount of good quality code rather than just rush for the quantity.
To my mind, good-looking code is a must since after you will receive market feedback and decide to change something or having to onboard a new developer - chances are that you have to fix tons of bugs or even build everything from scratch.
That definitely will slow you down. But it is important to ship fast meaning not to spend too much time building features and save time by lowering the number and the complexity of the features
ULY