Your First 30 Days With a Dev Agency

The first 30 days with a software development agency should include a discovery phase, environment setup, a working prototype or proof of concept, and at least one meaningful demo. If you're at day 30 and still waiting on a project plan, something has gone wrong. This window reveals more about an agency's real operating model than any sales call ever will.

Most founders approach hiring a dev agency the way they approach hiring a contractor to renovate a kitchen. You hand over the keys, describe what you want, and expect progress when you check in. That mental model works poorly for software. Code is invisible until it isn't, decisions compound fast, and a quiet agency is rarely a productive one.

The problem is that most agencies are very good at the sales process and inconsistent at the transition into actual work. The gap between signing a contract and seeing your first working build is where trust either gets established or quietly erodes. Founders who don't know what to expect in those first 30 days often find out too late that they've lost six weeks and a significant budget on rework, misaligned assumptions, or simple organizational drift.

This is a walkthrough of what the first month should look like, broken into realistic phases. Not an idealized version. The actual work, the friction you should expect, and the moments that tell you whether this partnership will hold.

Week One: Alignment Before Anything Else

The first week is not for coding. Any agency that opens a repository and starts writing features before they've fully understood your product is prioritizing speed over accuracy. That's a problem that compounds.

What week one should actually contain: a structured discovery session, a review of any existing documentation, and a clear articulation of project constraints. Those constraints include budget ceiling, timeline pressure, technical debt you're carrying, and any non-negotiables in the stack.

A good agency will also run a stakeholder mapping exercise in week one. Who makes product decisions? Who approves designs? Who has final say on scope changes? Not having this documented is one of the most consistent causes of project delays. When a decision needs to be made at week eight and no one knows who owns it, you lose days. Sometimes weeks.

Expect to be asked hard questions you haven't fully answered yet. What does success look like at six months? What's the riskiest assumption baked into this product? Who is the primary user and what do they currently do instead of using your product? A team that asks these questions in week one is building the foundation for good decisions in month three.

Week Two: Environment, Access, and the Invisible Work

Week two is largely invisible but critically important. This is when the technical groundwork gets laid: repository access, CI/CD pipeline setup, staging environments, design system decisions, and documentation standards.

This work is unglamorous. There's nothing to demo. But it determines how fast and how safely the team can move for the rest of the engagement. An agency that skips or rushes this phase because a founder is impatient for visible progress is making a poor long-term trade.

You should receive, by the end of week two, a written technical specification or architecture decision record. Not a fifty-page document. Even a two-page summary of the core technical choices and why they were made gives you something to react to and creates accountability for those decisions. If you get to week three without any written record of the architectural direction, ask for it directly.

Access provisioning is also where agencies reveal their operational maturity. A team that struggles to get credentials sorted, can't onboard cleanly to your existing tools, or needs three attempts to set up a working environment is showing you something real about how they operate under normal friction. This foundational period is also a good time to assess whether you've chosen the right engagement model—understanding different engagement models for every SaaS stage can help ensure you've set up the right working relationship for your company's needs.

Week Three: The First Working Build

By week three, something should work. Not the full product. Not even a polished MVP. But a working build, however narrow in scope, that demonstrates the core technical approach and at least one primary user flow.

This is the first real test. At Cameo Innovation Labs, we call this the "skeleton demo." The bones are visible. Nothing is styled. But you can click through the primary action the user is supposed to take and it completes. That's proof that the team understands the core problem and can execute toward it.

If week three delivers only wireframes and status updates, you're behind. Wireframes should have been part of discovery. By week three, those should be in production or close to it.

This is also the right moment to have a candid conversation about what you learned from building that first version. Good agencies treat the first build as a hypothesis test. What did they discover that changes the approach? What's easier than expected? What's harder? A team that presents the first build without any reflection on what it revealed is treating development as execution, not exploration. That's a mindset that struggles when reality diverges from the plan.

Week Four: Cadence, Transparency, and the Decisions That Need to Be Made

By week four, the working rhythm of the engagement should be clear. Weekly syncs, async update channels, how bugs get logged, how scope changes get evaluated. These aren't bureaucratic niceties. They're the operating system of the relationship.

You should also be having your first real scope conversation by week four. Not because scope is changing, but because building anything always reveals decisions that weren't fully made in discovery. What happens when users want to do X that wasn't in the original brief? Who owns that call? What's the process for evaluating it against existing scope?

Agencies that avoid this conversation at week four are deferring a problem. Agencies that handle it clearly, with a defined process and without drama, are showing you how they'll handle it at month six when the stakes are higher.

One specific thing to watch: how the agency handles estimation at week four. After thirty days of working on your product, they should have meaningfully better estimates than they did at contract signing. If the week-four estimate looks identical to the proposal, either nothing was learned or nothing is being shared. Neither is good.

What Good Looks Like: A Realistic Benchmark

At the thirty-day mark, a high-functioning agency engagement should include: a completed discovery document, a defined technical architecture, a working prototype demonstrating the primary user flow, a documented scope baseline, a clear decision-making structure, and an established weekly cadence.

That's not a high bar. It's a minimum bar. A truly strong team will also have surfaced at least one insight that changes how you think about the product. That's the signal that you're working with people who are thinking, not just executing.

For reference, teams operating with clear evaluation criteria tend to maintain higher standards throughout their engagements. If you want to assess whether your agency partner meets that bar, evaluating an AI dev agency with a structured approach provides a framework that works for assessing development partners more broadly—not just AI-focused shops.

The Warning Signs Most Founders Ignore

Some friction in the first 30 days is normal. Ramp time is real. But certain patterns signal structural problems, not temporary ones.

Frequent meeting rescheduling in the first two weeks usually means the team is under-resourced or overcommitted. A single missed deadline early on can be excused. A pattern of small delays in the first month predicts larger delays throughout the project. The first thirty days are when the team is most motivated. If they're slipping now, ask why.

Vague status updates are a consistent red flag. "Making progress on the backend" is not a status. "Authentication is complete, database schema is 80% finalized, API endpoints for user creation are in review" is a status. The difference matters because specificity forces clarity, and clarity forces honesty.

Perhaps the most underrated warning sign is an agency that never pushes back. If every idea you present is met with agreement, you're not getting expertise. You're getting compliance. The best teams will tell you when a feature is premature, when an assumption seems shaky, or when a timeline is not realistic given the scope. That pushback is the product of your investment in them.

Setting Up Month Two

The best thing that can happen at the end of month one is a planning session for month two that feels grounded. Not optimistic. Not alarming. Grounded, based on what was actually learned in the first thirty days.

That session should include a scope review, a velocity calibration, and an honest conversation about risk. What's the riskiest remaining technical challenge? What's the assumption that, if wrong, would most disrupt the roadmap? What decisions need to be made in the next thirty days to keep the work moving?

Founders who have this conversation at day 30 are in a meaningfully better position than those who don't have it until day 90. The first thirty days are not just about building product. They're about building the conditions for a partnership that can sustain pressure. That's worth paying close attention to.