Workflow automation moves work and data between systems that already exist. Custom software creates a place where work happens that has no home today. The deciding question is not which approach is better, it is whether the thing you need already exists in your stack and is simply not connected. If every field you need lives in a system somebody logs into, you have an integration problem. If the work happens in a spreadsheet, an inbox, or somebody’s head, you have a modeling problem.
Why this question gets answered backwards
The vendor you ask determines the answer
An application shop looks at your process and sees an application. An automation shop sees a set of connected triggers. Both describe their own capability honestly. Neither answers the question you asked, which is what your process actually requires.
We need a system usually means we need a place for this
When somebody says they need software, the underlying need is often a durable record with a state, a history, and a screen where people can see it. That is a much smaller thing than a full application, and recognizing it early changes what gets scoped.
Automation gets asked to hold state it was never built to hold
Connector platforms move one event from one place to another well. They answer questions like which requests are open, who has had this longest, and what happened to Tuesday’s poorly. At that point you are asking a run history to behave like a database.
An application gets built for something the existing tools already do
Accounting packages, field service tools, and form platforms have features nobody turned on. An afternoon of checking is worth it, because the most expensive custom software is the kind that duplicates a module you already pay for.
The spreadsheet becomes the requirements document
A spreadsheet that has run a process for years is a real specification. It is also full of undocumented exceptions, formulas that stopped being true, and a column somebody uses for something else. Copying it into software copies its errors with its logic.
Situations mapped to the answer that fits them
These come up most often when somebody asks us to scope work. The last column matters most, because the trap is usually the option that sounded cheaper on the first call.
| What you are dealing with | The answer that usually fits | Why | The trap |
|---|---|---|---|
| Someone retypes data from one system into another | Automation | Both systems already model the data; the gap is transport | Replacing a system when the only problem was the handoff |
| A process runs on a shared spreadsheet everyone edits | A form plus a workflow, occasionally custom | The spreadsheet is an undocumented data model, and writing it down comes first either way | Automating around the spreadsheet, which makes its quirks permanent |
| The rules live in one head and that person is retiring | Custom software, after the rules are authored | There is no system to connect, so the logic must be written down before it can run anywhere | Assuming judgment becomes rules without testing it against real past cases |
| Customers want to see status without calling | Custom, unless a portal exists in a tool you own | Somebody outside your company needs an interface, and automation has no front door | Sending scheduled status emails and calling it a portal |
| Approvals happen by email and nobody finds them later | Automation, plus somewhere for the decision to land | The approval already happens; what is missing is a durable record of it | A full approval application when a routed form and a history table would do |
| Only one person can price a job correctly | Custom software | This is a calculation engine with an interface, and no connector performs judgment | Approximating it in a spreadsheet formula nobody can version or test |
| Monthly reporting is assembled by hand from three exports | Automation first | Find out whether the exports can be joined before concluding you need a reporting system | Commissioning a reporting build on data that was never made consistent |
| Field crews need to work where the signal is bad | Custom software | Offline capture and edit conflicts are application concerns, not integration concerns | Assuming a mobile form covers it; the hard part is two people editing offline |
A sequence for making the call yourself
Write down where every field lives today
Take the process end to end, list each piece of information it touches, and name the system that holds it. If every field has a home, this is integration work. If several have no home except an email thread or a notebook, that gap is what a build is for.
Ask who needs to see this who has no login
Customers, subcontractors, referral sources, and inspectors are the usual answers. An external audience means an interface, and an interface means an application of some kind. Internal-only processes can often run through automation and the screens you already have.
Test whether the logic can be written as rules
Take a dozen real past cases and write the rule that produces each outcome. If two experienced people disagree about the right answer on any of them, you have a judgment rather than a rule. That is worth knowing before commissioning something to automate it.
Count the states, not the steps
A process with three or four states routes fine through a connector. A process with a dozen states, conditional transitions, and rules about who may move an item wants a model that lives somewhere queryable. Count states first, because step count is misleading.
Decide what has to outlive the tooling
Anything you might need to reproduce years from now should not live only in a connector’s run history. Records with legal, financial, or contractual weight belong in something you control and can export. That requirement alone sometimes settles the question.
Reading on either side of this decision
- custom application development — What a build involves when the process needs its own data model and interface.
- Cognito Forms consulting for processes built on a hosted form platform — The middle path most small businesses need, where a structured form carries the record and automation carries the routing.
Is this a fit for your business?
A good fit when
- You have quotes for the same problem that differ by an order of magnitude
- A process runs on a spreadsheet one person maintains and everyone depends on
- You own several systems and suspect the problem is between them
- Somebody proposed a build and you want to test whether it is the smallest thing that works
Probably not a fit when
- You have one system and one missing feature its vendor already offers as a module
- The process is not stable yet, so documenting it is the work, not building it
- The real problem is that nobody has decided who owns a step
What to have ready
- The process written as steps, with the person responsible for each one named
- A list of systems in use, including ones only one department knows about
- Two or three real cases from the last month, including one that went wrong
Questions we get asked
Can we start with automation and build custom software later?
Yes, and it is usually the right order. Automating first shows where the volume is and forces the process to be written down. Expect some rework, because when an application later absorbs part of the model, the integration around the old arrangement gets rebuilt. That still beats guessing at requirements up front.
Is a low-code platform custom software or automation?
It sits between them, and it is worth being precise about which part you are using. Building a data model, forms, and permissions on one is custom software; you own those decisions and the maintenance follows you. Wiring that platform to your accounting system is automation. Scope them separately.
Which is cheaper to change after it is live?
Automation is cheaper to change in small ways and more fragile when the systems on either end change underneath it. Custom software costs more per change and absorbs external change better. If the process keeps moving, that argues for a build. If the process holds and the tools keep updating, connect what you have.
What if the honest answer is that we need both?
That is the common case and not a failure of analysis. Most working systems are an application owning the part of the process nothing else models, plus integrations keeping it in step with the accounting package and whatever the field uses. What matters is not blurring which piece owns which data.
Related
Tell us what the process looks like now and we will map what a system would need to do. No obligation, and you keep the map either way.