Cresec

Build vs buy for SaaS workflows: a practical decision guide

By the Cresec team ·

Your team already pays for a CRM, email and a project tracker. Yet someone still spends every morning moving information between them, checking what changed and deciding what needs attention.

Another SaaS subscription might solve it. So might a workflow you build yourself. The useful starting point is to separate the system you rely on from the process you want to improve.

Buy the capabilities that already fit. Configure what you own. Build the specific workflow that makes your team more effective, when the benefit justifies maintaining it.

Define the job before choosing the software

Consider a hypothetical sales team. Every morning, each rep checks their assigned accounts, finds conversations that need a follow-up and prepares the next message. The CRM holds the records. Email holds the conversation. The team's rules determine which customer needs attention and what a useful follow-up looks like.

Write the requirement as an outcome: “Give each rep a reviewed list of their own accounts needing attention, with a suggested next step.” That is a manageable workflow. Rebuilding the CRM would add an entirely different set of responsibilities.

Then compare three routes:

Run the same example through each option. Include a reassigned account, missing information and a user who should not see a particular customer. A polished demo of the happy path is only part of the evaluation.

When buying is the better choice

Buying is a strong option when the process is standard, the product fits it and the vendor can take on work you do not want to own. That work includes maintaining the application, supporting users and adapting the product over time.

It is especially attractive when the feature list is only a small part of the responsibility. A billing system, for example, also needs to handle failed payments, corrections and reconciliation. Reproducing its screens would tell you little about whether you can operate it reliably.

Ask the vendor to show the difficult parts of your workflow. Check integration limits, permission behaviour, data export and the cost at your expected usage. Your company still owns configuration, access decisions and the consequences of how it uses the product.

When building is worth considering

Building becomes attractive when the gap is narrow and the value comes from rules specific to your team: how you prioritise accounts, prepare a handover, route an exception or assemble information from several systems.

A useful candidate has a clear input, a clear output and someone who can judge whether the result is right. The person doing the work should help shape it; they know the exceptions a requirements document can miss.

An AI-assisted prototype can help test the idea. Before relying on it, someone still needs to review the implementation, test failures and own changes. Building also brings dependencies: the app builder, hosting provider, model and connected APIs may each have costs and limits.

If nobody can maintain the workflow, keep it as an experiment until ownership is settled. A tool the team depends on needs an owner and a backup.

Compare the cost of a year of use

Compare options over the same period and at the same expected usage. Include the effort needed to reach a working rollout.

For illustration, suppose ten people each save twelve minutes on twenty working days. That is forty hours of potential capacity per month. It is an assumption to test, not a customer result or an automatic payroll saving. Subtract time spent checking outputs, correcting errors and maintaining the workflow.

Also ask whether those minutes can be used for something valuable. A workflow can be worth building because it improves consistency or reduces missed handovers, even when it removes no subscription.

Keep the core SaaS and build the missing steps

For the sales example, the smallest useful tool might read authorised account data, apply the team's follow-up rules and prepare a worklist with draft suggestions. The CRM remains the authoritative customer record. Reps review the suggestions before taking action in their existing tools.

This lets the team test the workflow before adding sending or record updates. Check exactly where a draft is stored: preparing text inside your tool and creating a draft in a mailbox require different permissions.

Custom software around a SaaS product still depends on that product's access rules, API availability and licensing terms. Check those constraints before treating a custom interface as a way to remove seats or reduce costs.

Decide how teammates will use it

A personal helper and a shared team tool have different access requirements. Before extending a prototype, answer these questions:

Evaluate bought products against these questions too. For a custom tool, use the IT approval checklist to make the answers concrete.

Make one small decision you can measure

Choose one repeated task, a small group of users and a named owner. Measure the current completion time and errors. Try the strongest option, then measure the same outcomes including review and correction time. Decide in advance what improvement would justify continuing, and how people will return to the existing process if it does not.

Cresec focuses on the access and governance needed to share custom tools with a team. The goal is for people to use their own access, with controlled actions and records tied to the person and tool version, while keeping the workflow on their own hosting. It does not take over ownership of your workflow or its maintenance.

If you have built a workflow your teammates want to use, request access to Cresec and tell us what it connects to. Access is currently by request.