So Amazon is retiring Honeycode, its no-code app builder. After just a few years. Ouch. These kinds of things happen occasionally, though — services come and go. As a business, you must walk that tightrope between leveraging helpful tools and avoiding disaster when one disappears.
When Facebook Pulled the Plug
Remember Parse.com? It was an awesome backend that let you launch mobile apps without all the hassle of coding a backend yourself. Developers loved it. Then, bam — Facebook bought it and shut it down a few years later.
Over half a million apps broken just like that. Many companies needed more time to migrate off. Even open-sourcing Parse Server only solved a little — who had the skills to run that thing? Huge mess.
Migrations Are No Picnic
Migrating data and workflows from a discontinued service is a nightmare. The providers make it challenging for you.
Take Integromat, which got gobbled up and rebranded as Make. They gave users tools to migrate their automation over. But bugs and broken connections still crept in.
Or take RelateIQ — a great CRM acquired by Salesforce. The data exports didn’t allow an entire data export when folks needed to switch CRMs after RelateIQ got shuttered.
The point is relying 100% on a third-party platform makes you vulnerable. When it goes down, so does your business.
The Hidden Dangers of No-Code
Something like Honeycode worries me even more than traditional software. No-code means non-technical folks or citizen developers, as they are called now, can build apps through a visual interface. No coding required.
The problem is that no-code apps rarely have documentation or the ability to export. If Honeycode gets turned off, there’s no quick path to rebuild those apps elsewhere.
For small apps, it is no big deal. However, a lot of enterprises use no-code tools for core processes, which is very likely for a tool like Honeycode by Amazon. That spooks me. One day, the platform pulls the switch, and half of your business workflows are gone.
To Build or Not To Build?
“Heck, let’s just build everything ourselves then! No more third-party risks.” I get that reaction. But it’s not realistic in most cases.
Rebuilding everything yourself takes specialized skills and a ton of time, let alone maintenance costs. You wouldn’t generate power to run your servers, too, would you? The opportunity cost of such a huge distraction could kill your actual product.
It would be best if you found a balance — leverage tools where it makes sense but limit the risk.
Fail Proof Architecture
One way to do that is to architect for failure resilience. Like how:
- You can abstract third-party tools under adapters, limiting damage if one needs to be swapped out.
- Keep critical data in your own warehouses, not just a third-party DB.
- Have a clear documentation model to rebuild a complex app or workflow if needed.
- Design migration plans upfront; don’t wait for a shutdown notice.
It also makes sense to really vet critical tools rather than just go for the trendy ones. And say no to no-code for anything super mission-critical.
Plan for Black Swan Events
In the end, product shutdowns will keep happening — however unlikely they seem at the time. The risks can be minimized, though.
Treat third-party software like any engineering system. Have contingency plans. Don’t rely on a single point of failure. And keep rafts handy when you’re out on the water.
The towels won’t save you from drowning when your boat sinks. But used right, they will make your life easier.
Originally published on Medium.com