Before choosing “build”, find out what is actually broken
A process can feel like a software problem for three different reasons: the team isn’t using the current tool consistently, the tools don’t share the information they should, or a necessary business rule genuinely doesn’t fit.
Those are different problems with different costs. Replacing software before distinguishing them is an expensive way to find out.
A useful question: what fails on a normal working day?
Write down the last incident that made someone say, “We need our own system.” Be specific.
Did a client see an outdated report? Was the same record entered in two places? Could someone not approve an order because the available access rules didn’t permit it? Or was the process simply missing an owner?
Then ask what the present system already supports. Changing the status convention or configuring a permission may fix the problem without another application. A paid implementation service may still be useful if nobody on the team can safely make the change.
Two projects, two different decisions
For LabLink, a clinic-facing report portal was built with Softr and Airtable. The key work was giving clinic users access to relevant report records while the operating team maintained the source data. A dedicated custom application was not required for that delivered scope.
For Bryant Products, the issue was more specific: an embedded Power BI report stopped behaving as expected when access tokens expired. The work focused on the embed and token-refresh path, not replacing the surrounding portal.
Neither example supplies a universal rule. Together they show why an agency should be able to recommend configuration or repair as readily as a new build.
Compare four choices with the same test
| Choice | Try it when | What would convince you? |
|---|---|---|
| Improve the current process | The tool fits but ownership or data quality is weak | The next real request completes reliably with the current setup |
| Configure an existing product | A native feature can cover the missing step | Staff and client roles can complete the acceptance test |
| Integrate existing tools | Each system works, but a handoff fails | Data moves correctly, including duplicates and failures |
| Build a focused application | A required interaction or rule remains unsupported | A documented gap and a credible ownership plan justify the cost |
For every option, compare a full year of licenses, implementation, maintenance, staff time, support and migration risk. Separate the cash cost from an estimated value of time saved.
Write one acceptance test before requesting quotes
Suppose a client must upload a document, a staff member approves it and the client sees the updated status.
The test might say:
- A client can upload a file and see whether it is awaiting review.
- Another client cannot access that file, even through a direct link.
- A reviewer can reject the file and request a replacement.
- If the notification fails, the submission isn’t lost and staff know what needs attention.
Ask vendors or developers to show how their proposed approach passes that test. A feature list or attractive mockup is not enough.
The decision you should leave with
If an existing product works in the tested scenario, use it. If a specific integration covers the gap, connect the tools and agree who operates the connection. If neither supports a requirement that matters, scope the smallest custom component that does.
If you want us to help evaluate that choice, send the workflow and the tool you’re using. There is no need to decide “custom” before the conversation.