The Resilient Entrepreneur, Edition #132
Hi there
I hope you had a great week!
Here are the topics in today's edition:
- How Did We Do Business Before Business Software?
- How to Connect Your SaaS Product to the World
Please reach out with comments, questions, or suggestions for articles!
Talk soon,
Tom
TACTICS FOR RESILIENT ENTREPRENEURS
How Did We Do Business Before Business Software?
Recently, I spent a whole day working with different business software. My emotions went from “I can’t live without this” to “Who built this?”
Recently, I spent almost an entire day updating information in various business software tools. I completed these tasks on my laptop in my home office, feet up and coffee mug right next to me. Nothing special for an entrepreneur.
Nevertheless, I asked myself how work happened before business software. In that single day, my emotions towards business software fluctuated from “how did previous generations get anything done without that tool?” to “which idiot decided to buy that tool.”
Let’s follow the different emotions I went through that day.
My All-Time Favorite: Microsoft Excel
The day started great: I updated my cash flow plan for Yonder, the B2B SaaS company I co-founded, and thought through a few scenarios for my business. Because my cash flow plan is fully configurable, I could see each scenario’s effects on cash flow and profitability in real time. The tool behind my cash flow plan? Microsoft Excel. The cost of building such a cash flow plan? Just my time, as Microsoft Excel has become a commodity in the business world.
I really can’t imagine how entrepreneurs budgeted and forecasted before Microsoft Excel. And I really don’t understand why people want expensive AI and SaaS tools for every little task when Excel does the trick for free.
Quite Good: Microsoft Word
Bing. An email from a customer with whom we’re working on updating our framework agreement. We’ve been working with this customer for five years, and the framework contract has grown to ten appendices in the meantime. Each appendix is a separate Microsoft Word document, and appendix no 10 is a self-declaration compliance questionnaire. Interestingly enough, that customer has sent us a compliance questionnaire just recently through a separate tool. I asked the procurement guys if we could just reference that questionnaire in the framework contract. The answer? No, please create a separate Microsoft Word document.
Microsoft Word is great because it’s easy to create documents. But it’s also easy to create a huge mess with all those Word documents, just because the tool is so easy to use.
Difficult: Project Planning Tools
Bing. Another email, this time related to my engagement as an active reserve officer in the Swiss Armed Forces.
The email instructed me to update some open tasks in the project planning tool we use to plan international exercises. I tried to do this right away, but I got an “access denied” message. That illustrates the core problem with all project planning tools: The project structure reflects the mind of the person who set it up. Over time, people are added to the project, convoluting the project structure because they bring in their own way of working. And suddenly, you have a task to do, but no access to the corresponding module in the project planning tool.
It’s 6 pm. Bing, Bing, Bing. At Yonder, we use JIRA to manage our development projects, and those projects grew over time, too. Around three years ago, I cleaned up the JIRA projects and set up an email automation, giving me a daily summary at 6 pm of all the JIRA tickets created in the last 24 hours for each of the three JIRA projects. And each day after 6 pm, I go through every single new ticket. People don’t always assign the correct epics and sprints, even after three years. Sometimes, they create beauty engineering tickets that have no priority.
If you want a project structure and order to survive over years, you have to maintain constant housekeeping. If you don’t invest that time, your project tool will become messy and useless.
Horrible: SAP Ariba
Whilst looking through those new JIRA tickets before calling it a day, I got a notification in Microsoft Teams from one of our account managers. “Hey Tom, can you help me fill in this supplier questionnaire on SAP Ariba? I couldn’t answer all the questions myself.”
I shuddered. SAP Ariba is possibly the most horrible, user-unfriendly piece of business software I have ever used. Unfortunately, many of our customers use it to manage purchase orders, invoices, and supplier documentation.
Because I hate SAP Ariba so much and it was already past 6 pm, I decided to postpone this task to the next morning.
When I forced myself to get this task done the next morning, and I finally managed to get past the horribly user-unfriendly login procedure, a pop-up informed me that the response deadline had passed and I couldn’t answer the questionnaire.
I needed a second cup of coffee to get myself back on track for the day.
Conclusion
Business software is just a tool. It’s there to support your business. And yes, all business software has its flaws and shortcomings. That’s why you shouldn’t spend too much time evaluating new tools and replacing your existing tool landscape.
And remember, even with the best tools, you can create a huge mess if you don’t invest time in keeping those tools in order.
So why not have fewer tools and invest more time in housekeeping?
STRATEGIES FOR RESILIENT ENTREPRENEURS
How to Connect Your SaaS Product to the World
Should you follow an interface strategy or an AI strategy to connect your product to the world? The likely answer is “both.”
I’m sure you came across automation tools such as Microsoft Power Automate, n8n, or Zapier.
These tools exist because people want to connect different software applications: Do one thing in an application, hand over the result to another, then trigger a follow-up action.
Many individuals and small companies use these tools to simplify their lives, for example to automate boring tasks.
That’s great. But what about larger organizations that need different software tools to talk to each other?
At Yonder, the B2B SaaS company I co-founded, we are selling to large enterprise customers in the aviation, critical infrastructure, and defense sectors. All of these sectors are highly regulated, so they would never allow their users to connect our product to Microsoft Power Automate, n8n, or Zapier workflows.
So, what do they request, and how do we respond to their requirements?
Option 1: Interfaces
The “legacy” way for B2B SaaS products to talk to other SaaS products is through interfaces. Your software engineers implement specific actions in your SaaS product based on API calls to another SaaS product. Customers enter their credentials to authenticate the interface, then can perform whichever actions are implemented in the interface.
It sounds simple, and in most cases it is: Take the API documentation of the SaaS product you want to interface with, implement the use cases your customers need, test it, ship it. All fully deterministic, since an API (should) always return the same data when it is called.
However, have you thought of data quality problems? Have you thought of what happens when the SaaS product you want to interface with suddenly changes its APIs and doesn’t inform you upfront? I’m not dramatizing here; we implemented an interface to another SaaS product that didn’t even have proper date formats. Yes, you read correctly. The other party sent ambiguous dates; sometimes formatted as dates, sometimes as text. No wonder our customers reported bugs all the time.
Option 2: MCP Servers
Enter Artificial Intelligence. The Model Context Protocol (MCP) provides a new way for different software applications to talk. Instead of implementing APIs for every service, an MCP server is a standardized bridge between your SaaS product and other products. And that bridge is AI: Any AI model can talk to any MCP server the same way. The only thing you have to do is expose tools for your SaaS product on your MCP server, and other applications can talk to your product through AI.
Does this sound easier than implementing APIs? Yes, the setup is easier. But as with any solution, there are pros and cons.
The first drawback is that AI is never deterministic, meaning that two identical queries can yield two slightly different answers. In many cases, that’s not a big drawback, but in safety-critical or regulated environments, it can be.
Furthermore, exposing tools to your SaaS product on an MCP server needs careful planning to ensure your customers use the integration only in the way you want them to. AI is more flexible in fulfilling edge case requests than a deterministic SaaS user interface.
Conclusion
In today’s world, people expect you to connect your product to other products. Therefore, there is no way around interfaces and MCP servers.
It doesn’t matter which avenue you choose first; you’ll likely have to implement both to stay competitive.
One final thought. While a classic interface just connects two tools, an MCP server lets you integrate your product into your customer’s AI workflows. And no matter how critical you might be towards AI, AI is here to stay. So integrating your tool into your customer’s AI workflows looks like a survival strategy for the years to come.
About Me
I’m a tech entrepreneur, active reserve officer, and father of three — writing about entrepreneurship, leadership, and crisis management from hard-won experience. No AI, no fluff, no promos. Just plain-text insights for people building and leading under pressure.
When I’m not solving problems, I find clarity in the mountains around Zermatt.
If this was useful, here’s how to get more:
📌 All my articles, no paywall — read everything in one place. Visit the blog.
📌 Buy me a coffee—it keeps the writing going. Thank you.
