How long a build
actually takes.

The three sizes of build, and what each one takes.

Most business automation builds for small businesses fall into one of three shapes. The timelines below assume a builder who is working on your project consistently, not fitting it in around fifteen other clients.

• A small automation · two to three weeks. One task. One input source. One output destination. Examples: a voice memo that becomes a client note, an email that becomes a calendar entry, a form submission that becomes a draft reply. If this takes longer than three weeks, ask why.
• A proper system · four to eight weeks. Several automations working together, or one automation that touches multiple tools and handles exceptions. Examples: a full intake system that reads messages, creates files, drafts replies, and updates a calendar. Eight weeks is the ceiling for this kind of work. If it is heading past ten, you need a conversation.
• A complex integration · eight to twelve weeks. Multiple systems that need to talk to each other, significant custom logic, or a build that touches sensitive data with compliance requirements. Immigration case management, medical record summarisation, financial reconciliation. Twelve weeks is generous. Sixteen is a problem.

What should happen in each week.

For a small two-to-three-week build, a reasonable week-by-week looks like this:

• Week one. The builder asks questions, maps the workflow, and produces a written scope document. You review it and sign off. No code yet. If code appears in week one without a scope document, ask where the scope document is.
• Week two. A working version lands on your computer or in your browser. It does the core task. It may not handle every edge case. You test it with real data from your business and give feedback.
• Week three. Edge cases are handled, feedback is incorporated, the builder hands over documentation, and the automation is running in your normal workflow.

For larger builds, the same pattern repeats across more cycles. Each cycle should end with something working that you can test. Not a progress report. Not a demo of something half-built. A working piece.

Why builds run long — and who is responsible.

Long builds almost always have one of three causes. Two of them are the builder's problem. One is shared.

• Scope crept without a conversation. You asked for one small addition. The builder said yes. Then another. Then another. Six weeks in, the project is three times the size it was scoped for, and nobody stopped to reprice it or reset the timeline. This is the builder's fault for not managing the conversation — and partly yours for not asking "does this change the timeline?"
• The builder is working on too many projects at once. Your build is waiting in a queue. The builder is responsive on email but nothing is actually getting built. The sign is lots of communication with slow delivery. Ask directly: how many active builds do you have right now?
• You were slow to provide what was needed. The builder asked for access to your email account and it took two weeks to sort out. They asked for a sample of your client files and you forgot. Delays on your side are legitimate reasons for a timeline to shift. A good builder flags them in writing.

The conversation to have if a build is running late.

If your build is past the outer edge of a reasonable timeline, have this conversation directly. Not by email if you can avoid it — by call.

A good response sounds like:

“Two things are left: the calendar integration and the edge case handling for attachments. I will have the calendar integration done by Thursday. Attachments the week after. That is the finish line.”

A response worth worrying about sounds like:

“We're in the final stretch. There are a few things to sort out still. Should be wrapping up soon.”

The second answer has no specific deliverable and no date. Ask the question again and ask for those two things specifically. If the answer stays vague, you are not in the final stretch.

Red flags.

• No scope document before code starts.

  If a builder starts building before you have agreed in writing on exactly what is being built, there is no shared definition of "done." Every delay becomes a negotiation.

• Week two deliverable is a progress update, not a working thing.

  A progress update is a story about work. A working thing is the work. They are not the same. You should be able to test something real within the first two weeks of any build.

• Timeline shifted without a written explanation.

  If the deadline moves, you are owed a specific reason in writing and a new specific date. "A bit longer than expected" is not an explanation.

• Completion keeps being described as "close."

  Close is not a date. If a build has been "almost done" for more than two weeks, ask for a list of what is actually left. The list is either short — in which case it should be done — or it is long — in which case close was never true.