Buy off-the-shelf SaaS when the workflow is common and the product meets the important needs. Build a focused internal tool when the process is distinct, valuable, and repeatedly bent around the product. Those are not the only choices.
Most teams have four:
| Path | Choose it when | Main cost to watch |
|---|---|---|
| Keep the current tool | The problem is occasional, low-risk, or caused by poor setup | Continued workarounds |
| Configure or buy SaaS | The workflow is common and vendor-supported | Seats, add-ons, administration, and fit limits |
| Add a tailored workflow app | A bounded process contains distinct rules, roles, or exceptions | Ownership, integration, and ongoing change |
| Commission traditional development | Architecture, scale, regulation, or integration complexity demands specialists | Delivery, maintenance, and internal capability |
The decision should begin with user needs, not software categories. The UK Government’s Technology Code of Practice makes the same point, then asks teams to consider reuse, integration, security, privacy, purchasing, data, and the full lifecycle. US Digital.gov guidance says user research can de-risk build-versus-buy decisions and warns that long-term maintenance belongs in the plan either way. Technology Code of Practice, Digital.gov acquisition guidance.
Score the operating fit before the feature count
For one workflow, score each question from 0 to 2:
| Dimension | 0 | 1 | 2 |
|---|---|---|---|
| Distinctiveness | Standard process | Some local variation | The process is a material business advantage |
| Exceptions | Rare and informal | Several known branches | Exceptions shape daily work |
| Access | Shared access is sufficient | Some role separation | Record/action access must differ by person or relationship |
| Evidence | History is useful | Decisions need reasons | Evidence and named approval are required before progress |
| Integration | Stand-alone is acceptable | One simple hand-off | Several critical systems must remain consistent |
| Change | Stable | Quarterly changes | Rules change often |
| Ownership | No named owner | Part-time owner | Named operational and technical owners |
This is a discussion aid, not a validated benchmark. High distinctiveness, exception, access, and evidence scores strengthen the custom case. High integration with weak ownership argues against a quick build.
Compare lifecycle costs, not subscription price with build price
NIST defines the software lifecycle broadly: initiation or acquisition, implementation, operation, maintenance, and eventual disposal. The same frame belongs in a commercial decision. NIST SDLC glossary.
Inventory these costs for every path:
- licences, seats, usage, and add-ons;
- configuration and implementation;
- migration and data cleanup;
- integrations and reconciliation;
- staff workarounds and duplicate entry;
- training and adoption;
- administration and access reviews;
- testing and releases;
- support and incident recovery;
- export, replacement, and exit.
Do not fill the gaps with industry averages. Use quotes, current vendor prices, staff time observed in the workflow, and a clearly stated planning period.
Demand the same evidence from every option
A fair comparison uses the same workflow cases and evidence standard. Ask a SaaS vendor, a traditional developer, and a tailored-app platform to demonstrate:
- the ordinary case from intake to completion;
- one common exception and its recovery path;
- an allowed and forbidden action for each role;
- the data hand-off to and from existing systems;
- how a change is tested away from live work;
- who approves a release and what can be restored;
- how data and records can be retrieved at exit;
- who owns support after the first launch.
Mark unanswered points “not verified.” Do not award a capability because it appears on a feature page if the exact requirement depends on plan, configuration, or an integration you have not tested.
This evidence pack also prevents a familiar mismatch: buying because the demo was polished, then building spreadsheets around the parts the demo did not exercise.
A purchase-approval example
Suppose a 20-person organisation needs staff to request purchases and managers to approve them. A standard SaaS or an existing Microsoft 365 workflow may be the sensible answer if every request follows the same form, route, and decision.
The balance changes if supplier evidence differs by category, Finance fields must remain restricted, approval routes depend on the client or cost centre, rejected requests need a controlled resubmission, and exceptions are frequent. A tailored layer can express that operating policy more clearly.
It still needs an owner. Someone must decide the rules, test permissions, resolve data mismatches, review releases, and support users.
KasiLabs occupies the governed middle path
KasiLabs is for teams that know the work but cannot turn it into a technical brief. Describe the job, the people, the information, the safeguards, and a good result. KasiLabs produces a readable plan and a private working version. The team chooses access and spending limits, tests normal and awkward cases, and approves the exact version that goes live.
That is different from buying a fixed product and different from asking an operations team to become visual programmers. It also avoids pretending that a generated prototype is ready because its happy path works.
GOV.UK deployment guidance recommends small, auditable releases, smoke tests, and a release cycle the team can support. KasiLabs’ private-review and controlled-release path puts that discipline into the buying decision: prove the hardest part before replacing the current system. GOV.UK deployment guidance.
Run a reversible test
Choose the hardest, smallest part of the workflow. Build only enough to test:
- whether users can complete it without interpretation;
- whether the correct person owns each next action;
- whether restricted information stays restricted;
- whether the common exception can be recovered;
- whether the operating owner can explain and support it.
Compare this private test with a configured SaaS trial using the same cases. Record what worked, what failed, and what each option will require to own. Do not let a polished dashboard decide the result.
Cases where you should not choose KasiLabs
Use commodity SaaS for standard payroll, accounting, email, and other mature categories when the supported product covers the need. Keep the spreadsheet for one-off analysis or a small trusted editing group. Commission specialist development where the required architecture, regulation, or integration depth is beyond current platform scope.
Do not build when the workflow is poorly understood, rarely repeated, or ownerless. Tailored software magnifies clear operating decisions; it does not supply them.
Make the decision conditional where evidence is incomplete. For example: “Proceed with a two-week internal evaluation only if the wrong-role test passes and the data export contains the required records.” A conditional decision is more useful than a weighted score that hides a stop-ship issue inside a good average.
If one valuable process sits awkwardly between generic SaaS and a large development project, test its hardest part privately in KasiLabs. Bring the real workflow and exceptions. You will see a working version before deciding what should replace anything.