Blog · Process
Most automation projects either drag for 90 days or get rushed into a 5-day Frankenstein. Here's what a deliberate 30-day shape actually looks like — the deliverables, the milestones, and the moments where projects go wrong if you skip a step.
A well-scoped SMB automation project should fit inside 30 calendar days for a single workflow ($3K–$7K), 35–45 days for 2–3 connected workflows ($7K–$16K), and 50–80 days for an operational system ($14K–$30K). The shape is always the same: ~25% discovery, ~50% build, ~15% testing + UAT, ~10% cutover + 30-day support. Agencies that promise <2 weeks for anything beyond a single linear workflow are skipping discovery, tests, or both — and you'll pay the difference in week 4 when edge cases surface. Below is the week-by-week breakdown for the canonical single-workflow project, with notes on how it stretches for larger scopes.
Thirty days is the Goldilocks zone for SMB automation projects. Shorter projects skip steps that matter. Longer projects accumulate scope creep and the original problem shifts before you ship.
The math: a single workflow project usually involves ~80 hours of focused work spread across discovery, design, build, testing, and cutover. Compressing that into 5 days means working 16-hour days OR skipping the deliverables that don't have a visible output (discovery, tests, documentation). Stretching it to 90 days means the workflow you were automating no longer exists in the same form when you finish.
Thirty days also matches how people pay attention. Four weeks is short enough that the same client champion is engaged from kickoff to launch. Beyond that, you start losing stakeholders to other priorities, and the project drifts. We've watched 90-day projects die in week 7 not because the build failed, but because nobody on the client side remembered what they wanted by then.
The first week is where most "automation failures" actually happen — months before anyone notices, because nobody recognizes the failure mode. The agency skipped discovery, started building from a one-paragraph brief, and now they're 80% done with a system that handles 60% of the real workflow.
About 6 hours total, mostly in 2-3 calls. We do most of the work async between calls so the client team isn't living in our meetings. The 6 hours are:
⚠ Anti-pattern: if an agency says "we don't need discovery, just give us the requirements", they're either assuming the workflow is much simpler than reality or they're optimizing for billable hours later (because every missed edge case becomes a change order). Discovery is 20-25% of project cost and it's the part that compounds the most.
With week 1 signed off, week 2 is when the build starts. The goal isn't a finished workflow — it's a runnable skeleton that the happy path passes through end to end.
About 3 hours. A mid-week 30-min check-in + an end-of-week 60-min demo of the happy path + ~90 min of async review and feedback.
What we look for at the week 2 demo: does the happy path match the workflow map from week 1? If yes, week 3 is "fill in the edges". If no, we caught a misunderstanding early — much cheaper to fix in week 2 than week 4.
Week 3 is where the actual quality of the build is determined. Anyone can ship a happy path. The agencies you remember after the project ends are the ones that handled week 3 with the same rigor as week 2.
About 3 hours, similar to week 2. We may need a 30-min ad-hoc call to confirm a specific edge case decision ("if the lead doesn't have a phone number, do we route differently or just skip the call step?"). The end-of-week demo shows the full workflow handling realistic scenarios.
Week 4 is when the workflow goes live, but "going live" is not a single moment — it's a deliberate sequence that catches the last 5% of edge cases the previous weeks couldn't surface.
About 6 hours plus team training time. UAT specifically requires real attention — this is where you catch things week 3 couldn't anticipate ("we didn't realize Maria does this part on Friday afternoons").
The shape is constant; the scale changes. For projects beyond a single workflow, you stretch each phase proportionally — you don't add a different phase.
| Project size | Discovery | Build | UAT + Cutover | Total calendar |
|---|---|---|---|---|
| Single workflow ($3K–$7K) | Week 1 | Weeks 2–3 | Week 4 | ~30 days |
| 2–3 connected workflows ($7K–$16K) | ~10 days | ~20 days | ~10 days | ~35–45 days |
| Operational system ($14K–$30K) | ~14 days | ~30 days | ~14 days | ~50–60 days |
| Custom platform ($25K–$60K) | ~21 days | ~50 days | ~21 days | ~80–100 days |
What changes proportionally as the project scales: discovery gets longer because more workflows mean more edge cases. Build gets longer because there's more surface area. UAT gets longer because there are more interfaces to validate. What doesn't change: the ratio. You'll always spend ~20-25% of project time in discovery and ~15% in UAT/cutover — anyone who slashes those is hiding the cost in a later month.
None of these are about the agency being malicious. They're about misaligned incentives — agencies that compete on price get there by cutting the invisible work. The invisible work is what makes the system survive past month 3.
✏️ Note: illustrative compositions, not specific clients.
Three things, none of them technical:
For the rest of the operational math (what each tier costs, what should be in the quote, how to write the brief that gets a precise number), see what an automation project actually costs in 2026.
For a single linear workflow with 1-2 integrations, no edge cases, and clean source data — yes, 10-15 days is realistic. For anything with multi-step branching, exceptions, approvals, or messy data, 30 days is the floor for a project that survives past month 3. Compressed timelines work when the scope genuinely fits; they don't work as a marketing claim against a project that needs full discovery.
Any bug found in normal operation during the first 30 calendar days after cutover gets fixed at no extra charge. Feature requests are separate scope. Typically a single-workflow project surfaces 3-6 bugs in the support period; an operational system surfaces 10-15. Most are minor — edge cases the discovery didn't reveal — and get patched in hours. The support period is also when we do tuning passes (e.g., adjust a rule based on real-world frequency you couldn't have predicted).
About 18-22 hours total across the four weeks for a single workflow: ~6h in week 1, ~3h in weeks 2-3, ~6h in week 4 plus team training. The biggest predictor of timeline slip is response time — questions that wait 3 days for answers turn a 30-day project into a 45-day project. Designate one champion who can answer in 24 hours and you're set.
We pause and have an honest conversation. Three options usually surface: (a) descope to fit the original timeline, (b) extend timeline and budget proportionally, (c) cancel with a partial refund based on work completed and lessons learned (still useful — discovery artifacts are yours). The worst option is to keep pushing through a wrong scope hoping it'll work. We've never seen that recover; we've seen it produce systems that get abandoned within 90 days.
Because the workflow works on day 30. The question is whether it still works on day 240 after you've changed something — added a new lead source, modified the CRM field structure, updated the integration credentials. Without tests, every change is a 'cross your fingers' moment. With tests, the workflow tells you immediately when something breaks. Tests are 5-10% of build cost and prevent the silent failures that destroy trust in automation systems.
Sometimes yes, often no. If your team has produced workflow maps and edge case catalogs before, internal discovery works fine and we'll review your artifacts in a 4-hour session instead of a full week. If this is your first systematic automation project, doing discovery jointly is usually worth the cost — it surfaces edges that an internal team that's lived with the workflow forever doesn't notice anymore. Either way, we don't skip the artifacts; we just discuss who produces them.
Blog
Send us the workflow — what triggers it, what it does, who owns it — and we'll come back with a 30-day plan that fits, with discovery, tests, documentation, and post-launch support all itemized. No surprises in week 4.
Tell us the problem →
