How to Prepare for a New IT Project: A Practical 30-Day Plan

Most people spend their first month on a new project reacting — answering whatever lands, reading whatever's open, and hoping a picture forms. Some of the time it does. More often, day 30 arrives and you still can't confidently say where the money flows through the system.

This is a deliberate alternative: new IT project preparation treated as a plan rather than a reaction. It assumes you're a working professional with real tickets to deliver, not a full-time learner, so each block is designed to run alongside actual work.

Quick Answer

A structured first 30 days on a new IT project moves through five layers: business context and environment setup (days 1–5), repository and data model (6–10), application architecture and APIs (11–15), development workflow and testing (16–20), CI/CD and deployment (21–25), then documentation and independent contribution (26–30). The aim is a working mental model of how a change travels from ticket to production, not complete knowledge of the codebase.

Days 1–5: Business Context and a Working Environment

Two goals: understand what the system is for, and be able to run it.

Business context. Before the code, learn the business. Who are the users? What do they pay for? What is the most important transaction in the system — the one that, if broken, generates phone calls? Which parts are regulated or audited?

Ask your lead directly: "If I could only understand one flow in this system properly, which one should it be?" The answer tells you where the value is.

Environment setup. Get it running locally, or in whatever development environment the team uses. Expect this to be frustrating and keep a log of every problem and fix — this log is the most valuable document you'll produce all month, because nobody else remembers what breaks for newcomers.

Checklist for the week:

• [ ] I can describe what the product does in two sentences
• [ ] I know the most business-critical flow
• [ ] The application runs in my development environment
• [ ] I can run the test suite
• [ ] I know where logs appear locally
• [ ] I've met the people who own the areas I'll touch
• [ ] I've written down every setup issue and its fix

Don't: try to read the codebase this week. It will be noise without context.

Days 6–10: Repository Structure and the Data Model

Repository. Map it at the top level. Which directories matter? Where do tests live? What's generated and what's hand-written? Which parts are dead code nobody deleted?

Read the dependency manifest — requirements.txt, pom.xml, package.json, go.mod. It tells you what the application actually does: a queue library means asynchronous processing, a payment SDK means money, a feature-flag client means runtime behavior you can't see in the code.

The data model. This is where the real domain lives. Code changes often; schemas change reluctantly. Find the five or six most important tables and understand their relationships, the row counts of the big ones, and where soft deletes or status columns encode business rules.

A practical exercise: sketch the core entities and their relationships on one page from memory. Then check it against the schema. Your gaps are visible immediately.

Checklist:

• [ ] I can name the top-level modules and what each is responsible for
• [ ] I've read the dependency manifest and know what the notable libraries do
• [ ] I've sketched the core data model
• [ ] I know which tables are large
• [ ] I know how database migrations are applied in this project

Days 11–15: Application Architecture and APIs

Now trace the critical flow you identified on day two — end to end, writing down every file it passes through.

Start at the entry point (HTTP route, message consumer, scheduled job). Follow it through validation, business logic, data access, and back out through the response. Note where it calls other services, publishes events, writes to caches or touches third parties.

Then do a second trace on a different flow. The second one takes a third of the time and confirms the patterns — that's when the architecture stops being a diagram and starts being something you can reason about.

APIs. For a service that exposes an API: how is it authenticated, how are errors shaped, how is it versioned, what's the contract with consumers? For a service that consumes one: what happens when the upstream is slow, returns an error, or changes its response?

Checklist:

• [ ] I've traced two flows end to end and written them down
• [ ] I can draw the system's main components and their connections
• [ ] I know which external services are in the critical path
• [ ] I understand the authentication model
• [ ] I know where configuration comes from in each environment

Days 16–20: Development Workflow, Git and Testing

By now you should be delivering small tickets. This block is about doing it the way the team does it.

Git workflow — ask explicitly:

• Which branch do I cut from, and target?
• Rebase or merge? Squash on merge?
• Commit message convention?
• How many approvals, and from whom?
• What must pass before merge?

Testing. Learn what exists and what's trusted. Where are unit tests, integration tests, end-to-end tests? How long do they take? Which ones are flaky and therefore ignored? What's the expectation for a new pull request?

Write tests for your first real change even if coverage is poor elsewhere — it signals how you work without you having to say anything about it.

Code review. Read other people's pull requests for a week, even ones unrelated to you. It's the fastest way to learn the team's standards, preferences and unwritten rules.

Checklist:

• [ ] I've merged at least one small pull request
• [ ] I know the branching and review conventions
• [ ] I can run each tier of tests and know how long they take
• [ ] I know which tests are unreliable
• [ ] I've read at least ten of the team's recent pull requests

Days 21–25: CI/CD and Deployment

The part most people postpone until an incident forces it.

Read the pipeline configuration. What runs on a pull request? On merge to main? On release? Where do artifacts go? How long does the whole thing take?

Understand deployment. How does code reach staging and production — automatically, on approval, on a schedule? Are there staged rollouts or feature flags? What's the blast radius of a bad deploy?

Learn the rollback. Write down the exact steps. Know who's authorized and how long it takes. This is the highest-value thing in this block by a wide margin.

Observability. Where are the production logs? What dashboards exist? What alerts fire, to whom, and what's the on-call rotation? Look at a normal day's graphs so you know what healthy looks like before you have to recognize unhealthy.

Checklist:

• [ ] I've read the CI configuration and know what runs when
• [ ] I've watched a deployment happen
• [ ] I can state the rollback procedure from memory
• [ ] I know where production logs and dashboards live
• [ ] I know what the alerts are and who receives them
• [ ] I know what normal traffic looks like

Days 26–30: Documentation and Independent Contribution

Write the document you needed on day one. Your setup log, the flows you traced, the diagram you drew, the conventions you had to ask about. This is genuinely useful to the team and it is also the clearest possible demonstration that you now understand the system.

Take a ticket end to end, unaided — including tests, review, merge and deployment. That's the real graduation, not the reading.

Review your own map. What can you still not explain? Turn each gap into a specific question and schedule the conversation rather than hoping it resolves.

Checklist:

• [ ] I've written an onboarding document and shared it
• [ ] I've taken a ticket from assignment to production
• [ ] I've listed what I still don't understand
• [ ] I've scheduled conversations for the important gaps

The 30-Day Plan at a Glance

Adapting the Plan

Short contract or urgent delivery? Compress to days 1–5, 11–15 and 21–25. Business context, one trace, and the deployment path are the irreducible core.

Very large system? Scope the whole plan to one bounded area rather than the entire platform. Nobody understands the whole thing.

No support from the team? Lean harder on git history, tests and the pipeline config — they're the documentation that can't go stale, because they execute.

Key Takeaways

• Understand the business before the code; it tells you which code matters.
• Your setup log is the most useful document you'll write in month one.
• The data model outlives the code and encodes the real domain rules.
• Two end-to-end traces teach more than weeks of unfocused reading.
• Know the rollback procedure before you need it.
• Reading other people's pull requests teaches the team's unwritten standards fast.
• Graduation is shipping a ticket unaided, not finishing the reading.

Related Questions

• What should I do in my first week on a new software project?
• How long does onboarding to a new codebase usually take?
• What questions should I ask my team lead when joining a project?
• How do I onboard when there's no documentation?
• What should I learn first: the code or the infrastructure?
• How do I prove I'm making progress during onboarding?

Frequently Asked Questions

Is 30 days realistic for a large enterprise system? For the whole system, no. For a working mental model of one area and the ability to ship changes safely in it, yes — and that's the right target.

What if I'm given tickets on day two? Normal. Run the plan alongside the work; the early tickets become your tracing exercises rather than a distraction from them.

There's no documentation at all. Where do I start? Git history, the test suite and the CI configuration. All three are executable, which means they can't be out of date the way a wiki can.

How do I ask for onboarding help without seeming slow? Ask specific, scheduled questions rather than continuous ad-hoc ones, and share what you've produced — a trace, a diagram, a setup doc. Specific questions from someone with artifacts read as diligence.

Can external support speed up onboarding? It can, particularly on the first architecture trace and the first production deployment — the two points where an experienced eye saves the most time.

What if I still feel lost at day 30? Write down precisely what you can't explain. A specific list is a solvable problem; a general feeling of being lost isn't.

Conclusion

A new project is not a test of how much you can memorize in a month. It's a question of whether you can build a reliable model of how work travels from a ticket to a customer — and then operate safely inside it.

Thirty deliberate days will get you there on most projects. Thirty reactive ones usually won't.

Starting on a new project and want a faster route through the first month? We help you trace the architecture, understand the conventions and ship your first changes with confidence. Tell us about the project.

Related pages

• project understanding sessions
• help with deployment and pipelines
• documentation and design docs
• how it works