How We Run Projects

We’ve run enough projects to know what causes them to go wrong. It’s rarely technical. It’s usually process: unclear ownership, feedback that arrives too late to act on, or scope that grows without anyone noticing.

Here’s how we structure projects to avoid those problems.

Two-Week Sprints

Every project runs in two-week sprints. At the start of each sprint, we agree on exactly what will be delivered by the end. At the end of each sprint, we demo working software — not slides, not wireframes, not a status update. Working software.

This creates a forcing function. If a sprint deliverable isn’t clear enough to demo, the scope isn’t clear enough to build. We resolve that at the start, not the end.

The Weekly Check-In

Every week, we send a brief written update covering:

1. What was completed in the last seven days
2. What’s planned for the next seven days
3. Any blockers or decisions needed from the client

The check-in takes us about ten minutes to write. It should take clients about five minutes to read. It keeps everyone aligned without requiring a 45-minute meeting to stay informed.

One Decision Maker

Every project needs one person on the client side with authority to make decisions. Not a committee. Not “we’ll need to check with the team.” One person who can say yes or no in a meeting.

We ask for this upfront. When we don’t have it, projects slow down by 30-50%. Decisions that should take a day take a week because they need to go through three people before anyone commits.

Scope Changes Are Fine

Scope changes happen on every project. Requirements shift, priorities change, better ideas emerge. We don’t penalise clients for this. We do make them explicit.

When scope changes, we document it in writing: what was originally agreed, what’s changing, and whether the change affects timeline or cost. Both sides sign off. Then we build the new thing.

The goal isn’t to lock scope in stone. It’s to make sure changes are intentional and understood by both sides, not things that silently happen and then cause arguments later.

What We Expect From Clients

• Availability: One person reachable within 24 hours for decisions and questions
• Feedback: Timely responses to demos — we need feedback within 48 hours to maintain momentum
• Access: Systems access (APIs, databases, tools) provisioned before the sprint that needs it, not during

That’s it. We don’t need clients to manage the project or understand the technical details. We need them available, responsive, and clear about what they want.