
Should a startup worry about technical debt before reaching product-market fit? - franciscomello
Should a startup spend resources refactoring code before p&#x2F;m fit is achieved? Or should it spend its resources turning out features to win prospective customers?
======
andreasklinger
Everyone will say no to this question. And it's the right answer.

But then you run into team problems with engineers feeling very exhausted
working with your codebase and you have to constantly deal w/ missing
confidence in the developed software.

In my experience "Acknowledged technical debt" is usually a good middle ground
to work with. It usually also works with die-hard engineers.

Building software is not about writing optimal code. The goal is to have
confidence in the code you wrote. Constantly wondering how something works
only to realize that it doesn't is energy draining and needs to be avoided.

Acknowledge and document technical debt. Explain (in notes) how stuff is meant
to be, how it should be, what does work. Essentially you want to reduce the
amounts of "WTFs" the next person (eg future you) has reading the code.

The most important lesson here is: technical debt can be a good thing. You buy
expensive short-term impact with future time. Very often you never need to
"cheque" that future time because that part of the product might have been
thrown away.

~~~
iconnor
I like this answer. Acknowledged debt is the most you should aim for. The last
thing you want to do is have a wall of trust where you throw requirements over
the wall and then don't care how the code gets written. The code is everyone's
responsibility. Everyone should be willing participants in the process (which
includes acknowledging the debt it took to meet deadlines).

------
tedmiston
No, because your priority is building something people like _quickly_. Not
building something _well_ that people don't necessarily care about.

That said, _tracking_ tech debt is important. Creating issues in Jira, or
whatever you're using, can be valuable over time. Maybe there's one specific
piece that gets in your way of building features every week, and tracking it
will make it more obvious or help you realize, e.g. "we could make this 10x
better with a few hours of effort vs. 12x better with a few days". Remember
that product-market fit stage is when you'll have the highest percentage of
your time to dedicate to building features -- might as well make the most of
it.

~~~
percept
Good coding practices can help here, too: decent comments, (reasonable) tests,
PR discussion, etc., can be self-documenting.

------
codegeek
No. Your highest priority is to reach the product market fit and get real
customers. You can always refactor.

~~~
seanwilson
I agree with this. Many coders spend too long worry about things customers
will never see or even use. Don't spend months making perfect backend code for
a feature that you end up removing because customers don't use it. See what
people want then iterate from there.

------
mbrock
Don't write so much code. Once you figure out what you're going to build, you
can just throw everything away and make it again more properly.

------
vonklaus
I would offer that there is a definite correct answer to this in most, if not
all, cases. It can go either way depending on what is going in your company
and market.

I would consider a few things before making your choice:

* Likelyhood of Pivot while Repurposing Codebase

Obviously, people don't just go into a startup thinking that they are going to
pivot and they aren't easy to predict because it means something unexpected is
working well. Your architecture should allow for services and components to be
broken out, e.g you will suffer massive technical debt if you want to pivot a
service that is dependent on a schema based mysql database with a very rigid
data model. All of this is set up on docker instances with crazy services and
held together with a staple gun.

If you want to carve out a small service that is working, it will be
impossible as it is inextricably tied to your bloated deathmachine. Death will
quickly catch up before your revenue does if you have to port and rewrite your
entire application and redeploy it. Make sure you can be sort of agile, in the
sense that you at least have a componetized modular structure for services
large enough to charge for.

* No One Likes Your Product

If your product is not great and no one wants it, having an immaculate and
eloquent codebase will kill you as well. Something that does a great job
performing a task no one will pay for is also negative.

my 0.02, tolerate technical debt at the micro level, but never at the macro
level. E.g you can do refactoring if you need to, your code is not extremely
dry, there are plenty of optimizations available but your code/functions work.

DO NOT TOLERATE IT AT THE MACRO LEVEL You used the wrong tool, are trapped on
the wrong database structure, your application is extremely unstable because
of a major design choice, etc.

Lot's of small errors are better than a few big ones.

------
swatthatfly
The answer can depend on some of the architectural choices you made when you
prototyped your product. If the original use-case has changed significantly,
and you find yourself fighting the codebase to get it to do what you want
today, the technical debt is something to worry about. The same thing applies
if you cannot scale to serve clients requiring a lot more volume than what you
anticipated originally. It's possible that some clients have modified the
original use-case they wanted when they signed-up with you, so your product
must evolve to keep serving them. This may require refactoring, whether p/m
fit was achieved or not.

------
karmiphuc
The startup world may be influenced a lot by Mark Zuckerberg's motto of "Move
fast; break things."

However, I don't think it's a good goal to aim for.

Like @andreasklinger and @hashkb said, you should have agreement with your
engineers about your limit.

Refactoring can never be enough, because we always try to improve, try to be
better.

You can think about the "later days" when you can come back on your codes and
fix those crap codes, but you know you won't. The bigger the debt for now, the
costlier it will be in the future.

Trust me, my startup is managing on that.

------
ryanto
It depends, technical debt lets the team build features quickly today at the
cost of slowing down future development.

Startups with a short runway probably don't have a future, so technical debt
can be viewed as something with little downside that gets you to market
faster. The tradeoff is that as your runway gets shorter debt makes it harder
to try new things.

I'd say don't worry too much about technical debt before p/m fit. However,
don't let anyone on your team use debt as an excuse for half-assing something
that could deter finding market fit.

------
shepbook
No, but it depends. One thing to remember about technical debt is the concept
of interest. Each time you have to go into a part of the code with high
technical debt, you pay interest.

There is also something to be said for building a v1 MVP to prove
product/market fit, and then build an entirely separate v2 that is refined to
what you have learned.

------
sheepmullet
Like pretty much every question asked on hn the answer is "it depends".

At what point do you consider p/m fit achieved?

How many developers are working on the software?

What makes you think features are important?

How mature is your market?

What's your value proposition? Etc etc etc.

If you are entering an established market then code-quality can be your
biggest competitive advantage.

------
hashkb
Give yourself a technical debt ceiling, and don't raise it each time you hit
it. Your engineers will stop trusting you, burn out, and/or quit. Make sure
you do more than just acknowledge the debt you are taking on, or else you
don't have technical debt, you just have bad code.

------
api
IMHO: "A little, but not too much. The more product-market fit you achieve,
the more you should worry about technical debt."

------
edoceo
Don't fall for the "Next Feature Folly"

