Should startups write good quality code or just worry about delivering the product asap?

Andrei Galkov
53 replies

Replies

Anna Kachan Aytan
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.
JohanDT
Test the startup and validate the product asap - if that's possible with low-quality coding then go for it! Do things that don't scale :)
mcfly
If you write bad code, you gonna have many bug. Bugs makes trust go away, and as startup we now needs to makes users confident you can handle the job correctly. Don't rush too fast, build less but make it good.
Sune B. Thorsen
@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.
Serhii Ovsiienko
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.
Andrey
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.
Austin Yu
+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.
Max Kamyshev
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
Max Kamyshev
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
Artem Galenko
@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
Natalie Furness
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.
Andrei Galkov
@natalie_furn good point! but if I give my prospects what they want, and it doesn't work, won't it backfire my startup?
Oly Lotfi
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.
Alexa Vovchenko
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.
Alexa Vovchenko
@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
Ping @tdeneulin you must have an opinion on the question!
Vikram Sahu ꩜
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. 😛
Abhishek Singh
I would lean towards faster shipping, but in certain cases high quality code/perfect product might be more appropriate (Cars, Medicines, Vaccines, Elitist products etc etc)
Oleksii Masny
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.
Andrew Orobator
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
Sam Liebeskind
@aorobator 100% - have to balance building out new features with cleaning up existing, both polish on features and fixing bugs too
Johan Hernández
I'll never forget how the CTO of Segment and PlanGrid referred to their early code https://youtu.be/tSW-GePDwn4?t=1360
Ankit Dhawan
Just get the product out there! As long as it does what its suppose to - quality of code does not matter.
Ankit Dhawan
@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.
Himanshu Sharma
I've been obsessed with launching a perfect product. This meant tweaking the app time and again. But I feel that launching a product with just the right amount of performance would have been better for me. No user will care if the app is 0.5 sec faster or the query is optimized correctly or not. Nevertheless, it is still hard to control the urge to wait just a few days more before launching.
Welly Mulia
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.
Hugo P.
@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.
Hugo P.
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?
Sam Liebeskind
@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
Jamal Moir
You don't have to write perfect code, you can write quick dirty solutions to validate as soon as possible. The caveat here is that it should be safe code.