At some point, every designer hears it. You're mid-project, the client's getting ambitious, and they ask: "Should we just build something custom?"

It's a loaded question. Say yes too quickly and you might be steering them toward a six-figure project they don't need. Say no reflexively and you could be condemning them to years of awkward workarounds in software that was never designed for their business.

I've been on both sides of this. I've watched clients waste money on custom builds when a Shopify plugin would've done the job. I've also seen businesses limp along with duct-taped solutions for years because someone told them "off-the-shelf is always cheaper." Neither outcome is great.

There's no universal answer. But there is a framework for thinking it through. And if you're the designer in the room, you're often better positioned to guide this decision than anyone realises.

When Off-the-Shelf Actually Makes Sense

Most businesses don't need custom software. If your client wants an online store, Shopify or WooCommerce will handle 90% of use cases. Need a CRM? HubSpot, Pipedrive, or Salesforce have spent years refining theirs. Project management? Asana, Monday, Notion. Take your pick.

Off-the-shelf wins when the problem is common, the budget is tight, or speed matters most. A startup validating a concept shouldn't be building proprietary inventory management systems. They should be testing their market with whatever gets them there fastest.

Off-the-shelf software also gives you a community. Documentation. Regular updates. When something breaks at 2am, someone on Stack Overflow has probably already solved it. Custom software doesn't come with that safety net.

So before you entertain the custom conversation, ask yourself: is there an existing tool that does 90% of what they need? If yes, start there.

The Warning Signs That Custom Is Genuinely Needed

Sometimes off-the-shelf really doesn't cut it. I've learned to watch for a few specific patterns.

The workflow is genuinely unique. I worked with a logistics company that needed to coordinate deliveries across three countries, each with different customs requirements, in real-time. They'd tried adapting a standard shipping platform. It was a disaster. The workarounds were costing them more in staff time than a custom system would have cost to build.

Integration has become a nightmare. When a business runs on five different platforms that don't talk to each other, someone ends up copying data between them manually. I've seen finance teams spend entire days just reconciling spreadsheets because their invoicing software can't connect to their project management tool. At some point, building a unified system costs less than the salary of the person doing data entry.

They want a competitive edge. If your client's competitors all use the same tools, they'll all have roughly the same capabilities. Custom software can create something proprietary. A better customer experience. A faster internal process. A feature nobody else offers. This is where working with a bespoke software development provider makes strategic sense, not just operational sense.

Security or compliance demands it. Healthcare, finance, legal. Some industries have requirements that generic software can't satisfy. When you're dealing with sensitive data and strict regulations, "it mostly works" isn't good enough.

They've outgrown their tools. What works for a 10-person company often breaks at 100. Scaling pains are real. If they're constantly hitting limits (user caps, storage ceilings, features locked behind enterprise pricing) it might be time to build something that grows with them.

How to Scope a Custom Project Without Losing Your Mind

Assuming you've decided custom is the right path, the next challenge is scoping it properly. This is where projects go off the rails. I've seen it happen more times than I'd like to admit.

Start by separating needs from wants. Ask the client to describe their ideal outcome in detail, then work backwards. What's the minimum version that would actually solve their problem? That's your MVP. Everything else goes on a "phase two" list that may or may not ever happen.

Be ruthless about this. Clients will tell you they need seventeen features on day one. They don't. They need the three features that address their core pain point. The rest can come later, once they've validated that the system actually works for them.

Get specific about integrations early. "It needs to connect to our accounting software" sounds simple until you discover their accounting software is a 15-year-old installation with no API. Integration complexity is the number one source of budget overruns in custom projects. Map it out upfront.

And talk about ongoing costs. Custom software isn't a one-time purchase. It needs hosting, maintenance, updates, security patches. Make sure the client understands they're not buying a product. They're investing in a capability that requires ongoing care.

What Designers Should Know About the Development Process

I wish someone had told me this earlier in my career: your involvement shouldn't end when you hand over the Figma file.

Developers interpret designs. Even good ones make assumptions. If you're not in the room (or at least available on Slack) when those assumptions get made, you'll end up with something that looks like your design but doesn't feel like it. The micro-interactions, the edge cases, the responsive behaviour. These details get lost in translation unless someone's paying attention.

Design systems help enormously. If you've built a proper component library with documented states and behaviours, developers have something concrete to reference. "Use the secondary button from the system" is clearer than "make it look like the other buttons, you know, the less important ones."

Don't be precious about pixel perfection in early stages. Development is iterative. The first build will have rough edges. That's normal. Save the polish for when the functionality is locked. Otherwise you'll drive yourself (and the dev team) crazy with revision cycles that don't matter yet.

Making the Recommendation

Your job as a designer isn't to make the build vs. buy decision for your client. It's to help them make an informed one.

Frame custom software as an investment, not an expense. Yes, it costs more upfront than a SaaS subscription. But if it saves 20 hours of staff time per week, or enables a revenue stream they couldn't access before, the maths often works out in its favour.

Present the trade-offs honestly. Off-the-shelf is faster and lower risk, but comes with constraints. Custom is flexible and powerful, but demands more time, money, and ongoing commitment. Neither is inherently better. It depends entirely on the situation.

And when you don't know the answer, say so. I've found clients respect "I'm not sure, but here's how we can find out" far more than false confidence. Suggest a discovery phase. Bring in a technical partner for a second opinion. The goal is to get it right, not to look like you already have all the answers.

When you help a client make the right technology choice, whether that's a SaaS tool or a bespoke build, you're not just delivering a design. You're shaping how their business operates for years to come, and that’s worth taking seriously.