You’ve signed. Now what? The first month sets the tone for everything after — and it’s also when you can still tell, cheaply, whether you hired well. Here’s what the first 30 days look like when a project is run properly, week by week, so you know what to expect and what to demand.

Week 1: Names, access, and a working rhythm

Kickoff is logistics done seriously: one named owner on each side, a shared channel where questions live (not scattered emails), access granted to the systems and data the work needs, and the release calendar on paper — dates you can hold everyone to. Boring, and it prevents half of all project drama.

Weeks 1–3: Discovery in the rooms where work happens

Workshops with the people who do the job, artifacts collected, the requirement document and wireframes taking shape and coming back to you for correction. Your effort peaks here — a prepared client makes these weeks sing. Expect drafts you can mark up, not silence.

Week 4: The signed blueprint and the first real slice

By the end of the month: a requirement both sides read and signed, wireframes of every screen, a ranked feature list, the confirmed price and phase plan — and development starting on the first slice, with the first working release scheduled just weeks out. From here, the rhythm is set: build, review, adjust, repeat.

The early-warning signs, while leaving is cheap

Thirty days in, worry if: nobody has interviewed the people who’ll use the system; questions get answered with reassurance instead of documents; there’s no date on which you’ll touch working software; or scope conversations feel slippery already. These rarely improve at month six. The inverse — named owners, written artifacts, a visible calendar, honest “here’s what we don’t know yet” — is what hiring well looks like up close.

What we ask of you in return

The first month is a partnership audition for both sides: we need your people in the workshops, your honest corrections on the drafts, and an hour of attention when a release lands. Give a good vendor that, and the next eleven months are mostly the calm repetition of month one — which is exactly the point.

Most software budgets are one number: the build quote. Then reality invoices you for everything around it, and the project that was “on budget” somehow isn’t. Here’s the worksheet I actually use — five lines instead of one — so the number you approve is the number you spend.

Line 1: Discovery — small, fixed, first

A fixed-price discovery engagement produces the requirement, wireframes, and the real build quote. Budget it separately and treat it as de-risking money: whatever you decide afterward, the blueprint is yours, and it’s the reason lines 2–5 are facts instead of hopes.

Line 2: The build — phased, not swallowed whole

Discovery ranks features by business value, which lets you budget phase one around the features that carry the return and park the rest. A phased budget also matches spending to evidence: each release shows working software before the next check clears. Cash flow prefers this; so does risk.

Line 3: Contingency — 10–15%, written down

Something true will be discovered mid-build — a workflow nobody mentioned, an edge case that matters. A written contingency turns that moment from a crisis into a line item. If discovery was thorough, you often don’t spend it; if you didn’t budget it, you spend it anyway, plus stress.

Line 4: The year-two line

Hosting, updates, watching, and small fixes: plan 15–20% of build cost per year. I’ve written a whole maintenance budget guide; the summary is that software you don’t maintain doesn’t get cheaper, it gets brittle. Put the number in the approval memo so nobody is surprised by year two.

Line 5: The people cost on your side

The budget line everyone forgets isn’t money — it’s hours. Someone on your team reviews releases, answers questions, tests with real data, and champions the rollout. Roughly an hour or two per release, plus training time at launch. Budgeting it makes it happen; projects where the client has no time are the ones that drift.

The payoff of budgeting this way

A five-line budget makes vendors comparable (ask each one for all five), makes the ROI conversation honest (returns get measured against the whole cost), and — my favorite part — makes the project boring financially. Boring budgets are the ones that finish.

You don’t need to become a security expert to run a safe website — but you do need to know which five questions to ask, because most small-business breaches aren’t clever attacks. They’re bots walking through doors nobody remembered to close. Here’s the owner’s checklist, in plain language.

1. Updates are the whole ballgame

The overwhelming majority of website compromises exploit a known hole in an outdated plugin, theme, or platform — a hole that was patched months before, by an update nobody applied. Someone must own the monthly ritual: update, then click through the site. Unmaintained plugins are worse than outdated ones; if it hasn’t seen an update in a year, replace it. (This ongoing care is precisely the “keeping the lights on” bucket from our maintenance budget guide.)

2. Logins: unique passwords, second factor, fewer admins

Bots try stolen password lists against your login page around the clock. A password manager, two-factor authentication for every admin account, and a hard look at who actually needs admin rights closes that door. Departed employees and old vendor accounts should lose access the day the relationship ends.

3. Backups you’ve actually restored

A backup you’ve never test-restored is a hope, not a plan. You want automatic daily backups, stored somewhere other than the website’s own server, and one rehearsed restore so you know the recovery takes an hour — not a panicked weekend. Ask your host or your developer to show you, not tell you.

4. HTTPS everywhere, forms included

The padlock isn’t decoration — it encrypts what visitors type into your forms. Every page should force HTTPS, and anything a form collects should arrive by an authenticated route (and only collect what you actually need — the safest data is the data you never stored).

5. Someone is watching

Uptime monitoring, login-attempt limits, and a monthly glance at users and file changes turn “we were hacked for six weeks” into “we caught it Tuesday.” None of this requires enterprise budgets — it requires an owner: a person (or your development partner) whose job description includes these five items.

Most requirement documents die unread. Forty pages of “the system shall,” a glossary nobody consults, and by page six every reviewer is skimming — which defeats the entire point, because a requirement only protects you if both sides actually absorbed it. After years of writing these for real projects, here’s what the readable kind looks like.

It’s organized by what people do, not what the system has

Chapters like “Receiving a shipment,” “Quoting a customer,” “Closing the month” — not “Module 4: Data Layer.” When the document mirrors the workday, the person who does that job can read their chapter in ten minutes and tell you exactly what’s wrong with it. That correction, made on paper, is the cheapest fix your project will ever get.

Every requirement answers three questions

Who does this, what do they accomplish, and how do we know it worked. “The warehouse lead scans a pallet and the system assigns it a bin; the pallet appears in bin inventory immediately” — testable, unambiguous, and readable by anyone. If a sentence can’t be turned into a test, it isn’t a requirement yet; it’s a wish. This is exactly what our QA team builds test cases from, which is why testing starts before the code does.

The pictures carry half the weight

Wireframes of every screen sit next to the words. People who would never catch a missing field in prose will spot it instantly in a picture of “their” screen. The rule we hold ourselves to: if a screen exists in the plan, it exists as a drawing both sides signed.

It says what’s out, not just what’s in

The most valuable page is often the one titled “Not in this phase.” Scope disputes don’t come from what was written down; they come from what each side silently assumed. Writing the exclusions — with a parking lot for phase two — turns future arguments into calm roadmap conversations.

Why this is worth insisting on

This document is what discovery produces, what the price is built on, what each release is tested against, and what keeps everyone honest for the life of the project. Whoever builds your software, insist on one you can actually read — and read it. The hour it takes is the best-leveraged hour in the whole budget.

Marketing reports love big numbers: impressions, followers, sessions, reach. They go up and to the right, everyone nods, and nobody can say what they bought. If you run a business, you need exactly four numbers — and the discipline to ignore most of the rest.

1. Leads: how many people raised a hand

Form submissions, calls, chat conversations, booked consultations — actions by a real person who wants to talk. This is the first number that means anything, and it’s why your website’s forms and phone number need tracking before your marketing does. Traffic that never becomes a lead is scenery.

2. Source: where each lead came from

Google search, a referral, a LinkedIn post, the article they read first — without the source, you can’t repeat what worked or cut what didn’t. This is what tools like Google Analytics (wired through Tag Manager) are actually for: not admiring traffic, but attributing leads. Ask “which channel produced the customers, not the clicks?”

3. Cost per lead, by channel

Divide what you spend on a channel — ads, content, tools, time — by the leads it produced. Suddenly the comparison is honest: the “cheap” channel producing nothing is expensive; the “pricey” one filling your calendar is a bargain. This single division settles most marketing arguments.

4. Close rate: which leads become customers

The final honesty check. A channel can produce plenty of leads that never buy — and a quiet channel can produce three leads a month that all close. Track leads through to won/lost, even in a simple spreadsheet, and the picture often flips.

The monthly habit

Once a month, one page: the four numbers by channel, this month vs last. Double down where cost per lead is low and close rate is high; fix or cut the rest. It takes twenty minutes and beats any dashboard — because it ends in a decision, not a scroll. If your current setup can’t produce that page, that’s the first thing to fix; it’s exactly the plumbing we set up in our marketing engagements.