I had a call last week with a new client, a sharp guy building a fairly complex WooCommerce extension that syncs inventory with a third-party API. He was completely stuck. He had been coding for three months and had a long list of features, but nothing was actually finished. His project board was full of vague tasks like “Build the admin dashboard” and “Handle API authentication.” He felt like he was working nonstop and never shipping anything. He did not have a feature problem, he had a planning problem. What he needed was a real product development framework, not another to-do list.
His problem is one I see all the time. Devs think about work in horizontal layers: design first, then backend, then frontend. You map out all the design, then all the database tables, then all the API endpoints. It feels organized, but it is a trap. You end up with a pile of half-finished components that never quite add up to a usable feature. Nothing is ever done done.
I have made this mistake myself. On my first big project I tried to fix the chaos with a giant JIRA board. I broke “User Profiles” into 20 tiny tickets: one for the database schema, one for the REST endpoint, one for the avatar upload component, one for the form styling, and so on. It was a masterpiece of micromanagement. The trouble was that at any given moment we had 10 tickets “in progress” and, for weeks, no actual profile page. The team lost motivation fast.
Vertical scopes of work
The fix is to stop thinking horizontally, by role, and start thinking vertically, by feature. You define a self-contained slice of work that delivers a complete piece of functionality, from the UI down to the database. I have refined this over the years, drawing on a couple of ideas I first ran into over on carlalexander.ca. It is a mix of working backward from the end goal and packaging the work into what Ryan Singer from Basecamp calls “scopes.”
Instead of a “User Profile” project, you define a scope called “Users can edit their own profile.” That scope is not a single task, it is a checklist of everything needed to make that one sentence true. When the scope is done, the feature is integrated and works.
Example scope: basic Stripe integration
Say you are adding payments. A horizontal plan would have tasks like “Design checkout form” and “Create payments API endpoint.” A vertical scope looks different. Here is one:
- Goal: User can pay for a single product via Stripe.
- Tasks:
- Design a minimal, one-field credit card input form.
- Add a
Paybutton to the product page template. - Write the server-side endpoint that receives the form post.
- Integrate the Stripe PHP SDK to create a charge.
- Handle success: Redirect to a simple “Thank You” page.
- Handle errors: Display “Payment failed, please try again.”
Once you check off every item, that scope is 100% done. It is a real, testable piece of the final product, with no front-end work left hanging and no disconnected back-end code.
So what’s the point?
This is not really about project management theory, it is about momentum. Every completed scope is a win for the team and a concrete step toward launch. It forces you to decide what is essential for the feature to actually work and to push the “nice to have” items into a later scope. You stop drowning in endless detail and start shipping finished features, even small ones. That is real progress at last.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, drop my team a line. We have probably seen it before.