How to Order Business Automation Without Wasting Your Budget: An Owner's Checklist

Ordering business automation is easy. Ordering it so that six months later you don't end up with a half-finished system, an empty budget and a contractor who stopped replying is much harder. I see this regularly: people come to me to "finish" or "rewrite" something they have already paid for.

Here is a typical example. A company pays $4,000 upfront for a "turnkey CRM". Three months later there is a nice-looking interface, but leads from the website don't reach it, the accounting integration is "almost done", and the server access belongs to the contractor. Finishing the project takes the same amount again, and part of the work is easier to throw away. The result: double the budget and six lost months, during which the sales team kept working in spreadsheets.

Below is a checklist to help you avoid that, even if you end up working with someone other than me.

Why automation projects fail

The reasons are almost never technical:

• Buying a technology instead of a result. "We need a CRM" instead of "we lose 30% of leads because nobody calls back".
• No shared understanding of scope. The owner has one picture in mind, the contractor estimated another.
• Payment isn't tied to results. A large advance removes the contractor's incentive to hurry.
• Everything at once. Trying to automate the whole business in one go instead of launching the most important part first.

Start with money, not technology

Before looking for a contractor, answer three questions:

1. Where exactly do you lose money or time? Be specific: "a manager spends 2 hours a day copying website orders into the accounting system".
2. What does it cost per month? 2 hours × 22 working days × the employee's hourly cost. Even a rough estimate beats none.
3. What counts as success? "Orders reach the accounting system automatically; the manager only checks them."

If the loss is $200 a month, a $5,000 project takes more than two years to pay off. At $1,500 a month it's a completely different conversation. That number immediately sets a sensible budget.

How to describe the task without a technical spec

You don't need to write a specification yourself — that's the contractor's job. But a good task description saves weeks of back-and-forth. Use this template:

• Who we are: industry, headcount, departments involved.
• How it works now: the process step by step — who does what, in which tool.
• Where it hurts: what gets lost, duplicated or forgotten.
• What we already have: ERP/accounting, CRM, website, spreadsheets, messengers.
• How it should work: the "after" process, in your own words.
• First priority: the one thing to solve first.
• Budget and timeline: at least a range.

One page like this is enough for an experienced developer to ask the right questions and give a realistic estimate.

Red flags when choosing a contractor

If you spot two or more of these, be careful:

• No fixed price per stage. "We'll bill by the hour and see" with no upper limit.
• Code and access stay with the contractor. The server is in their name, the repository is private, passwords will be "handed over later".
• No demos. You're promised to see everything at the end rather than every 1–2 weeks.
• "Everything you have needs to be rewritten." Sometimes true, but more often a way to sell a big project. Ask them to explain exactly what's wrong.
• No questions about your business. They talk about technology right away but never ask how your sales or warehouse actually work.
• A large advance for the whole project. 50–100% before work starts is a reason to reread the contract.

Staged payment: what it looks like

A healthy setup splits the project into stages, each with a clear result you can check yourself:

1. Analysis and plan — process description, feature list, estimate per stage.
2. MVP — a minimal working version for the main problem.
3. Improvements — the next features by priority.
4. Launch and training — data migration, guides, support in the first weeks.

You pay for a stage, get the result, accept it, and move on. If something goes wrong, you lose one stage at most — not the whole budget.

What a good estimate contains

Estimate section	What it should include	Warning sign
Scope of work	Features per stage in plain language	"System development — $5,000" as a single line
Timeline	A date or range for every stage	Only an overall "2–3 months"
Price	An amount for each stage	Only a total, or only an hourly rate
Out of scope	Explicitly listed exclusions	No such section at all
Acceptance	How you verify a stage is done	"We'll deliver when it's ready"
Infrastructure	Where the system runs and who pays for hosting	Not mentioned
Support	Post-launch terms and monthly cost	"We'll figure it out later"

MVP first, everything else later

An MVP isn't a "cheap version" — it's the first working version that solves the main problem. For example, not "an ERP for the entire company" but "equipment tracking on sites instead of paper logbooks".

The benefits are clear: you see results within weeks, employees start using the system and tell you what to add, and the budget goes to what's really needed rather than what seemed important at the start.

Code, servers, documentation — all of it should be yours

Check before signing:

• Code repository — in your account (GitHub, GitLab) or handed over after every stage.
• Servers and domains — registered to your company; the contractor gets access, not the other way round.
• Credentials — all passwords and keys are kept by you.
• Documentation — how to deploy the system, where backups are, how integrations work.

The idea is simple: if the contractor disappears, another developer should be able to continue the work, not start from scratch.

Support after launch

Every system needs attention after launch: updates, small fixes, changes in marketplace or accounting APIs, backups. Agree upfront who handles this, how fast they respond to problems, and what it costs. A monthly support plan is usually cheaper than one-off "everything is down" emergency calls.

What it looks like in practice

A platform for a company with distributed sites and field teams. The project started with a concrete pain — paper logbooks and spreadsheets. I built the system iteratively: equipment and warehouse tracking, transfers between warehouse and sites, the repair cycle, tasks with photos from a phone, field reports. Today it's a single FastAPI backend with 8+ role-based apps — office, site, driver, technician, storekeeper. It runs on private servers behind a VPN. Read the case study.

A SaaS product for suppliers and sellers. A platform where suppliers upload catalogs and sellers export products to marketplaces and their own shops, with stock and prices syncing automatically. It shows well how architecture changes as a product grows: an earlier version ran on 8 microservices with RabbitMQ, the current one is FastAPI + PostgreSQL + Redis + MinIO with three portals — admin, supplier and seller. Read the case study.

When automation isn't worth it

To be honest, sometimes it's better not to order anything:

• The process isn't settled yet and changes every month — sort it out manually first.
• Your losses are smaller than the cost of building and supporting a system over 1–2 years.
• An off-the-shelf subscription service, or configuring what you already have, solves the problem.
• Nobody in the company will own the rollout and accept each stage.

How much it costs

Benchmarks from my projects: a single task or integration starts at $150–250, a turnkey web application or portal starts at $1,500 with staged payment, and ongoing support starts at $100 a month. I fix the exact price for each stage before work begins.

Let's discuss your project

If you're planning automation and want to understand where to start and what it will realistically cost, book a free 30-minute process review. I'll ask about your business and tell you what's worth automating first — and what can wait. More about how I work: web applications and integrations.