Skip to content
BlackBadger

Blog / General

How to decide between configuring, switching, and building

/ 11 min read

TL;DR

Most companies frustrated with their software should configure it better rather than switch or build, but the decision depends on whether your workflow is a competitive advantage, the tool has structural limitations, or pricing scales unfairly with growth.

Key takeaways

  • Frustration with a platform is usually a symptom of no admin owner, not a bad platform.
  • Switching only makes sense when the new tool fixes a structural mismatch, not a cosmetic one.
  • Building is the right call when your workflow is a differentiator or when seat costs scale faster than revenue.
  • Score the decision across four factors instead of arguing about opinions in a meeting.
  • A custom system will not fix an undefined process or bad data habits. It will expose both.

You're paying for a platform your team complains about weekly. Somebody on the leadership call says "we should just build our own." Somebody else says "we should look at what else is out there." Nobody has data. Everybody has an opinion. Here's how to actually make that call without spending six months and a pile of money finding out you were wrong.

On this page
  1. The honest baseline, most of you should configure
  2. When configuring is the right answer
  3. When switching is the right answer
  4. When building is the right answer
  5. A rubric you can actually score
  6. Three hypothetical companies, three different answers
  7. What building does not fix
  8. Your next step
  9. Read this next
  10. Frequently asked questions

TLDR

Most companies who hate their software don't need new software. They need someone to own the setup. Configure first. Switch when a different tool in the same category genuinely fits your work better and the move pays for itself. Build when your process is the thing you win on, when no off-the-shelf tool can model it, when per-seat pricing punishes you for growing, or when your stack has splintered into six systems that don't talk. Build for the right reason and you own an asset. Build for the wrong reason and you own a mess you now have to maintain.

The honest baseline, most of you should configure

I'll say the unpopular thing first. In most of the situations where a company is angry at its project management or CRM tool, the tool is fine. What's missing is ownership.

Look at how these platforms usually get bought. Someone signs up. Ten people get invited. Nobody defines what a project record should contain. Nobody decides which fields are required. Nobody builds the views that answer the boss's questions. Six months later the data is garbage and everyone blames the software.

That's not a software failure. That's a setup failure. And no new platform survives contact with the same habits.

Ask yourself a hard question before you spend anything. Does anyone at your company own this system as part of their actual job description? Not "is good at it." Own it. Has time blocked for it. Gets measured on whether it works. If the answer is no, that's your first fix, and it's cheap compared to everything else in this article.

If your team can't explain your current process on a whiteboard in fifteen minutes, don't buy anything and don't build anything. You'll pay a vendor or a developer to document it for you at a much worse rate than doing it yourself.

When configuring is the right answer

Configure when the platform can already do what you need and nobody has made it do that. This is more common than people think. Modern tools ship with an enormous amount of unused capability.

The signs are pretty clear. Your complaints are about missing reports, confusing views, or inconsistent data entry. People use spreadsheets on the side because the main system doesn't show them what they need. Two departments enter the same information differently. Nobody has built an automation in a year.

All of that is fixable inside the tool you already pay for. Real configuration work looks like cleaning up your field structure, deleting the fifty custom fields nobody fills in, writing down what a "stage" actually means, building the three or four saved views that answer the questions leadership asks every Monday, and training people on the version that now exists.

It's unglamorous. It also works. And it costs a fraction of any alternative because you're not moving data, retraining from scratch, or rebuilding integrations.

One caveat. Configuration hits a ceiling. If you find yourself building workarounds on top of workarounds, or if your admin spends more time patching automations than improving them, you've passed the point where more configuration helps. That's a real signal, and you should take it seriously rather than grinding for another year.

When switching is the right answer

Switching is the narrowest of the three options, and it's the one people reach for most casually.

A switch makes sense when there's a structural mismatch between how your work flows and how the platform models work. Not a preference. A mismatch. If you run a job shop with dependent production stages and your tool only models flat task lists, you'll fight that forever. If you bill on retainer with rollover hours and your system only understands fixed-fee projects, same story. Those are structural.

What isn't structural: the interface feels dated, a competitor has a nicer dashboard, a salesperson demoed something shiny. Those get you six months into a migration before you notice the new tool has different limitations you didn't know to ask about.

Before you commit, price the whole move honestly. Not the subscription. The move.

  • Exporting historical records, including attachments, which almost never come out cleanly
  • Rebuilding every integration to accounting, email, and your field tools
  • Retraining everyone and absorbing the productivity dip while they relearn
  • Running both systems in parallel for a period so you don't lose history
  • The internal hours your ops lead spends on all of the above instead of their job

If that total is recoverable within a year or two through real gains, switch. If you're switching to avoid a config project, you're going to do the config project anyway, just on a platform you don't know yet.

Ask any prospective vendor exactly how you get your data back out, in what format, and whether file attachments are included. Get the answer in writing. Plenty of platforms have a lovely import and a miserable export.

monday.com help center article titled Export from monday to Excel displaying the Connect and automate category a tip about importing from Excel and the first step to click the three dot menu at top right of your board
monday.com help center article about exporting from monday to Excel shows the export board to Excel option and beginning of step by step instructions Source: support.monday.com/hc/en-us/articles/26989749858578-Export-from-monday-to-Excel
HubSpot Knowledge Base article on exporting content and data showing available subscription levels, account data export options, and a table of contents listing data types that can be exported.
HubSpot Knowledge Base shows an account management article titled Export your content and data with details on exporting pages, contacts, files, and account data types. Source: knowledge.hubspot.com/account-management/export-your-content-and-data

When building is the right answer

Four conditions push you toward a custom system. You don't need all four. Two strong ones usually settle it.

The first is process uniqueness. If the way you schedule, quote, or fulfill is genuinely different from everyone else in your industry, and that difference is why customers pick you, an off-the-shelf tool will sand it down. Configuring a generic platform to be unique is the expensive way to get a worse result.

The second is object model mismatch that no vendor solves. Every platform has a fixed idea of what a record is. Deal, project, task, contact. If your business runs on something that doesn't fit any of those, you'll spend years pretending. I've seen companies use a "project" record to represent a physical piece of equipment that moves between customers. It sort of works. It never works well.

The third is per-seat math. This one you can calculate on a napkin. Say you're at 60 users on a platform at $79 per user per month. That's $56,880 a year, every year, forever, and it goes up when you hire. Add 20 people and you're near $76,000. Now compare that to a system you commission once and own. You still pay for hosting and ongoing changes, but nobody charges you rent per employee. Run your own numbers across a five year window before dismissing this.

The fourth is stack fragmentation. When you've got a CRM, a separate scheduler, a quoting tool, a spreadsheet for commissions, and a project tracker, and three people spend their days retyping between them, the integration tax has already exceeded a build. You're just paying it in salaries instead of software.

Count the rekeying. Pick one week and have your team log every time they copy information from one system into another. That number, multiplied by loaded hourly cost, is the honest price of your current setup.

A rubric you can actually score

Stop debating and score it. Rate each of these one to five, where five means strongly true for your business.

  1. Process uniqueness. Is how you work a real differentiator, or is it industry standard?
  2. Headcount trajectory. Will your user count grow meaningfully over three years?
  3. Integration burden. How many systems hold pieces of the same job, and how much manual transfer happens between them?
  4. Data ownership needs. Do you need direct access to your own data for reporting, compliance, or eventual sale of the business?

Total under 8 and you should configure what you have. Between 9 and 13, look hard at whether a different platform in the same category fits better. Above 14, a custom build is probably the cheaper answer over five years, and it's certainly the one that leaves you owning something.

The rubric isn't magic. It forces the conversation to be about facts.

Three hypothetical companies, three different answers

These are illustrative examples, not clients. They're the patterns I see repeatedly.

The 25 person marketing agency

They're frustrated with their project tool. Nobody updates tasks. Leadership can't see capacity. But their delivery process is standard agency work, headcount is flat, everything already connects to their accounting system, and they have no unusual reporting needs. Score around 6. They don't need anything new. They need one person who owns the tool, a cleanup of their project template, and a rule that time gets logged daily. Configure.

The specialty contractor at 90 employees

They use a CRM that models deals but not jobs. Every job has crews, equipment, permits, and multi-visit scheduling. They're jamming all of it into notes fields. Headcount is growing. But there are real vertical platforms built for exactly this trade. Score around 11. A purpose-built industry platform fixes the structural mismatch for less than a ground-up build. Switch.

The equipment rental and service company

They track units, contracts, service history, and billing across five systems. Two full-time people move data between them. Their scheduling logic is genuinely unusual and it's why they win bids. They're growing fast and every new hire adds seat cost across all five tools. Score around 17. Build.

What building does not fix

A custom system is a mirror. It shows you exactly how you work, including the parts you've been avoiding.

It won't fix an undefined process. If four managers each run jobs differently and nobody will decide which way is right, a developer can't decide for you. You'll get four options in the interface and the same chaos with a nicer skin.

It won't fix bad data discipline. If people don't update records today, a new system won't make them. Custom software can make entry faster and can enforce required fields, but it can't make someone care.

It won't resolve internal disagreement. This is the one that kills projects. When sales and operations fundamentally disagree about when a job becomes real, that argument has to end before anyone writes code. Otherwise it ends halfway through the build, expensively.

And it isn't free after launch. You own it, which means you're responsible for hosting, security updates, and changes as your business shifts. That's a real ongoing commitment. It's usually smaller than what you were paying in subscriptions, but it isn't zero, and anyone who tells you otherwise is selling.

The worst build outcomes start the same way. A company automates a broken process instead of fixing it first. Now the broken process runs faster and costs more to change. Map the workflow you want, not the one you have.

Your next step

Score the rubric this week. Get your ops lead and one skeptical department head in a room and do it together. If you land under 8, you just saved yourself a lot of money and you know exactly what to work on. If you land above 14, get real numbers on your current per-seat spend and your manual rekeying hours before you talk to anyone.

If you want a second opinion from people who'll tell you to keep what you have when that's the right answer, book a free strategy session. We're in Clearwater and we work across Pinellas and Hillsborough counties.

Read this next

When per-seat pricing stops making sense for your business

Related articles

Frequently asked questions

How long should we try configuring before giving up on it?

Configuration hits a ceiling when you find yourself building workarounds on top of workarounds, or when your admin spends more time patching automations than improving them. If you've reached that point, it's a real signal to stop grinding and consider other options rather than continuing for another year.

When is it actually a good time to switch to a different software platform?

Switch when there's a structural mismatch between how your work flows and how the platform models work. This means the tool fundamentally can't handle your business process, not just cosmetic issues like an outdated interface. You should also price the entire move honestly, including data migration, integration rebuilding, and retraining. Only switch if those costs are recoverable within a year or two.

What's the most common reason companies complain about their software?

Most frustration with software comes from setup failure, not software failure. Usually nobody owns the system as part of their job description, which means fields aren't configured, data entry standards aren't defined, and automations aren't built. Before spending money on new solutions, assign someone to actually own the system.

What conditions mean we should build custom software?

Build when your process is genuinely different from competitors and gives you an advantage, when no off-the-shelf tool can model your workflow, when per-seat pricing punishes you as you grow, or when your stack has split into multiple systems that don't communicate. You need two strong conditions to justify building.

Can we configure part of a platform and build custom features for the rest?

The article doesn't prevent combining approaches, but it emphasizes that building solves specific problems. Build only when off-the-shelf tools truly can't model your process. Building for the wrong reason creates a system you have to maintain indefinitely.

What won't a custom build fix?

A custom system will not fix an undefined process or bad data habits. It will expose both of them. If your team can't explain your current process on a whiteboard in fifteen minutes, don't build anything yet. You'll be paying a developer to document your process at a worse rate than doing it yourself first.

Share this article

Keep reading

When staying on your current platform is the right call

Custom software isn't always the answer. Here's the arithmetic, the warning signs, and the honest caveats that tell you whether to renew your platform or replace it.

If this is your situation

Talk it through on a call

Thirty minutes over video with the person who would run the build. You talk, we ask questions, and you leave with a plain read on whether custom software makes sense for you. If the answer is that your current tool is fine and badly configured, you will hear that.

Book a strategy call

Who wrote this

David Verneuille

David Verneuille

Founder, Black Badger Software Solutions

David Verneuille founded Black Badger after 18 years as a project manager and years implementing Smartsheet, monday.com, Wrike and Zoho for clients. He now builds custom systems that clients own outright, which is why the writing here is specific about where each platform fits and where it stops fitting.

About Black Badger

Drafted with AI assistance, then checked, edited, and approved by a person before publishing. The facts, opinions, and recommendations are ours.

Related

More on general

More reading

Read this next

Want this looked at properly?

An article can only go so far without knowing your systems. Book a strategy call, walk us through what is breaking, and you will get a straight read on whether custom software is the right answer.