How I Decide Whether to Take a Project Outside My Stack

Should a specialist take a project that runs on tools they do not usually use?

Sometimes, but only when the core of the work is still my craft and the unfamiliar tool sits at the edge. I say yes when the hard part is go-to-market logic I know well. I say no when the hard part is the tool itself, because then the client is paying for my learning curve.

This question comes up more than people expect. A prospect wants lead routing built, but their CRM is not the one I use most. A founder wants a new marketing site, but their team has already committed to a platform other than Webflow. The work sounds like mine. The stack does not.

Over 6+ years and 100+ projects for 25+ clients, I have learned that this decision shapes outcomes more than almost any line in a proposal. Here is the framework I use, and the parts of it I learned the hard way.

What counts as outside my stack?

For me, outside my stack means any project where the main build happens in a tool I have not shipped production work in. My core is Webflow for websites, as a Certified Webflow Partner, plus the CRM and automation tools I have running systems in. Anything else gets this check first.

The definition is about production work, not familiarity. I can find my way around many tools. That is different from knowing where they break, how their limits behave under load, and what support looks like when something fails at the worst moment. Production experience is what a client is really paying for.

My automations in production for Ajust, built on Airtable and WhaleSync, and for Kismet Health, built on HubSpot through Zapier, are good examples of what "in my stack" means. I know those systems well enough to predict problems before they happen. That kind of knowledge takes real projects to build.

What question do I ask first?

I ask where the hard part of the project lives. If the hard part is deciding how leads should be scored, routed, and reported, that is go-to-market logic, and it travels across tools. If the hard part is bending an unfamiliar platform to do something unusual, the tool is the project, and I am the wrong person.

Most projects split cleanly once I ask this. A routing system for a team on a different CRM is often mostly logic. The rules, the edge cases, and the reporting are the same thinking, whatever tool runs them. The tool specific part might be a small share of the work.

On the other hand, a website rebuild on a platform I have not shipped on is mostly tool work. Design decisions transfer, but templates, CMS structure, hosting quirks, and performance tuning are where the time goes. That is exactly where my experience would be thin.

How do I check whether I can deliver at my usual standard?

I estimate how much of the project depends on tool specific knowledge, then ask whether I could learn that part on my own time without billing for it. If the answer is yes, and the client knows the tool is new to me, the project can work. If not, I decline.

My pricing is fixed fee, with most projects between $1,000 and $10,000. That model makes this check more important, not less. With a fixed fee, any time I spend learning a new tool comes out of my margin, not the client's budget. That is fine for a small share of the work. It is not fine when learning is most of it.

The other test is support after launch. If something breaks three months later, can I fix it quickly? For tools I know well, diagnosing a problem is usually quick. For a tool I touched once, the same problem can take far longer. Clients feel that difference long after the project ends.

When do I say yes to an unfamiliar tool?

I say yes when three things are true. The hard part is logic or strategy I know well. The unfamiliar tool has clear documentation and a sane API. And the client agrees, in writing, that this tool is new to me and that the plan includes a small test before the full build.

The small test matters. Before committing to the whole project, I build one piece in the new tool, such as a single routing rule or a single sync. If it behaves the way the documentation says, I go ahead. If it surprises me in bad ways, I have learned that cheaply and can still change course.

Honesty with the client matters even more. I tell them plainly which parts of the work I know deeply and which parts involve a tool I am newer to. I think clients deserve to know this before they sign. A client who is put off by that honesty would likely have been put off by problems later anyway.

When do I say no?

I say no when the tool is the main event, when the client needs deep platform expertise from day one, or when I would be the only person maintaining something I barely understand. In those cases, the best thing I can do is refer the work to someone who lives in that tool.

Saying no to work that sounds like mine is uncomfortable. The fee is real, and the client often likes me. But taking a project I cannot deliver at my usual standard costs more than the fee. It costs the trust and referrals that come from a happy client, and those are worth more than any single fee.

I wrote more broadly about turning down poor fits in how I say no to bad fit clients. Stack fit is one specific version of that decision. It is easier to explain, because it is about the tools, not the person, and clients usually understand it right away.

What about clients who picked a tool I would not have chosen?

That is a different situation from an unfamiliar stack. If the client has chosen a tool I know but would not have recommended, I can still do great work, as long as I state my concerns once and then build the best version within their choice. Respecting the client's decision is part of the job.

The key is to separate "I would not pick this" from "I cannot deliver well in this." The first is an opinion I share once and then let go. The second is a reason to decline. Mixing them up leads either to arguing with clients about tools forever or to taking work I should not take.

I covered the first case in more depth in what I do when a client picks a tool I would not. The short version is that clients own their stack. My job is to give honest advice, then deliver within the choice they make.

What does this have to do with ownership after launch?

Everything. A system is only as good as the person who maintains it after I leave. If the client's team cannot own a tool, and I cannot support it well, the project is fragile from the start. Stack decisions are really maintenance decisions, made early, when changing course is still cheap.

This is the same reason I turn down automation projects with no clear owner on the client side. I explained that rule in why I turn down projects without a CRM owner. Unfamiliar tools and missing owners create the same risk: a system nobody can confidently fix.

So when I evaluate a project outside my stack, I ask one last question. Six months from now, who fixes this when it breaks? If the answer is a confident person on the client's team, or me with real knowledge of the tool, it can work. If the answer is nobody, I pass.

What should you do next?

If you are a freelancer or specialist weighing a project in an unfamiliar tool, ask where the hard part lives, whether you can learn the tool specific parts without billing for them, and who will fix the system in six months. If any answer worries you, refer the work instead.

If you are a founder or marketer hiring someone, ask them directly which tools they have shipped production work in. A specialist who tells you honestly where their experience is thin is more trustworthy than one who claims every tool. That honesty is usually a sign of how they will handle problems later.

If you want help with a go-to-market system, a website, or the automations behind them, and you are not sure whether your stack is a fit, reach out. I will tell you plainly whether I am the right person, and if I am not, I will try to point you to someone who is. Let's chat.