@kylefox Would be nice if Claude could take a hint now and then from devs with 20 years experience in Rails rather than getting cute. Itโs like, dude, youโre only like 3 years old.
@kylefox No, itโs saying that your validation is guarding against a condition thatโs already guarded against by the unique index, whichโฆ sort of but not really the point.
Build your MVP with the expectation that it's actually a v1 that will need to be extended and maintained for years to come.
If you're wrong, you'll cost yourself a little time, but if you're right, you'll have saved yourself potentially years of carrying costs on crappy code.
I can completely understand the idea of building a quick MVP to validate the market.
But it's worth asking yourself: what happens if this works? I've never seen a company start to get traction and then put everything on pause to rewrite the app. There's no time.
The takeaways here?
Document your assumptions.
Build in some form of monitoring early - at least in production.
And remember - technical debt isn't always about cutting corners. Sometimes it's about the system environment not turning out to be what you thought it would.
Most of the time when we think of technical debt, it's in the context of making a trade-off between "Doing It Right" and "Getting Shit Done". That's certainly one form, but there's another type that's more insidious.
Read on...
With The Time Bomb, though, you probably didn't think about any of that, so when it does show up, it comes as a complete surprise. And unless you've got good monitoring and instrumentation, tracking down the root cause becomes a nightmare.