I highly agree here. Do not staff a very new startup with junior engineers and expect a good outcome.

Furthermore, you absolutely do need to cut corners _somewhere_, but a seasoned team understands that taking on such tech debt will require a reduction in velocity at some point in the near future. It is then incumbent upon engineers to ensure management understands that the team is borrowing from future velocity to deliver quicker, and it's incumbent on management to facilitate remedying that tech debt at the earliest available convenience. If management does not facilitate removing tech debt by allowing for such refactoring/structural work it is then incumbent on engineering to stop offering the shortcuts that temporarily increase velocity, because there's already too much tech debt to be had, and to take on more will reduce velocity unacceptably.

A good startup has experienced engineers and experienced managers who understand this dynamic.

I really wish we had more precise terms for tech debt.

For instance I think type/schema debt (where your domain model has changed from your original type/schema debt) is very painful and has a very high interest rate.

I think duplicate domain logic has a medium to high interest rate.

I think code organization(what methods go where) has a low to medium interest rate.

I think white spacing, duplicate non-domain logic and code style has a low interest rate.

My take is that the highest tech debt is never duplication but always abstraction. Duplication make the job tedious and error-prone, but a wrong abstraction in the start and suddenly you have an insurmontable rewrite of everything for the unexpected change or feature that comes in and wasn't envisioned in the beginning. And it'll come, until you have product market fit and are not a startup anymore.

Agree, and in theory duplication is easy to refactor and clean up, but the nasty thing about duplication is that the instances can diverge in little ways, and then the person cleaning it up may not be able to tell if the differences are meaningful and need to be preserved, or accidents of maintenance.

My current job is cleaning up both kinds of tech debt for a startup. Duplication has created several bugs, but most of them were fixable in a few hours at most, and we finished cleaning them all up within 4 months. Bad abstraction has taken hours to months to clear up and we're still not done.

The difficulty in our current culture with abstraction mostly derives from taking "don't repeat yourself" too far and using that to mean "apply any compression strategy you can find to this code" which could range from enterprise generalization and configuration to APL-style code-golfing.

A gentler, more helpful admonition would be "find the theme, reuse the theme". If you only set out to compress the code you obscure the theme of the code, but if you set out to elevate the theme as you find it, you are likely to let more code rest in a form that is duplicated but a reasonable reflection of the themes currently present.

Was going to say the same... I've been in projects where the abstractions made what should be a trivial 30-60min change, with tests, blows up to almost a week just because all of the layers that need to be worked through.

To GP: schema debt is usually from adding stuff before you need it... it's almost always pre-mature and one should have a good migration strategy in place early on in order to support destructive (or at least not-simple) restructuring over time.

Even better if those could be demonstrated by studies/concrete data instead of "I think/feel..."

Really, really agree. Especially on the last point. Having a small, experienced team is I think the least risky way to build products. Taking the right shortcuts is the big advantage here. Not only about technical debts, but also on reducing planning things to the last detail and reducing overhead on researching best practices for a non-proven stack.

Can you clarify your last sentence? Do you mean not spending too much time planning things out to too much detail?

cies is correct but I'd like to expand the point. A junior engineer (like me) might have encountered tens of systems, and work in less than ten. Senior/more experienced engineers encounter and work in much more. They know which things to implement. For example, let's implement an authentication system for a SaaS. The junior engineer will ask for specs to the brim to avoid missing anything. How to do forget password? Password requirements? Social logins? While the experienced can see the contexts, pick the suitable decision and implement it quickly. They will be more concerned whether the auth will need to support OAuth to smooth out onboarding or to put it off later because their target demographic is more familiar with email/password. These kinds of shortcuts compound to reduce anxiety, increase velocity, and to iterate faster when the product hits the market.

I think what is meant is that a senior can shoot these things more/less from the hip, hence needing less research time.

I suggest it's frequently less about knowing which corners to cut, and more about knowing hard from easy, to avoid future impedance mismatches between eng & sales/marketing (or even internal business leadership).

One of the very most frustrating things for an exec is downtime. The next worst is inaccurate time estimates for IT work. If you don't have at least some experienced architects/developers, it's normal to find yourself in the position where nobody knows what they don't know, and that's a bad look for everyone involved. It's also why a lot of bigco's have been outsourcing internal appdev to MSPs over the last 10+ years. It de-risks projects, eliminates skilled labor shortages, and ensures reasonable QoS... in theory. It doesn't always work out that way, but that's the objective.

Experienced engineers are hard to get though, unless they are founders themselves. Early-stage startups tend to rely on the cheapest engineers they can find, and only hire more experienced devs when they've accumulated a pile of technical debt and poor decisions.

That's why who your technical partner is is so important. Pick someone smart who you wouldn't be able to afford otherwise or pay for it now and later.