The First-Sprint Baseline: What We Set Up Before Writing Features

When one of our developers joins a project, clients often expect features in the first week. What they get first is less visible and more valuable: a baseline that makes every later week faster and safer.

Whether we're starting a product from scratch or joining an existing codebase, this is the checklist we work through in the first sprint.

1. One way to run the project

A new developer should go from clone to running app with one documented command. If setup needs a call with the person who built it, that's the first thing to fix. Environment variables are listed in an example file, and secrets live in a secrets manager, never in the repository.

2. Continuous integration on every change

Every pull request runs linting, type checks, and tests automatically. The pipeline doesn't need to be clever. It needs to be fast and trusted, so a red build means something and a green one means the change is safe to review.

3. Preview environments

Each change deploys to its own temporary URL. Product managers and clients review real software instead of screenshots, and feedback arrives before code merges, not after it ships.

4. Automated, boring deploys

Deploying should be a merge, not an event. If releasing requires a checklist, a specific person, or a Friday-afternoon prayer, teams release less often, and each release carries more risk.

5. Know when it breaks

• Error tracking that reports exceptions with enough context to reproduce them
• Uptime checks on the endpoints that matter
• Structured logs, with personal data kept out
• Alerts routed to someone who can act, not to an inbox nobody reads

6. Backups you've actually restored

A backup you've never restored is a hope, not a plan. We schedule a restore test early, while the stakes are low.

7. A shared definition of done

"Done" means different things to different people. We agree on it in writing with the client: reviewed, tested, deployed to production, documented where it matters, and checked by whoever asked for it. A short, shared definition prevents the slow drift where work is "basically finished" for weeks.

Joining an existing codebase

On an inherited project we don't rewrite anything in the first sprint. We read the code, run it, write down how it actually deploys, and add the missing pieces of the baseline one at a time, starting with whatever would hurt most if it failed tonight. The goal is to make the existing system safer to change, not to replace it with our preferences.

None of this shows up in a demo. All of it shows up in how quickly a team ships its tenth feature, and how calmly it fixes the eleventh when something goes wrong.