Technical debt
When you work on a product, your goal is to ship the product or new features ASAP to a) validate it with users, b) make money faster to stay alive longer.
It is advised to ship faster since there is no certainty that the product will have traction. You may be sure that users should definitely fall in love with your product, but it is just your opinion :)
To meet ship faster goal you have to reduce time spent on optimizing code. Remember the perfection is not startupper's friend. When you put aside something while building the product, you are thereby accumulating technical debt.
Examples of such debt.
You do not write autotests, which means that the speed of releasing new features will be lower since you have to spend time on manual testing. You may even worse scenario when the new code introduces regression into the existing code.
You do not document. This for sure will make things difficult for new developers when they decide to introduce changes to the code.
These are the examples of technical debt, that will prevent you from shipping faster and ultimately you will face a dilemma either to spend huge resources to rewrite the product or lose to competitors and go out of business.
Let consider the Evernote example, at some point in time, they had 5 applications for 5 different platforms. There is one product - a note-taking app. To ship a new feature, they had to develop and test five times on five platforms!
If there were no competitors, they would have lived with this technical debt for a long time, but competitors (Notion, Roam Research to name a few) are quietly eating their market share. Evernote decided to rewrite the app, bring it all down to one codebase. It took them 18 (!) months to do it. During 18 months they had to pay the developers, testers, for parallel infrastructure. Since the developers were busy rewriting the code, during this time users did not see the new features.
This is the price Evernote paid to pay off its technical debt. We always have to re-pay the technical debt someday. And the price can be very high. https://www.protocol.com/evernote-reboot-ian-small
Don’t even tell me abou technical debt. I work for a fintech that evolved from lending to a portfolio of financial services, but the technology being used was a ‘built up’ P2P platform. It took us allay 2 years to get rid of it and hundreds of thousand dollars…
How did they even survive this?
I feel like you need to keep releasing new features to 1. keep competitors at bay and 2. keep your users happy, regardless of how much value your product already provides as-is.
There's always an endless avaricious demand/expectation for more, otherwise growth slows, churn increases, and you lose market share.
Very interesting topic.
Disclaimer: my vision is biased, since I have several years experience as a software developer of cloud platforms.
To me, being quick does not ABSOLUTELY mean you have to ditch some more-or-less-good practices, because when you evaluate pro and cons you see that they slow you down (a bit) in the beginning, but they can make your momentum way longer, giving the chance to react pretty quickly to incoming feedback from market/customers.
A bit of CI/CD (which clearly includes your mention of "autotests", I suppose), a not really entry level cloud setup, a minimum integration of observability tools in the application give you more grip of how things are going under the hood; and such information can be super valuable even if you are just starting.
Also, another important aspect of technical debt is that very often "makers" tell "just try to grow, then you'll fix what's to be fixed". True, but this is not just about dropping money on the table. Creating a team has aspects that are way more complex then just paying salaries and getting more chairs in the office: a team is about processes, relations, vision, skills. Out there there's plenty of big tech companies that "blitzscaled" but then struggled to keep everything on track, sometimes losing important pieces of the teams because of frustration, lack of motivation, burnout.
With all this given, I know that the vision and attitude that I am talking about can be applied only with pretty deep technical skills in place, and this is not something that is always possible. So I clearly understand the point of stacking a bit of debt. What I think is that people very often underestimates its impact.
Hey Nurlan,
Unpopular opinion: I would not have a problem at all with becoming the next Evernote. Better than one out of million nobodies 🤷♂️😅
But to elaborate a bit deeper on your question: Accumulating technical dept VS a slow development/launch pace is always a thin line. But in my experience, I would always strive for more pace to (1.) better validate product-solution/-market fits (2.) be more agile and potentially pivot the idea. But this is not black and white but more gray-ish, as this doesn't mean you have to build a "huge heap of garbage" nor a "100%-tested masterpiece" but something in between.
Always a good read is Paul Grahams "Do things that don't scale": http://paulgraham.com/ds.html
👋
I'd add that for the majority of companies, tech isn't going to be the relevant deciding factor for growth. And that that holds even more true for indie hacker projects.
Even more unpopular opinion: the tech you're using and the quality of the codebase is almost irrelevant.
Most of us on here are engineers, and I think emphasis on tech comes more from that identity than anything else
I might be wrong, but I think non-tech people have an advantage over tech people. Let me explain. When some cool (in my opinion) idea comes to my mind, I immediately start coding. Instead, I should have validated the idea first.
Think generally you need a bit of both. In my mind a team of marketer/builder is ideal. If you have a marketing background and can't code out the project yourself, that's also a hurdle.
But agree, do get the sense that a lot of people with marketing backgrounds do better online than people with tech backgrounds
You can still sell products at scale on Gumroad :)
Startups are not an exact science. You can't predict if it is going to be a wild success or a complete failure. With some previous project, I had a "gray-ish" situation, I saw interests, there were signups, questions but I could not make that "leap of faith" to continue the project. So, yes, I agree with you, It is always something in between.
After 20 years in IT and 15 years as a software developer I am at a point where I would flat out decline doing the work if I was asked to just hack it without proper planning, tests, etc.
There is just not enough mental capacity left in me to handle the stress of maintaining a poorly built codebase in production.
I think it's a balancing act. At one extreme is writing horrible code fast, users love it and it grows fast. Then you go through hell trying to service the growing customer-base while rewriting the code.
At the other extreme, you'd spend ages writing the cleanest best code ever, for software that you discover nobody wants. You end up throwing away lots of hard work as you scramble to pivot to something people actually want.
Both extremes suck.