Build vs. buy approval workflow software: a decision framework

Most enterprises should not custom-build every part of an approval workflow. Buy or configure the common infrastructure, including intake, routing, status, access, notifications, and reporting. Build only the decision logic, integrations, or user experience that creates a real strategic advantage or cannot meet a mandatory control any other way.

That recommendation still leaves a third option between a fixed product and custom software: configure a workflow platform, then add custom components at the edges. The right choice depends on what must stay unique, who will own each layer, and what evidence the system must produce when something goes wrong.

Source review: August 26, 2026. Treat the framework below as a decision method, not a substitute for your security, privacy, legal, procurement, architecture, and records reviews.

Start with three options, not two

“Build or buy” hides an important middle path. Approval workflows usually combine common capabilities with organization-specific rules, so evaluate three delivery models.

• Custom build: Your team owns the application code, infrastructure choices, releases, testing, monitoring, support, and future changes.
• Packaged approval software: A vendor supplies a defined application and operating model. Your team configures the permitted options and adapts its procedures to the product.
• Configured workflow platform: A vendor supplies reusable building blocks for forms, rules, ownership, views, notifications, and access. Your operations or implementation team assembles those components around your workflow.

A hybrid model combines them. For example, a workflow platform can own intake and approval state while a custom service calculates a proprietary risk score. The useful question becomes: which layer should each party own?

Draw the ownership boundary before you compare features

An approval workflow moves a decision through four layers:

1. Decision record: request facts, evidence, status, owner, decisions, timestamps, and outcome.
2. Decision rules: thresholds, required reviewers, completion policies, exceptions, and authority limits.
3. Connections: identity, finance, HR, CRM, storage, messaging, and other systems that provide or receive data.

4. Operations: queue monitoring, access reviews, changes, incident recovery, evidence retrieval, support, and improvement.

For each layer, name the business owner, technical owner, control owner, and support owner. A custom build gives you control only if those people have time, authority, and a funded maintenance plan. A purchased product reduces code ownership, but it does not transfer accountability for policy, access, data quality, or vendor oversight.

Write the boundary down as an architecture decision. “IT owns the system” is too vague. “Procurement owns routing policy, the workflow team configures approved rules, security approves identity and data connections, and engineering maintains the vendor-master integration” gives people something they can operate.

Use nine factors to choose the delivery model

Score each factor against evidence from the same representative workflow. Do not let a polished demo replace a failed control or an unstaffed operating model.

Mark mandatory factors as pass or stop. Weight the remaining factors for the specific workflow. A high total score should never hide a failed access-control, evidence, recovery, or data-residency requirement.

Build when the difference is strategic and owned

A custom build makes sense when the workflow itself creates measurable differentiation, available products cannot meet a mandatory constraint, and a named team will own the application after launch.

Strong build signals include:

• A proprietary decision engine or user experience directly affects the organization's product or service.
• The workflow must participate in a specialized, tightly coupled transaction that supported interfaces cannot handle safely.
• A regulatory, sovereignty, performance, or deployment requirement eliminates viable products after evidence-based review.
• The organization already funds a product team for discovery, architecture, delivery, security, reliability, support, and continuous change.

Do not treat “our workflow is unique” as proof. Many companies have different thresholds and approver names, but those differences still use common components. Build when the mechanism must differ, not merely the configuration.

Buy when the workflow is standard and the product fits the controls

Packaged approval software fits when the job follows a mature category pattern, the organization can adopt the product's operating model, and the supplier passes the mandatory controls.

This often applies when an existing finance, HR, procurement, or service-management system already owns the record and its approval capability meets the real requirements. Adding another system in that case can split authority and create more integration work.

Buying still requires diligence. The CISA Software Acquisition Guide gives enterprise acquirers control questions and supporting task questions for supplier review. Use the workflow's operational context to decide which controls need deeper evidence, then carry the accepted obligations into the contract and operating plan.

Configure a platform when the rules are unique but the components are common

A configured workflow platform fits the wide middle: the organization has its own fields, authority limits, routes, evidence, and exceptions, but it does not need to own code for every form, notification, queue, and status view.

This model works best when:

• Operations owns the workflow and needs to improve approved rules without joining an engineering release queue.
• IT must govern identity, access, data movement, integrations, and release boundaries.
• Several departments can reuse the same intake, decision, evidence, and reporting patterns.
• The platform exposes safe extension points for the few capabilities that require custom code.

The hybrid boundary matters. Keep the decision record and state transitions in one authority. Avoid duplicating approval status across a platform, spreadsheet, inbox, and custom database. If a custom service makes a calculation, return its result, version, and evidence reference to the same governed record.

Compare total lifecycle cost on the same baseline

A license quote and an initial development estimate do not describe comparable things. The U.S. GAO Cost Estimating and Assessment Guide calls for a defined purpose and scope, a technical baseline, a work breakdown structure, documented assumptions, data, risk and sensitivity analysis, and updates with actual costs. Use that discipline for every option.

Custom-build lifecycle cost should include discovery, product management, architecture, engineering, infrastructure, security, privacy, testing, integrations, data migration, monitoring, incident response, user support, documentation, training, rule changes, dependency upgrades, continuity, and eventual replacement.

Purchased or configured lifecycle cost should include licensing, implementation, configuration, supplier assurance, integrations, data migration, administration, training, support, contract management, change requests, add-ons required by the design, monitoring, and exit.

Estimate the same workflow volume, retention period, environments, availability need, control scope, support hours, change rate, and evaluation horizon. Record uncertainty instead of hiding it in a precise total. Update the decision with pilot evidence and actual operating costs.

A software-purchase approval shows how the decision changes

Consider a software-purchase approval that collects business need, vendor, cost, term, data access, system access, contract status, and risk. It routes routine requests to a manager, adds Finance at an amount threshold, adds security and privacy when data or access triggers apply, and preserves the final handoff to procurement.

A packaged procurement product may win if it already owns the vendor and purchase record, supports the required reviewers, and preserves the required approval evidence. A configured workflow platform may win if the company needs a cross-functional front door, organization-specific routing rules, and reusable views across several request types. A custom build may win if the decision depends on a proprietary risk engine or a tightly coupled transaction no viable product can support.

The hybrid option can keep request intake, status, ownership, notifications, and evidence in the workflow platform while a custom service supplies one specialized score. That boundary preserves differentiation without turning every common approval component into an internal software product.

Run one pilot that produces a decision record

The pilot should test the delivery model, not just the happy path. Use the same representative workflow and evidence standard for every viable option.

1. Define the baseline. Document users, fields, volumes, routes, roles, evidence, integrations, retention, support, and pass-or-stop controls.
2. Run hard cases. Include a threshold boundary, incomplete request, unavailable approver, separation-of-duties attempt, changed evidence, integration failure, and export.
3. Make a governed change. Ask the expected long-term owner to add one approved field or rule, test it, release it, and explain the evidence.
4. Operate the queue. Find pending, overdue, reassigned, reworked, and failed items without reconstructing state from messages.
5. Exercise recovery and exit. Restore a failed connection, retrieve a closed decision, and export a complete record with its field definitions and evidence references.
6. Update the estimate. Replace assumptions with measured effort, unresolved gaps, supplier commitments, and ownership decisions.

Record the trigger, expected result, actual result, evidence, owner, gap, and decision for every case. The 12-test enterprise requirements checklist provides a deeper acceptance script after the delivery model passes this first decision.

Use a one-page decision record to prevent selective memory

Keep the final choice short enough for future owners to use. Include:

• The workflow, users, business outcome, and decision date.
• The options considered and why each remained viable or failed.
• The mandatory controls and evidence links.
• The nine-factor scores, weights, assumptions, and uncertainties.
• The ownership boundary for record, rules, connections, and operations.
• The lifecycle-cost baseline and review triggers.
• The chosen option, accepted risks, conditions, and exit path.
• The pilot result and the next review date.

The GOV.UK Technology Code of Practice offers a useful cross-check: user needs, accessibility, open standards, security, privacy, reuse, integration, data, purchasing strategy, and sustainability all belong in a technology decision. A narrow feature score misses the system's full life.

Formaloo supports a configured or hybrid approval path

With Formaloo, teams can create a request Form with admin-only and Assignee fields, configure conditional routing through Advanced logic, and run actions when a form submission arrives or changes. Teams can display form submissions in Table or Kanban Data Blocks, then create focused views for different stages or owners.

Those components support a configured delivery model for structured intake, routing, decision state, ownership, notifications, and operational views. Your team should still test its actual authority rules, access boundaries, evidence requirements, integrations, and recovery cases. If a specialized service must calculate a result, define the interface and return the result to the governed request record.

Formaloo's enterprise offer also combines the platform with a forward-deployed team for process redesign, implementation, and continued improvement. If you want to map the ownership boundary and test one real approval workflow against this decision framework, Book a demo.

Sources

• Formaloo Help Center: How to build an approval workflow in Formaloo
• Formaloo Help Center: How to add advanced logic to your form
• Formaloo Help Center: What is On update logic and how it works
• Formaloo Help Center: How to add a table data block in Formaloo
• Formaloo enterprise
• GOV.UK: The Technology Code of Practice
• U.S. GAO: Cost Estimating and Assessment Guide
• CISA: Software Acquisition Guide for Government Enterprise Consumers

Sources and product guidance reviewed on August 26, 2026.