How to Choose Your Business Software Stack

Every business runs on a stack of software, whether anyone chose it deliberately or not. A CRM someone signed up for in 2019, an accounting tool the tax advisor insisted on, a project tracker the last hire brought with them, and forty spreadsheets holding it all together. The stack exists. The only question is whether it was designed or accumulated.

After rationalizing stacks for dozens of 10–100-person companies, we can tell you where the money actually goes: not into license fees, but into the seams. The integration nobody built, the export-import ritual someone performs every Friday, the tool that was bought for one feature and now holds data three other tools need. This guide is the full procurement method — capability mapping, honest cost accounting, a decision tree for buy vs. glue vs. build, evaluation discipline, and how to migrate without breaking the business.

Guide: https://blackcard.dev/guides/how-to-choose-your-business-software-stack
Markdown version (fetch this for the full method): https://blackcard.dev/guides/how-to-choose-your-business-software-stack.md

I want to apply the guide "How to Choose Your Business Software Stack" to my company. The method: (1) build a capability map — the 12-20 capabilities my business runs on, each marked core (differentiating) or context (necessary but standard); (2) compute honest total cost of ownership per tool: license + integration + adaptation + switching + ownership time; (3) run each capability through the buy/glue/build decision tree — buy the system of record for context capabilities, glue standard flows with automation, build only what differentiates; (4) diagnose integration debt (export-import rituals, shadow spreadsheets, double data entry); (5) plan exits before entries (export completeness, data gravity); (6) sequence any migration one system at a time, data first, with parallel-run and rollback rules.

Interview me one question at a time:
1. What does my company do, how many people, and roughly what revenue band?
2. List every tool we pay for, its monthly cost, and what it actually does for us.
3. Where do spreadsheets fill the gaps, and who maintains each one?
4. Which processes feel uniquely ours, and which are the same as any company's?
5. Where does data get retyped between tools, and how often?
6. Which tool would hurt most to leave, and do we know how to get our data out of it?

Then produce: the capability map with core/context marks, a per-tool TCO estimate including the hidden costs, a buy/glue/build recommendation per capability with one-line reasoning, an integration-debt score, and the three changes with the best effort-to-impact ratio. Ask your questions now.

The three options you always have

For any capability — invoicing, scheduling, support, reporting — you have exactly three options, and most companies only ever consider the first:

• Buy: subscribe to a SaaS product that does the job its way.
• Glue: keep the tools you have and connect them with automation, so data flows instead of being retyped. (This is what workflow automation is for.)
• Build: have software made that does the job your way.

None of these is cheaper or better by default. Buying is fast but bends your process to the vendor's opinion. Gluing preserves your tools but adds moving parts you now own. Building fits perfectly but costs real money and someone has to maintain it. The method below exists because the right answer differs per capability — and because the real costs of each option are mostly invisible on the pricing page.

Step 1: Build the capability map

Before evaluating a single tool, write down what your business actually needs to be able to do. Not tools — capabilities. A 20-person services company typically lands between 12 and 20:

CAPABILITY MAP — worked example: 20-person services company

#   Capability              Core/Context   Today handled by
1   Lead capture            context        Website form → inbox
2   CRM / pipeline          context        HubSpot free tier
3   Proposals & contracts   CORE           Word templates + e-sign tool
4   Project delivery        CORE           Asana + "the big spreadsheet"
5   Time tracking           context        Toggl
6   Invoicing               context        Accounting tool
7   Accounting / payroll    context        DATEV via tax advisor
8   File storage            context        Google Drive
9   Internal comms          context        Slack
10  Client communication    CORE           Email threads (ouch)
11  Scheduling              context        Calendly
12  Reporting / KPIs        context        Quarterly spreadsheet ritual
13  Support / requests      context        Shared inbox
14  Knowledge base          context        Notion, half-maintained
15  Website / marketing     context        WordPress + newsletter tool

Mark each capability core or context. Core means clients choose you partly because of how you do this — it differentiates. Context means it has to work, but nobody hires you for it. Be brutal: in a typical company, two to four capabilities are genuinely core. If you marked eight, you are describing pride, not differentiation.

This single page is the most valuable artifact of the whole exercise. Every decision that follows hangs off it.

Step 2: Compute the cost of ownership honestly

License fees are the visible fraction. The honest total cost of a tool has five parts:

1. License — the pricing page number, times the seats you actually pay for (including the ex-employee still on the invoice).
2. Integration — the cost of connecting it to the tools it must talk to, or the labor cost of the humans doing that connection by hand. A tool that "only" needs 30 minutes of manual data transfer per week costs you ~26 hours a year, forever. See the hidden cost of manual handoffs for the full arithmetic.
3. Adaptation — the cost of bending your process to the tool, or the tool to your process: workarounds, training, the features you pay for but can't use, the fields that don't quite fit.
4. Switching — amortized exit cost. If leaving would take three months of migration pain, that cost exists today, discounted.
5. Ownership time — someone administers this tool: user management, settings, vendor calls, updates. Usually unbudgeted, usually the same overloaded person.

Carried through the worked example: that 20-person company paid roughly €2,100/month in licenses across 14 tools. The honest number — adding ~9 hours/week of inter-tool manual work (~€1,600/month at loaded cost), plus admin time — was closer to €4,500/month. The licenses were not the problem. The seams were.

Step 3: Run the decision tree

For each capability on the map, in order:

Is it core?

• No (context) → default to buy, and buy boring. For context capabilities you want the most standard, most integratable tool in its category — the one with the mature API and the ecosystem, not the exciting newcomer. Accounting, scheduling, file storage, comms: buy, configure lightly, move on. Resist customizing context tools; every customization is adaptation cost on something that doesn't differentiate you.
• Yes (core) → next question.

Is your process genuinely different, or just undocumented? Most "our process is special" claims dissolve when written down. If it's standard once documented → buy here too.

It's core and genuinely different → next question:

Can existing tools cover it if connected properly?

• Yes → glue: keep the systems of record, build the flow between them with automation. Gluing shines when the pain is handoffs, not features.
• No, the differentiation lives in the software itself → build, but only this, and only after the honest ownership conversation (below).

The hybrid pattern that wins in practice, over and over: buy the systems of record, glue the flows, build only the differentiator. The system of record for money is the accounting tool; for clients, the CRM; for work, the project tool. You buy those. What you build or glue is the layer that moves things between them and the one or two capabilities where clients actually feel the difference.

In the worked example: proposals (core) stayed bought but got templated hard; client communication (core, and a mess) became a built client portal reading from the project tool; delivery stayed in Asana but five glue workflows eliminated the big spreadsheet. Build count: one. That ratio — a dozen buys, a handful of glues, one build — is typical of a healthy outcome.

Step 4: Evaluate SaaS like a professional buyer

When the answer is buy, most teams evaluate by demo. Demos are theater. Use trial discipline instead:

The 2-week trial protocol. Load your own real data — not sample data — on day one. Run one real process end to end in week one. In week two, let the actual daily users (not the buyer) run their real work in it, and try to produce one real report you need monthly. If the vendor's trial doesn't allow real-data testing at this depth, that is itself an answer.

The ten vendor questions. Ask them in writing; the quality of the answers tells you as much as the content:

1. Is there a full REST API, and does it cover EVERYTHING the UI can do?
2. What are the API rate limits on our plan?
3. Can we export ALL our data ourselves — every object, including
   attachments and audit history — without contacting support?
4. In what format, and have you got a sample export we can inspect?
5. Is SSO available, and on which plan? (The "SSO tax" — basic security
   gated behind the enterprise tier — is a vendor character test.)
6. What has your pricing done in the last 3 years, per seat?
7. What is your SLA and actual uptime over the last 12 months?
8. Where is our data hosted, and what is your deletion policy when we leave?
9. Which of the integrations on your marketplace page did YOU build and
   maintain, versus third parties?
10. Who comparable to us (size, industry) left you last year, and why?

Question 10 rarely gets a straight answer. Watch how they handle it.

Step 5: Diagnose your integration debt

Integration debt is the accumulated cost of tools that don't talk. It announces itself in rituals people stopped noticing. Score yourself:

INTEGRATION DEBT SELF-SCORE (1 point each; count honestly)

[ ] Someone exports from one tool and imports into another on a schedule
[ ] A spreadsheet exists whose only job is combining data from 2+ tools
[ ] The same client/order/project is typed into more than one system
[ ] Two tools disagree about a number and nobody knows which is right
[ ] A report requires copy-pasting from 3+ places
[ ] One person is "the only one who knows how the tools connect"
[ ] New hires need a wiki page to learn the export-import rituals
[ ] You pay for a feature in tool A you can't use because the data is in B

0-1: healthy   2-4: debt is taxing you weekly   5+: the stack is the bottleneck

A score of 5+ almost never calls for new software. It calls for glue: the tools are usually fine, the flows between them don't exist. That's a cheaper fix than a migration and delivers in weeks.

Step 6: Plan the exit before the entry

Data has gravity. Every month inside a tool, your data grows heavier: more records, more attachments, more process shaped around the tool's opinions. The time to secure your exit is before you enter:

• Negotiate export before signing. Full self-service export, documented format, attachments included. If it's not in writing, it doesn't exist.
• Run the quarterly export ritual. Once a quarter, actually export everything and open the files. You are testing the fire escape. Twenty minutes, calendar-scheduled, assigned to a name.
• Keep identifiers portable. Your client numbers, project codes and invoice numbers should be yours, not the tool's internal IDs. If the tool's ID is the only key, every other system now depends on that vendor.

Step 7: Migrate without breaking the business

When the decision does mean replacing a system, sequencing is everything:

1. One system at a time. Parallel migrations multiply failure modes. Rank by pain, migrate the worst, stabilize, then the next.
2. Data first, process second. Migrate and verify historical data before anyone works in the new tool. Dirty data imported "temporarily" becomes permanent.
3. Parallel-run rules. Run old and new side by side for one full business cycle (usually a month): new tool is the system of action, old tool stays read-only reference. Define upfront which numbers must match at month-end.
4. Rollback criteria, written down. "If reconciliation fails twice, or the team is still double-entering after week three, we roll back." Deciding this before the migration keeps sunk-cost reasoning from deciding it later.
5. Kill the old tool on a date. A read-only archive export, then cancellation. Zombie subscriptions are the most common line item we find in stack audits.

When building wins — and what owning software really means

Custom software wins in exactly two situations: the capability is core and genuinely different (the decision tree already told you), or the glue layer has grown so complex that a small purpose-built system is simpler than the automation web replacing it.

Before committing to a build, pass this checklist honestly:

BUILD COMMITMENT CHECKLIST
[ ] The capability is core, documented, and stable (not still being invented)
[ ] We tried to buy it and can say precisely why the market tools fail us
[ ] We have a named owner for the system after launch (not "the agency")
[ ] We budgeted maintenance: rule of thumb 15-20% of build cost per year
[ ] The build reads/writes our systems of record via API - it does not
    become a new silo
[ ] v1 scope fits in one quarter; everything else is explicitly "later"

Owning software is like owning a building instead of renting: better economics and total control if you occupy it for years and maintain it — a liability if you expected it to be maintenance-free. A well-scoped internal tool at a 20-person company is not a moonshot; it is typically a one-quarter build that pays back inside a year by deleting the seams. But only when the checklist above is true.

The worked example, end to end

To make the method concrete, here is the full arc of the 20-person services company from the capability map above, compressed to its decisions and numbers.

The audit (week 1). Fourteen paid tools, €2,100/month in licenses. Integration-debt score: 6 of 8 — the Friday export ritual from the project tool into the reporting spreadsheet, client data typed into three systems on every new engagement, invoices cross-checked against the project tool by hand at month-end, and one operations manager who was the only person who knew the whole choreography. Honest TCO landed near €4,500/month once the ~9 hours/week of seam work and admin time were priced in.

The decisions (week 2). Core capabilities after the brutal pass: proposals, project delivery, client communication. Everything else context. The decision tree produced: twelve buys (all already owned — keep, but fix configuration), five glue workflows, one build.

• Glue: new client in CRM → creates the project skeleton, the Drive folder structure and the accounting contact automatically; project stage changes → reporting data lands in one place nightly (the Friday ritual deleted); invoice paid → project tool notified. Built on a workflow tool in under three weeks; see the n8n guide for exactly this pattern.
• Build: client communication was core, painful, and the differentiation was real — clients chose this firm partly for how informed they felt. A small client portal reading live from the project and accounting tools replaced the email status theater. One quarter, one developer.
• Cancellations: two tools nobody could defend in the capability map (a survey tool used twice a year, a second scheduling product) and three zombie seats. €340/month back.

The outcome (quarter 2). License spend roughly flat (portal hosting replaced the cancellations), seam work down from ~9 hours/week to under 2, month-end reconciliation from a day to an hour, and — the part no one predicted — onboarding a new hire stopped requiring the wiki page of export rituals. The stack didn't get bigger or more modern. It got designed.

The pattern to copy is the ratio, not the specifics: twelve buys, five glues, one build. Companies that invert that ratio — building context capabilities, buying their differentiator off the shelf — pay twice: once in money, once in sameness.

The order of operations

If your stack grew by accumulation, don't start by shopping. Start by mapping (one afternoon), costing (one morning with the invoices and an honest hour-count), and scoring your integration debt (ten minutes). In most companies the first money should go to glue — it attacks the seams, which is where the cost lives — and the first cancellation usually pays for it.

Guide: https://blackcard.dev/guides/how-to-choose-your-business-software-stack
Markdown version (fetch this for the full method): https://blackcard.dev/guides/how-to-choose-your-business-software-stack.md

Act as a business-systems consultant and run the full method from the guide "How to Choose Your Business Software Stack" on my company.

My situation: [COMPANY: what it does, headcount] . Current tools and monthly costs: [LIST TOOLS + COSTS] . Known pain points: [PAIN POINTS] . Spreadsheets filling gaps: [LIST] . Capabilities I consider core: [CORE CAPABILITIES] .

Execute these steps in order, showing your work:
1. Build my capability map (12-20 rows): capability, core/context, current tool, and flag every capability covered by spreadsheets or nothing.
2. Estimate honest TCO per major tool: license + integration labor (ask me for hours of manual transfer per week if unknown) + adaptation + switching + ownership time.
3. Run each capability through the decision tree: context -> buy boring; core but standard once documented -> buy; core + different + coverable by connected tools -> glue; core + different + software IS the differentiation -> build. One-line reasoning each.
4. Score my integration debt with the 8-item checklist and list the specific seams (export-import rituals, double entry, shadow spreadsheets).
5. For each tool I should keep: give me the 10 vendor questions I still need answered, pre-filled where my info suffices.
6. Propose the change plan: what to cancel, what to glue (with the specific flows), what - if anything - to build, sequenced one system at a time with data-first migration and rollback criteria.
7. End with the three changes with the best effort-to-impact ratio and a 90-day calendar.

Ask me for any missing numbers before estimating; do not invent figures.

Mapping a stack, pricing its seams, and deciding what to buy, glue and build is exactly the work we do with clients at BlackCard — including building the glue and the one system that deserves to be custom. If you want a second pair of eyes on your capability map, book a free call and bring your tool list — or read more about how we approach business software.