How to choose and scope a first automation project

Owners usually arrive with a list. Scheduling is a mess, the invoicing takes a weekend, nobody knows which jobs make money, the field crew's paperwork is late, and someone read an article about AI. All five are real. Doing all five is how a first project becomes an eighteen-month program that gets cancelled in month nine.

The first project has a job that is different from its stated goal. Its stated goal is to fix a process. Its real job is to prove — to your team, not to you — that software built for how you actually work is worth the disruption. Everything about scoping follows from that.

Choosing the first workflow

Score each candidate on five dimensions. The winner is rarely the most painful process; it is usually the one that is painful enough and cleanly bounded.

The last row is the one that predicts outcomes best. Projects with a committed internal owner succeed at wildly different rates from projects without one, regardless of how good the software is. If nobody has two hours a week for this, the honest recommendation is to wait until someone does.

Size it so it ships in weeks

A first project should reach real use — actual people doing actual work in it — in weeks, not quarters. Not because fast is inherently good, but because everything you assumed during scoping is partly wrong, and the sooner that surfaces the cheaper it is.

What actually drives the cost

Owners tend to assume cost tracks features. It tracks these instead, roughly in order:

1. 1Integrations with systems you do not control. One well-documented API is routine. An old ERP with no API, or a platform whose export is a nightly CSV, is where weeks go.
2. 2The number of user roles. Each role that sees a different subset of data is a permission model, a set of screens, and a testing matrix.
3. 3Approval chains and conditional rules. "Over $5,000 goes to the owner unless it is on a contract, in which case the PM approves, except in the commercial division." Every clause here is real work.
4. 4Data migration and cleanup. Frequently the largest single line, and the one nobody budgets. Ten years of records with inconsistent customer names do not migrate themselves.
5. 5Offline and mobile requirements. Genuine offline capability is a different architecture, not a setting. Worth it when the work happens without signal, expensive when it does not.
6. 6Compliance and audit requirements. Real ones — retention, access logging, regulated data — add scope that is not visible in any screen.

What does not drive cost as much as people expect: the number of screens, the visual design, and — increasingly — the AI parts. Extraction and classification are usually a smaller piece of the work than the validation, permissions, and integration around them, which is a point made in more detail in getting clean data out of documents.

Budget the second year, not just the build

Custom software is not a purchase, it is a small ongoing commitment. Plan for hosting, an annual dependency and security update cycle, and some quantity of change as the business changes. It is much smaller than the build, and a business that budgets zero for it discovers in year two that nobody can safely touch the thing.

Also settle ownership at the start, in writing: you own the code and the data, you have access to the repository, and you can hand it to another team without a negotiation. This costs nothing to agree up front and is close to impossible to fix later.

The first project's success metric is whether your team asks for the second one.

Nine questions to ask before signing

• What would you refuse to build for us? A partner with no answer will build whatever you ask for, including the parts you should not have.
• Which part of our request is better solved by configuring what we already own? The honest answer is often "some of it".
• What are we not going to get in the first version? If the scope has no exclusions, it has no boundaries.
• Who owns the code and the data? Get it in writing, including repository access.
• What happens if we stop working with you? There should be an answer that does not involve starting over.
• How will we know it worked? A number agreed before the build, not a report designed afterwards.
• What do you need from us, in hours per week? Any project claiming to need nothing from your team is one that will be built against assumptions.
• How do you handle our data during development? Real records are involved; ask how they are protected and who has access.
• What does year two cost? Hosting, updates, and support, stated plainly.

Signs to walk away

A fixed price quoted before anyone has watched the work being done is not confidence, it is a guess with padding — and the padding gets defended by refusing changes later. A proposal that leads with technology rather than with the process is solving for the vendor's interest. And a partner who agrees with everything in the first meeting has not understood the business well enough to disagree with anything yet.

The counterpart is also true: be suspicious of your own list. If the process you want automated is genuinely standard for your trade, packaged software will beat anything custom on price and on time. The projects worth building are the ones where your business does something the market's software has no field for.