The build-versus-buy debate has always offered two endpoints: keep paying for the suite, or rip it out and rebuild. Most companies need neither. Look at who actually holds your licensed seats and a pattern appears in almost every deployment: a small core of people who create and edit, surrounded by a much larger ring who only view, approve, and read dashboards, all paying the same per-seat price. There is a third pattern for exactly this shape. Keep the vendor as your system of record. Custom-build the consumption layer. Remove the read-only seats. Call it the partial build: replace the seat, not the suite.
Why are you paying editor prices for people who only read?
Because per-seat pricing rarely distinguishes creation from consumption. In most deployments a minority of licensed users create and edit records; the majority view, approve, or read reports built from other people's work. Vendors understand this asymmetry, where viewer tiers exist at all, they are priced carefully to protect the seat count.
You can see the overpayment in the workaround economy every organization develops:
- ▸Screenshots pasted into Slack because a stakeholder does not have a seat.
- ▸PDF exports emailed weekly to a distribution list of people who will never log in.
- ▸The eternal Excel export, refreshed by hand until it quietly becomes the real system, the failure mode we dissected in When the Spreadsheet Becomes the Database: An SME Escape Plan.
Business intelligence is the extreme case, viewer seats for people who consume one chart a week, and we ran the seat math on custom dashboards versus Power BI and Tableau separately. The pattern below generalizes it to CRMs, project tools, and ERPs.
What is the partial-build pattern?
Keep the vendor product as the system of record for the people who genuinely create and edit in it. Build a thin custom application, synced from the vendor's API into a database you own, for everyone who only consumes: viewers, approvers, report readers. Then remove those users' seats at the next renewal boundary.
It sits deliberately between the two documented options:
- ▸Staying means the consumption ring compounds your bill forever, at whatever uplift each renewal brings.
- ▸Full replacement means rebuilding the creation tools too, the hardest 20 percent of the product, for the fewest users.
- ▸The partial build keeps the suite for the core who need it and rebuilds only the surface the other 80 percent touch: lists, detail views, dashboards, and approval buttons.
It has siblings. Keeping HubSpot for marketing while building the operational core it was never meant to be splits by function; the partial build splits by user. Both refuse the false binary of all-vendor or no-vendor.
How do you find out which seats are truly read-only?
Measure; do not survey. Pull 90 days of audit or activity logs and classify every licensed user by their write actions: records created, fields edited, comments made. Users whose only writes are approvals or status changes, or who show no activity at all, are consumption-layer candidates. People overstate their own usage; logs do not.
Classify into five buckets:
- ▸Creators, originate records. They keep their seats.
- ▸Editors, modify substance regularly. They keep their seats.
- ▸Approvers, their only writes are approve, reject, or a status flip. Candidates.
- ▸Pure readers, views and report loads only. Prime candidates.
- ▸Ghosts, no login in 90 days. Cut these seats now, before any engineering; removing never-login seats is the only free money in software.
Two classification traps: seasonal users, finance edits heavily at quarter close and reads otherwise, so classify across a full business cycle, and shared logins masking several humans behind one seat, which is a security problem to fix, not a pattern to preserve.
What does the architecture actually look like?
Four pieces: a sync service pulling from the vendor's API, webhook-driven where offered, scheduled pulls otherwise, with periodic full reconciliation regardless, into a Postgres you own; a thin web application behind your SSO with role-based views; a narrow write-back path for approval actions; and a visible data-freshness indicator on every screen.
Design notes from the field:
- ▸Sync: store raw API payloads, then project them into clean read models. Webhooks drop silently, so reconciliation is not optional. Budget the vendor's API quota into the design; some platforms meter or separately price API volume, so check current platform pricing before committing.
- ▸The read app: server-rendered list and detail views beat recreating the vendor's UI. Build for the three or four questions consumers actually ask of the data, not for parity.
- ▸Write-back: approvals post through the vendor API under a service account, with an audit trail mapping every action to the human who took it, never let the service account become an anonymous super-user.
- ▸Freshness: show 'synced 4 minutes ago' on every page, and match sync frequency to the workflow. The layer loses trust permanently the first time someone acts on stale data without knowing it was stale.
Is reading your own data through the API even allowed?
Usually, but verify before building. Check your agreement for indirect access, multiplexing, or named-user clauses: language that charges for humans who benefit from the data without logging in. Disputes over indirect access are well documented in the ERP world, and some vendors price API access as a separate platform tier. Read your MSA, then the current API terms.
For EU organizations the regulatory floor is rising in your favor: data portability under GDPR and the switching obligations arriving with the EU Data Act's access-by-design requirements strengthen your claim to your own data. But the contract still governs how that data may be consumed and by whom, so put legal eyes on the specific clause and verify against the vendor's current published terms, not forum folklore. If the clause is hostile, that is a renewal negotiation item, and a demonstrated alternative moves it, as we argue in Build the Exit Before the Renewal.
How do you roll it out without breaking anyone's workflow?
Shadow first, cut later. Launch the read layer to one consumer team while their vendor seats stay active, measure logins in both systems, fix the gaps the vendor-login data reveals, then expand team by team. Seats come off at the renewal boundary, not mid-term, mid-term removals rarely earn refunds.
The rollout order follows risk:
- ▸Pure readers first, lowest stakes, fastest feedback.
- ▸Approvers second, once the write-back path has run clean for a few weeks.
- ▸Single-action writers last, and only where the API supports their action faithfully.
- ▸Creators never, moving them is a different project with a different risk profile.
Your success metric is vendor logins from migrated users trending to zero. Anyone still logging in has a workflow you missed: treat each one as a requirement, not a compliance failure. Keep a small pool of licensed fallback seats through the first quarter, and time the reduction against your renewal notice window so the savings actually land.
What does it cost, and when does the math clear?
A consumption layer for one system is typically a four-to-ten-week build, depending on workflow count and write-back complexity, plus modest ongoing maintenance for API drift. The payback test is one line: seats removed times per-seat annual price, against amortized build plus run cost. Run it with your numbers, not anyone's marketing.
The formula, with its assumptions in the open:
- ▸Annual saving = (removable seats x annual per-seat price at renewal) minus (build cost divided by amortization years) minus annual maintenance minus infrastructure.
- ▸Use the renewal price including the proposed uplift, not the historical one.
- ▸Budget maintenance as a realistic fraction of build cost per year, APIs drift, and someone must own the sync.
- ▸Infrastructure for a read-heavy internal app is usually minor.
What moves the answer is seat count and price band; the build cost is comparatively flat across deployment sizes, which is why the pattern strengthens as deployments grow. For grounding the build side of the equation, see How Much Does It Cost to Build Custom Software in 2026?.
Where does the pattern stop working?
It stops when consumers turn out to be creators, when the vendor meters or forbids the API traffic the sync needs, when compliance requires acting inside the vendor's native audit trail, or when collaboration itself, comments, mentions, live editing, is the product's value. And below a few dozen removable seats, the arithmetic rarely clears.
- ▸Hidden creators: logs say read-only, quarter-end says otherwise. Classify across a full cycle before cutting.
- ▸API economics: per-call pricing or platform fees can eat the saving, model them explicitly.
- ▸Regulated workflows: if auditors require the vendor's native trail for an action, that action stays in the vendor.
- ▸Network features: if the value people get is collaboration rather than data, a read layer strips exactly what they came for.
If several of these apply at once, you are really choosing between staying and a full migration, and that decision, with its sequencing and parallel-run mechanics, is what our complete guide to escaping SaaS for custom software is for.
How TuniCyberLabs helps
We build consumption layers end to end: the audit-log seat analysis, the sync architecture against your vendor's actual API and rate limits, the read-and-approve application on infrastructure you own, and the renewal timing that turns the build into banked savings, fixed scopes, EU and North Africa engineering. Explore what we build on our custom software services page.
Send us your seat count and renewal date, and we will tell you honestly whether the math clears.