Don’t say yes to tech you don’t know.

This week, I signed a new client. What made it special wasn’t the revenue - it was where they came from.

They found me through the brand I’ve been steadily building on LinkedIn. It’s a small but strong reminder: consistency compounds.

You never know who’s been silently reading your posts until one day they show up in your inbox with a decision already made.

On the podcast side, I’m trying to lock in more guests. Turns out, it's harder than it looks.

But that’s what growth does - it adds layers. Each new piece of your business introduces new logistics. And that’s fine. It just means I need better systems.

And speaking of systems, I’ve been thinking about how many founders and tech teams are doing great work but aren’t entirely sure why.

Like sprinting full speed without checking the map. It’s made me more conscious of stepping back and asking, “What’s the goal here?” Not just with marketing - but also in the legal strategies I build.

And that brings me to a common issue I see with tech projects.

The Project Killer: “We’ll Figure It Out”

It usually starts with a promising client conversation. The scope is ambitious. The budget looks good. Everyone’s excited.

Then the client says something like: “We want the whole platform built on [insert shiny, new, completely unfamiliar stack].”

The team freezesbut only for a second. Then someone says the line: “We’ll figure it out.”

And just like that, the project enters dangerous territory.

What “We’ll Figure It Out” Really Means

On the surface, it sounds optimistic. Resourceful. Solution-oriented. But what it actually means is this: You’ve just agreed to something your team hasn’t tested.

You’ll be spending unbilled hours learning under pressure. You’re taking on delivery risk without protection. You’re gambling on a tech stack you don’t fully understand.

The result? It might look fine at first until the deadlines close in. That’s when bugs start surfacing.

The interface begins to lag. The logic misfires in ways nobody expected. And the client?

They don’t care that your team pulled three all-nighters watching Kubernetes tutorials on YouTube. They care that their platform doesn’t work.

When Learning Curves Turn Into Legal Risk

Every agency has a learning curve. Trying new stacks, tools, and APIs is part of growth. But what most teams miss is that the learning curve isn’t just a delivery risk - it’s a legal one.

If you haven’t made room for this uncertainty in your contract, the consequences are yours to own.

That means: Unplanned extra hours that go unpaid. Scope disagreements over bugs vs. expectations.

Delays that trigger penalties or refund demands. Reputational risk from unmet deliverables.

What You Should Do Instead

If your team is considering taking on a stack they don’t fully know, don’t panic. You don’t have to say no.

You just have to say it clearly - with documentation to match. Here’s what I recommend:

1) Acknowledge the Learning Curve

Tell the client:

“We haven’t worked with this exact stack before. We’re open to using it- but we’ll need extra time upfront for R&D, testing, and integration planning.”

This builds transparency and sets expectations early.

2) Add a Research or Sandbox Phase as a Line Item

Don’t bury it in your general timeline. Make it explicit:

“Phase 1: Technical research, sandbox setup, and testing. Estimated time: X days.”

This gives you legal and billing room to make mistakes, explore, and learn without breaching the agreement.

3) Insert a “Best Effort” Clause

This protects you when the tool or stack causes the issue - not your team. For example:

“Performance of the deliverables is subject to the limitations of third-party tools and technologies. We will use reasonable efforts but cannot guarantee full functionality across environments outside our control.”

4) Limit Liability for Tech You Didn’t Choose

If the stack was client-mandated, protect yourself accordingly. For example:

“We are not liable for delays, malfunctions, or integration failures resulting from the use of [Tool X / Stack Y], as selected by the client.”

That one sentence could save you weeks of unpaid stress.

TL;DR - Clarity > Optimism in Tech Contracts

Don’t let enthusiasm force you into blind commitments. Before agreeing to use a new or unfamiliar tech stack:

• Be upfront with the client about your experience

• Budget time and fees for early R&D

• Protect yourself with best-effort and liability clauses

• Define what’s out of scope if things go wrong

The Conclusion: You Don’t Have to Be an Expert, But You Do Have to Be Honest

In tech, it’s easy to fall into the “yes” trap. Yes to new stacks. Yes to aggressive timelines. Yes to client requirements you haven’t fully mapped.

But being agreeable doesn’t mean being unprotected. You can say yes to the work - while still writing contracts that make space for learning.

So the next time a client says, “Can you build it on [XYZ]?” Go ahead and say, “Sure, we’ll figure it out.” Just make sure your paperwork does too.