Every project I've watched go badly went badly the same way. Not because the idea was wrong or the team was weak, but because the first version was too big to finish.
Big changes hide their own problems
A two-week branch is a bet that you understood the problem on day one. You usually didn't. The feedback that would have corrected you — a review comment, a failing integration test, a user saying "that's not what I meant" — arrives after you've built on top of the mistake.
A two-day branch is a much cheaper bet. If you're wrong, you're wrong about two days.
What "smaller" actually means
It doesn't mean fewer lines. It means fewer unverified assumptions per merge:
- Ship the schema migration before the feature that uses it.
- Ship it behind a flag, off, and turn it on separately.
- Ship the boring version, then make it fast — with a benchmark proving it was slow.
Each of those turns one large uncertainty into a sequence of small, checkable ones.
The objection
"Splitting it up takes longer." Sometimes, in raw hours. But you're comparing against a fantasy where the big version works the first time. Measured against the version where you debug a two-week branch for three days, small wins nearly every time.
Make it smaller. Then make it smaller again.