One thing can’t be the solution to everything

If you’re looking for one system to do everything then you’re asking to be lied to

Can the system do X?

"Yes, it can do anything."

On the surface, that sounds great. Flexible. Capable. But more often than not, it’s a red flag, whether it’s coming from an external implementation partner or your own internal team.

Because when someone always says yes (whether it’s about Airtable, Retool, NetSuite, or any other platform) what they’re actually doing is skipping the hard bit: understanding what the business really needs.

We see it all the time. Teams asking if the system can do something, and getting the same enthusiastic nod: "Yep, we’ll just build an Airtable app for that." Or, "We’ll plug it into NetSuite." Or, "There’s an API for that."

Sometimes, that’s true. But often, it’s shorthand for dodging the real question: Should we do it that way? And for whom are we building this?

When yes becomes a liability

It’s easy to get excited about building. Especially with low-code tools, the barrier to entry is low, and you can spin up a working solution quickly. But that excitement often comes with a blind spot, the long-term overhead.

We’ve seen brands where well-intentioned internal teams built app after app in Airtable or Retool, only to realise months later that:

• The person who built everything is now the only one who understands it

• The stack has become a tangle of apps, automations, and fragile dependencies

• The original business problem was never really solved, just digitised

What started as a fast fix becomes a slow, creeping liability.

---

---

One size fits... no one

Just because a system can do something doesn’t mean it should. For example, a product development team working in NetSuite might tick a box on the capabilities list, but if they hate the experience, you’re introducing friction into a critical process. Worse, they’ll abandon it entirely.

Too often, teams try to shoehorn processes into systems that aren’t designed for the people using them. When that happens, adoption fails. And the business ends up back where it started, or worse, stuck with tech debt and low morale.

---

What to ask instead of "can it do this?"

You’re not just looking for technical possibility. You’re looking for:

• Real-world examples of similar setups

• Honest opinions on what works (and what doesn’t)

• Clarity on the trade-offs

• Experience from other brands who’ve tackled the same challenge

Some useful questions to ask:

• "Can you show us a live example of how this would work?"

• "What would you recommend based on what you’ve seen elsewhere?"

• "Who is this system suitable for, and who is it not suitable for?"

• "What happens if the person who builds this leaves?"

And critically: challenge your own team too. Ask your internal tech leads if the proposed approach is really the best route, or just the most familiar one. Find out how other brands are solving the same problem. Don’t be afraid to ask around.

---

The right implementation doesn’t start with a blank yes

Good partners don’t agree to everything. They push back. They ask questions. They help you protect what’s working, and challenge what’s not.

They know that implementation isn’t just about getting a system live, it’s about making sure it’s the right fit for the business, the process, and the people who have to use it every day.

So if the answer to everything is yes, it might be time to ask a different question: what do they actually understand?