Most companies have a few automated workflows that nobody thinks of as software until they break. Perhaps the business has reorganized and changes in one tool need to be reflected in others. Perhaps one piece of software is being replaced for budget reasons. Or perhaps the “glue” SaaS holding the workflow together is shutting down.
The immediate instinct is usually to find another subscription that looks close enough. Sometimes that is the right answer. But when a workflow is stable, specific to your business, and already well understood, there is another option: rebuild it around the way your processes actually work.
A workflow with a deadline attached
At Launch Supply, we recently began doing that for an inbox task-sync workflow running in Relay.app, which is winding down its service this fall.
The workflow begins when a client creates a task in their Asana instance. Our sync application creates a corresponding issue in Linear and links it back to the original Asana task. A member of our team then triages the request, after which the application files the Linear issue in the appropriate project, routes it to the right team, and updates the client’s Asana task. The client can continue working in Asana, which suits their team, while our agency manages delivery in one unified Linear instance.
Relay had been handling that workflow successfully. The forcing function was not dissatisfaction with the tool. It was the vendor shutdown.
Planning was the work
Because the workflow had not changed much recently and is very specific to how we operate, we decided to see whether we could rebuild it. During about an hour of focused time on an airplane, Claude helped us turn the existing workflow into an implementation plan.
The plan covered where the new system would run, what data needed to be tracked, what the administrative interface should expose, and how each workflow step should behave. More importantly, it identified the decisions that needed to be made before implementation could be reliable.
For example, Asana can send several webhook events while someone edits a request. A reliable replacement needs to distinguish between several events caused by one person composing a task and genuinely separate changes that should create or update work in Linear.
Resolving those design questions in advance was the crucial step. The valuable work was identifying exceptions, documenting decisions, and being explicit about what was in scope, out of scope, or still open.
What the build produced
After a short round of questions, the build could proceed while we worked on other things. The resulting Rails application includes webhook receivers, a state machine, Asana and Linear integrations, Google Workspace sign-in, an admin interface, deployment configuration, and a test suite. The marginal hosting cost should be around $8 per month.
We also plan to run the new application alongside Relay for a few weeks. That will let us compare results, find discrepancies, and build confidence before switching the old workflow off. Faster implementation makes this verification step more important, not less.
The build-versus-buy line has moved
We think the build-versus-buy equation has changed for certain kinds of problems. A focused process with stable rules and clear ownership can now be practical to build and own. Broad, rapidly evolving platforms are a different decision.
In this case, the result is not simply a replacement for a disappearing SaaS product. It is a documented, testable process that supports both our clients and our agency. The next time a vendor changes direction, we will not be starting from zero.
If your team has a business-critical workflow held together by subscriptions, spreadsheets, and manual handoffs, we can help you determine whether a targeted custom solution is actually the right fit.