Build vs. Buy: POS and Customer Management, Decided With Math

Should you run your point of sale and customer management on a platform like Square or Shopify, or have something built for how your business actually works? If you're asking, it's usually because you've hit one of three walls: the monthly fee stack has crept past what feels reasonable, the platform won't do something your operation needs, or you've realized you don't actually control your own customer data.

This article gives you the decision framework we use: the fee math (done honestly, including what custom costs), the data-ownership question, the integration ceiling test, and — because it's the answer more often than a custom-software shop should probably admit — the cases where the platform simply wins.

Start with the honest default: buy

Square, Shopify, Toast, Clover, and their peers are good. They represent enormous engineering investment, they handle payments compliance you should not want to own, and they cost less per month than one day of custom development. The default answer for a new or simple retail operation is buy. Custom has to beat that default with specifics, not feelings. The rest of this article is about checking whether it does.

The fee math

Platform costs come in three layers, and only the first one is on the pricing page:

1. Subscription: the monthly plan fee, per location, often per register.
2. Processing: the percentage-plus-cents on every card transaction.
3. The app stack: loyalty, advanced reporting, subscriptions, marketing, booking — each a monthly add-on, each solving something the base plan almost does.

Run an illustrative scenario — your numbers will differ, and processing rates vary by plan and channel, so treat these as placeholders to overwrite. A hypothetical single-location retailer doing $60,000/month in card sales at an average $40 ticket (1,500 transactions):

| Cost layer | Illustrative figure | Monthly | | --- | --- | --- | | Plan + register fees | — | ~$90 | | Processing at ~2.6% + 10¢ | $60k × 2.6% + 1,500 × $0.10 | ~$1,710 | | Add-on apps (loyalty, reporting, marketing) | 4 apps averaging $45 | ~$180 | | Total | | ~$1,980/mo (~$23,800/yr) |

Now the crucial part most build-vs-buy math skips: custom doesn't eliminate processing. A custom system still runs payments through Stripe, Square's APIs, or a traditional processor at broadly similar rates. What custom actually removes is the subscription and app-stack layers — in this scenario about $270/month — plus the workaround costs the platform can't address (hand-reconciliation between systems, staff time fighting the tool, sales lost to a rule the platform can't express).

So the fee math verdict is blunt: if your only complaint is cost, stay on the platform. $270/month of removable fees will never pay back a custom build. Custom becomes financially rational only when the workaround column is large — when the platform's ceiling (next section) forces manual labor or blocks revenue. If a platform gap costs you, say, 10 staff-hours a week and a compliance workaround, that's the number that pays for a build, not the app fees.

The data-ownership question

Ask your current platform three questions:

1. Can I export every customer, with full purchase history, in a usable format — today? Most platforms allow customer exports, but histories, notes, loyalty balances, and marketing consent often export partially or not at all.
2. If I leave, what walks out with me? Gift-card liabilities, stored cards (portable only via processor-level migration), review content, and loyalty state are common hostages.
3. Who else can use my data? Read the terms on aggregated data. You may be feeding the benchmark your competitors buy.

On a platform, your customer list lives in someone else's building under someone else's rules. With custom software, the database is yours: every sale, every customer, every note, queryable however you want, exportable because you hold the keys. We treat this as a design requirement — clients own the code, the data, and the infrastructure accounts from day one.

How much is that worth? Honestly: for a coffee shop, very little — the customer relationship is the counter, not the database. For a business where the customer history is the asset — repeat-service businesses, wholesale accounts with negotiated pricing, regulated retail with compliance records — data ownership stops being philosophical and becomes operational. Which is really the next test:

The integration-ceiling test

Every platform has a ceiling: the point where "it almost does that" becomes "it can't." The ceiling is where build-vs-buy is actually decided. Probe yours with these:

• Pricing logic. Tiered wholesale pricing, member pricing, bundle rules, time-based pricing? Platforms handle the common cases; genuinely custom pricing models hit the ceiling fast.
• Compliance rules. Purchase limits per customer per day, age verification, product visibility rules, regulator-ready audit trails. In regulated retail — cannabis being the clearest example, and one SWRV's founder has built for extensively — these aren't features, they're conditions of operating. Most mainstream platforms won't touch some of these categories at all, starting with payments.
• Inventory shape. One SKU, one price, one shelf is easy everywhere. Batch tracking, expiry dates, unit-of-measure conversion (buy by the kilo, sell by the gram), made-to-order components — this is where platform inventory models crack.
• The unified-record test. Can the platform show one customer's activity across the register, the website, and the phone as one record? Or are you exporting three CSVs and VLOOKUP-ing them every month? If channel unification is manual, you're paying the custom-software cost in labor without getting the software.
• API depth. Not "does it have an API" — everything has an API — but: does the API expose the thing you need to change, at the volume you need, with webhooks for the events you care about? A platform with a good API raises its own ceiling; you can often build around the gap instead of replacing the platform. This hybrid — platform POS at the counter, custom layer for the pricing/compliance/reporting it can't do — is frequently the right second answer.

Score honestly. Zero ceilings hit: buy, and close this tab. One ceiling, reachable via API: hybrid. Multiple ceilings, or a compliance ceiling: you're in build territory.

When the platform simply wins

To be explicit about the buy column, because a custom shop telling you when not to hire it is information you can trust:

• Standard retail or food service, one or few locations, common pricing. Square/Toast/Shopify were built for exactly you. Take the win.
• You're new. Your process isn't stable yet. Custom software freezes whatever process it finds — freeze one that's proven first. Start on a platform, and let the workarounds you accumulate become the spec for what (if anything) to build later.
• Volume is modest. The economics above scale with transaction count and staff hours. At low volume, no workaround column gets big enough.
• The gap is cosmetic. Wanting nicer receipts or a different dashboard layout is not a build case.

And the build column, compressed: build when your process is your advantage and the platform forces you to abandon it — compliance-heavy retail, genuinely custom pricing, multi-channel operations reconciled by hand, or a customer dataset that is the business's core asset. This is the same "your process is the product" test that applies to replacing spreadsheets with custom software — the POS version of it.

A staged path instead of a leap

Build-vs-buy is usually framed as a cliff. In practice the sane path is staged:

1. Max out the platform first. Configure it properly — most "outgrown" platforms were never fully set up. Document every remaining workaround with hours attached.
2. Build around the ceiling. Keep the platform at the counter; add a custom layer via its API for the specific gap — the compliance module, the wholesale pricing engine, the unified reporting database that pulls every channel into one place you own.
3. Replace the core only when the math says so — when workaround hours plus blocked revenue clearly exceed build-and-maintain costs, migrate the counter last, after the custom system has been running the back office long enough to trust.

Stage 2 is underrated. It captures most of the data-ownership and ceiling benefits at a fraction of full-build cost, and it de-risks stage 3: by the time you replace the POS, your custom layer already holds your real data model.

Next steps

1. Assemble your real fee stack — plan, processing, every app — for the trailing three months.
2. Write the workaround list with weekly hours against each item. This column decides the question; the fee column rarely does.
3. Run the ceiling test above against your pricing, compliance, inventory, and channels.
4. Ask for the staged option. Whoever you talk to — including us — should be able to articulate a stage-2 hybrid, not just "migrate everything." Our Ecommerce & POS service is built around platform-honest recommendations: Shopify or Square when they fit, custom when the ceiling is real, and the custom software practice behind it when it is. The Project Builder will take your fee stack and workaround list directly and give us what we need to show you the math both ways.

Buy is the default. Build is the exception that proves itself with arithmetic. Do the arithmetic before anyone — vendor or developer — does it for you.