There's a saying in research and writing that you don't so much finish as you find the right stopping point. That is also how you survive a feature that looks too big to ship.
The default is all-or-nothing. The branch lives for months. Estimates are vibes. You are perpetually "almost done." The useful skill is seeing the stopping points inside the monolith — slices that are small enough to estimate, merge, and even split across people.
A walking skeleton first
Before muscle, build the thinnest path that actually works end to end.
A button that hits an API that hits a database and returns "Success!" is enough. Ugly is fine. You have proven the plumbing: frontend talks to backend, service talks to the database. That is the first stopping point, and it is the one that usually hides the real risk.
Slice by user story, not by layer
Horizontal slicing feels logical and delivers nothing until the last piece lands.
Take a product search page with filters.
The old way:
- Build the whole UI (dead mock)
- Build the perfect
/api/products/searchthat handles every parameter - Write the query that can do any combination
- Spend days wiring it together
Nothing is done until everything is done. The merge is an event.
Vertical slices instead:
- Basic search. Type a keyword, see matching names. One input, one
keywordparam, oneWHERE name LIKE. Stopping point. Real user value. - One filter. Category. Checkboxes can wait. Optional
categoryId, one extraAND. Stopping point. The filter mechanism works. - Multiple categories. Checkboxes, an array of IDs,
IN (...). Stopping point. - A different kind of filter. Price range. New control, new clause, same foundation.
Each slice is a complete, testable win. You are not holding two pillars and a pile of rocks. You are shipping a thinner version of the real thing.
Hide the unfinished work
"I can't ship this, it's half-done." Feature flags exist for that. Merge behind a flag. You and QA turn it on. Users see nothing until you are ready. You get to pick stopping points without a big-bang merge.
The planning is the point
This takes more thought before the first line. It can feel slower than "just starting."
If you cannot find a thin vertical slice, that is the method working. The requirements are still foggy, or the technical path is worse than it looked. Better to learn that in planning than during a late integration.
Guessing a three-month project is fortune-telling. Estimating a two-day slice is a guess you can stand behind. Shipping every few days is also how stakeholders stop asking if anything is happening.
Don't hunt for the finish line. Find the next stopping point.