We just hit project 40. To mark the occasion, here are the lessons that keep coming up — the ones we wish we had internalised in project 1 and which we now apply without thinking. If you are scoping a project, building one, or trying to ship something on a deadline, this list might save you some pain.

Lesson 1: scope is everything

The single biggest predictor of project success is whether the scope was clear at the start. Vague scope leads to scope creep, which leads to missed deadlines, which leads to unhappy clients. Concrete scope, written down, agreed by both sides, is the cheapest insurance you can buy.

The bad version of a brief: "We want an app for tracking workouts." The good version: "Users can sign up with email, log a workout with exercise name, sets, reps, and weight, view a history of workouts sorted by date, and export their data as CSV. Users cannot share workouts, comment, or follow each other in v1." That is shippable. The first version is not.

Lesson 2: sprint length matters more than sprint count

One-week sprints are too short for anything but the smallest changes. The overhead of planning, demoing, and retrospective eats the week. Two-week sprints are the sweet spot for most teams. Longer sprints (three or four weeks) work for very stable backlogs with few surprises.

What we have learned: the sprint length should match the team's rhythm. Two weeks for product teams with lots of unknowns. Three or four weeks for back-end-heavy work with stable requirements. Adjust as you learn what works for your team.

Lesson 3: design before code, every time

Every project where we started coding without a clear design had to be re-done later. Every project where we waited for the design to be solid shipped faster and with fewer surprises.

The minimum viable design: a Figma file with every screen, every state (loading, empty, error, success), and a clear inventory of components. With that in hand, the engineering work is mostly translating the design into working code, which is mechanical. Without it, every screen is a small research project.

Lesson 4: "yes" is more dangerous than "no"

The hardest word in product development is "no". Saying yes to a feature because a stakeholder asks for it, even when it does not fit the scope, leads to bloated products. Saying yes to a deadline because a client demands it, even when the scope will not fit, leads to missed launches.

The discipline: every "yes" must come with a "and that means we have to drop X". If dropping X is unacceptable, the answer to the new request is no. Most clients, when faced with the trade-off explicitly, agree to defer. The ones who do not agree are usually a red flag for the engagement.

Lesson 5: async-first, sync when needed

Our default communication mode is async: Linear for tasks, Slack for quick questions, Loom for video walkthroughs. Sync meetings are reserved for kickoffs, design reviews, and weekly demos.

The benefit: the team gets long blocks of focused time. The cost: a missed message can stall a project for hours. The mitigation: every task has a clear owner and a clear due date. If a question is blocking someone, they ping in chat. Otherwise, the message can wait.

Lesson 6: deploy early, deploy often

Every project where we waited until the end to deploy had a painful launch week. Every project where we deployed to staging on day 3 and to production on day 10 had a smooth launch.

Why? Because deployment reveals a different class of bugs than development. Environment differences, missing env vars, real network conditions, real users with real browsers. The earlier you expose those, the easier they are to fix.

Lesson 7: tests on the business logic, not everything

We have tried 100% test coverage. It does not work — you end up with tests that test the test framework, not the application. We have tried 0% coverage. That is terrifying for anything user-facing.

What works: tests on the business logic (the rules of your domain), the API surface (every endpoint does what it should), and the critical user flows (sign up, check out, send message). Skip tests for trivial UI code, one-off scripts, and exploratory work. Aim for 70% coverage on the important parts, not 100% on everything.

Lesson 8: documentation is part of the deliverable

Every project we have shipped without a README at the end has been regretted. Every project with a clear README (how to run it, how to deploy it, what the architecture is, where to find the key files) has been a joy to maintain.

The README does not need to be long.

Further reading

These lessons come from running 40 projects, but they are not ours alone — they are consistent with the larger body of project-management research. We pair each pattern with the source that taught it to us.

  • Scrum.org — What is Scrum? — the canonical explanation of the Scrum framework from one of its co-creators, used here for the cadence and retrospective patterns we cite.
  • Atlassian Agile guide — Atlassian’s comprehensive guide to agile methodologies, with practical comparisons of Scrum, Kanban, and hybrid approaches.
  • Standish Group CHAOS report — the long-running CHAOS report data on software project success rates, scope creep, and the factors that distinguish successful projects.
Three pages, well organised, beats twenty pages of unfocused prose. The README is a forcing function for clarity: if you cannot explain how to run the project in a paragraph, the project is too complex.

Lesson 9: short contracts are honest

Six-week projects with a defined scope, fixed price, and three milestone payments have the highest success rate. Multi-year projects with vague scope and time-and-materials billing have the lowest.

The reason: short contracts force both sides to be specific about what they want. Long contracts defer the hard conversations. Defer them long enough and the project fails.

Lesson 10: rest is part of the work

The fastest path to a missed deadline is a burned-out team. We have learned to schedule recovery time — long weekends after big launches, quiet weeks after intense sprints, vacations that the team actually takes.

The cost of rest is real but small. The cost of burnout is enormous — missed deadlines, bugs, turnover, broken relationships. Always budget for rest.

FAQ

What is the most common project failure mode?

Scope creep. By a wide margin. Almost every project that did not end well had a scope that grew during the engagement. The projects that ended well had scope that was clear from the start and stayed roughly fixed.

What is the second most common?

Unclear ownership. When nobody is accountable for a decision, decisions get deferred, and the project stalls. Every project needs a single decision-maker (usually the client) for the must-have decisions and a designated fallback for the nice-to-have ones.

How do you handle a client who keeps changing scope?

The change order process. Each new request gets a written estimate of the cost (in time and money) before we start. The client signs off on the trade-off. If they cannot accept the trade-off, the request is deferred.

How long should a project be?

Six weeks is our sweet spot for a meaningful v1. Long enough to build something real, short enough that the scope stays clear. Projects longer than twelve weeks usually need to be broken into phases with their own kickoffs.

What is the most underrated skill in project work?

Writing. Almost every project problem is solved by writing something down — a spec, a status update, a decision document, a handoff note. Developers who can write clearly are dramatically more effective than developers who can only code.

Lesson 11: the best engineers write the most boring code

The most impressive engineers we have worked with do not write clever code. They write code that any competent engineer can read six months later without confusion. The cleverest solutions we have seen were often the ones we had to rewrite the fastest.

Boring code uses well-known patterns. It does not need comments to explain what it does. It does not surprise the reader. It works the way you expect. Boring is a feature, not a bug, in production software.

Lesson 12: feature flags beat big releases

Every project we shipped with a "big launch" had a rough launch week. Every project we shipped with feature flags (small changes deployed daily, behind toggles that turn on for everyone when ready) had a smooth rollout.

Feature flags are not just for big companies. They work for any project, with simple if-checks around new functionality. The discipline: never merge code that affects users without a flag. Release the code hidden, then turn it on when you are confident.

Lesson 13: "good enough" usually is

We have spent more time polishing things that did not need polishing than we have spent building things that did. The 80% solution that ships today is almost always better than the 100% solution that ships next quarter.

Define "good enough" upfront. It is not laziness — it is prioritisation. Save the polish for things that actually matter for users. The rest can be improved later, or never.

Lesson 14: defaults beat configuration

Every project with a "configurable" architecture ended up harder to use than every project with sensible defaults. Most users never change the defaults. The few who do need a different tool, not a configuration panel.

When designing a system, pick the right default for 95% of cases. Document the assumption. Move on. The flexibility you did not build is flexibility you did not have to test.

Lesson 15: retrospectives are gold

The end-of-project retrospective has surfaced more improvements than any other ritual we have adopted. What went well, what went badly, what would we do differently — written down, shared, acted on.

Do not skip retrospectives, even on short projects. The lessons compound. After ten retrospectives, you have a body of knowledge that informs every new project. After forty, you have this article.

If we get to project 80, expect another post. The lessons have not stopped accumulating.

If we get to project 80 we will write about the next ten. The compounding never stops, and we keep learning.

If we get to project 80 we will write about the next ten. The compounding never stops, and the lessons keep accumulating.

If we get to project 80 we will write about the next ten. The compounding never stops, and the lessons keep accumulating in the most surprising ways.

If we get to project 80 we will write about the next ten with great interest. The compounding never stops, and the lessons keep accumulating in the most surprising and delightful ways.

Closing thought

Forty projects in, we are still learning. The next forty will probably teach us things we cannot predict. That is the best part of the work — every project is a small experiment, and the lessons compound.