Campus One Card and Access Control: Keep Transact or CBORD, Build the Entitlement Layer
The threshold is the number of door hardware platforms you run, not the number of students. On one access control platform with entitlements coming from a single system of record, buy Transact Campus, CBORD or Atrium as delivered and use the standard connector.
On this page
The threshold is the number of door hardware platforms you run, not the number of students. On one access control platform with entitlements coming from a single system of record, buy Transact Campus, CBORD or Atrium as delivered and use the standard connector. Once you run two or more head ends, or entitlements arrive from three or more authorities, build the layer above the card platform. In practice that lands near 8,000 students, and under about 3,000 it almost never does.
When is off the shelf genuinely the right call here?
Buy, and here is which one. A single campus under roughly 3,000 students, on one access control platform, with dining run in house and no off campus merchant programme, should run Transact Campus, CBORD or Atrium as delivered plus the standard connector to the access head end. A custom layer there would be an expensive answer to a problem you do not have.
Buy if your entitlements come from one system of record. The value of an entitlement service is reconciling several authorities against each other, and with one authority there is nothing to reconcile. Adding middleware would give you a second place for the same answer to live.
Keep the card platform whatever else you decide. Transact, CBORD and Atrium are strong where they were designed to be strong: card issuance, dining plan mathematics, declining balance accounts and the merchant estate. Replacing that is expensive and returns nothing, and rebuilding a stored value ledger to solve a door problem is the worst trade available.
There is a fourth case that is really a stop. If you have no internal owner for access policy, do not build. The system encodes decisions about who may open what and for how long, and those decisions belong to people. Without an owner, a custom layer accumulates the same manual overrides you have now, only faster.
When does a custom build actually pay off?
Build when nothing on campus can answer what a person may open right now. Five triggers, and two together is usually sufficient.
The first is more than one door hardware platform, which is the norm at any institution that has grown through renovation or acquisition. Lenel OnGuard, Software House C-CURE 9000 and Genetec Synergis each expose different interfaces and cardholder models, so the card system publishes into a black box and hopes.
The second is entitlements arriving from three or more authorities. Banner, Colleague or Workday Student knows enrolment. StarRez or Adirondack knows the housing assignment. A human resources (HR) system knows staff status. When reconciling those is somebody's job, the honest answer to any access question is whatever the most recently pushed file said.
The third is revocation you cannot measure. Battery powered wireless locks on residence hall doors hold a cached allow list and update when a technician walks the building or the lock next reaches a gateway. If you cannot state your revocation latency as a number, you are carrying a risk that will be quantified during an incident review rather than during a budget cycle.
The fourth is a stored value programme with third party merchants, where reconciliation crosses vendors. The fifth is launching mobile credentials when your identity assurance at provisioning is a portal password.
How do they compare on the things that matter in this industry?
Where the answer lives. This is the structural difference and it is worth stating plainly: the card is not the system. The entitlement decision is the system, and the card, the phone and the reader are how it gets expressed. Packaged platforms model a cardholder with a list of door groups, which is the access panel you already own. A build models one person, one credential set and computed grants, each carrying a source, a reason and an expiry, so a grant tied to a housing assignment dies on its own when the assignment ends.
Manual overrides get the same treatment. Every campus has groups added years ago by people who have left, and a build gives each an owner and a review date rather than letting them be inherited quietly.
Timing. Packaged integrations are nightly files by design, from an era when that was fine. A student who drops a laboratory course at two in the afternoon keeps after hours access to a room with compressed gas cylinders until the next morning. A build subscribes to change events where source systems emit them, polls tightly where they do not, and recomputes grants for one person, targeting a change visible at the reader inside a minute for online doors.
Offline locks. Neither route makes old hardware behave like new hardware. What a build adds is honesty: the lock estate modelled as assets with a last known sync time, a revocation completeness figure per building after each deactivation, and a technician walk list prioritised by the risk of the space.
Money. A stored value ledger with double entry semantics, idempotency keys so a replayed batch cannot double post, and refunds as entries rather than edits is what makes a disputed charge a query instead of an afternoon.
What does total cost of ownership look like at your scale?
This comparison is unusual because the build does not replace your card platform subscription. You keep paying it and add a layer above, so the honest question is whether the layer returns more than it costs.
Price three things you already spend. The connector modules your card vendor sells per access head end, multiplied across every platform you run and across five years. The reconciliation labour in the card office, meaning hours spent chasing why a student has access they should not or lacks access they should. And the temporary card and manual override workload, which grows quietly every year because overrides are added and never reviewed.
Then price the exposure you cannot currently measure, which is your revocation latency on residence hall doors.
On the build side, a first release covering the entitlement service, event driven synchronisation from registration and housing, near real time push to your primary access head end and a deactivation completeness view runs $90,000 to $180,000 over 14 to 20 weeks in Digital Heroes delivery experience. A full platform adding the stored value ledger, merchant and vending settlement, mobile credential provisioning, a student self service portal and a temporary card workflow runs $250,000 to $600,000 phased over 9 to 15 months.
A university of roughly 14,000 students with two head ends and wireless residence hall locks lands at about $150,000 for the first release. A second head end adds $15,000 to $30,000 once the entitlement service exists. Handling the offline lock estate properly is $12,000 to $25,000. Mobile credential handling is $25,000 to $60,000, and the identity assurance work around it is the real project rather than the credential itself.
Afterwards, hosting runs $400 to $1,200 a month and support and enhancement 15 to 20 percent of build cost a year, with a seasonal shape rather than a flat one. Add out of hours cover explicitly, because middleware that is down at eleven at night means students standing outside residence halls.
What does the hybrid look like, and when is it the honest answer?
Buy the platform, build the thin layer you actually need. On campus this is the recommended architecture rather than a compromise, and it is what almost every institution above the buy threshold should do.
The split is clean. Transact, CBORD or Atrium stays the system of record for card issuance, dining plans and declining balance accounts. Your access head ends stay the enforcement point at the door. You build the entitlement service between them: one person record, one credential set, grants with sources and expiries, event driven synchronisation from the authorities, and the deactivation completeness view.
Inside that there is a sequencing hybrid that saves real money. Build the entitlement service and integrate one access platform properly, then add the second as a defined follow on. The second is materially cheaper once the grant model exists, and doing both at once doubles the surface area you are debugging at go live.
There is also a scope hybrid. Defer stored value to phase two. The entitlement layer carries the security and service benefit, the ledger carries the finance benefit, and the ledger can wait a quarter. On payments, stay out of Payment Card Industry Data Security Standard scope deliberately by using a hosted payment page or a tokenising gateway so card numbers never reach your servers, and confirm your final position with your institution's payment compliance officer rather than with a developer.
One condition on all of it. Write the affiliate policies before you build them. Deciding who a visiting scholar is, and what their access lifecycle looks like, costs nothing in a meeting and a great deal after it is encoded.
Which should you choose, by operator size and stage?
Under 3,000 students, one access platform, dining in house. Buy Transact, CBORD or Atrium as delivered and use the standard connector. Spend the difference on readers.
3,000 to 8,000 students, one head end, entitlements from one or two systems. Stay bought, and do the free work. Document your grant sources, put an owner and a review date on every manual override, and measure how long a lost card stays live on residence hall doors. That measurement alone often changes the conversation.
Above 8,000 students with two or more head ends. This is the crossover. Build the entitlement service, event synchronisation and the primary head end push first, at $90,000 to $180,000, and schedule go live for a quiet period rather than move in week. The first week of term is the worst possible time to discover a grant rule nobody documented.
Multi campus, off campus merchant programme, or launching mobile credentials. Build the full platform and phase it deliberately. Plan for a parallel plastic and mobile period lasting years, which means every entitlement rule has to work identically for both throughout.
One last point that applies at every size. Door history is sensitive personal information about students and staff, subject to Family Educational Rights and Privacy Act obligations where it forms part of an education record. Decide who may query it and how long you keep it, because the default in most access platforms is to keep everything indefinitely.
If you want a second opinion before signing anything, Digital Heroes starts every engagement with a signed specification covering the data model, permissions and acceptance criteria, which is what keeps a fixed price fixed. Nothing about that commits you to the build.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- Only about 30% of digital transformations succeed at meeting their objectives, but getting six critical success factors in place (leadership commitment, talent, agile culture, progress monitoring, clear strategy, and a modernized platform) raises the odds of success from 30% to 80%. Source: Boston Consulting Group (BCG) (2020) →
- Companies in the top quartile of McKinsey's Developer Velocity Index had 2014-18 revenue growth four to five times faster than bottom-quartile peers, showing that software-building capability is a driver of business performance, not just a support function. Source: McKinsey & Company (2020) →
- McKinsey found that currently demonstrated technologies can fully automate about 42% of finance activities and mostly automate a further 19%, indicating roughly 60% of finance work is technically automatable. Source: McKinsey & Company (2018) →
- WordPress powers 41.5% of all websites and holds 59.2% of the market among sites running a known content management system, making it by far the most-used CMS on the web. Source: W3Techs (2026) →
Frequently asked questions
What does it cost to switch off Transact or CBORD?
In the recommended shape you do not switch. The entitlement layer sits above the card platform, which stays the system of record for issuance, dining plan mathematics and declining balance accounts, so the subscription continues.
What you can stop buying, over time, is the per head end connector modules the card vendor sells, since the entitlement service pushes to the access platforms directly. Price those across every platform you run and across five years before assuming the build has no offsetting saving.
What happens if our card vendor or access platform changes pricing or its interface?
Interface change is the recurring cost, not price. When your access control platform, student information system or identity provider is upgraded, connectors need retesting and sometimes rework, and that work should be scheduled alongside the upgrade rather than discovered after it.
The structural protection is that the entitlement service holds its own grant model. If a vendor changes commercial terms, you are negotiating about one component rather than about the architecture, which is the practical form bargaining power takes here.
How long does a campus card integration build take?
Fourteen to twenty weeks for a first release, with about three of those in discovery. Discovery has to put the registrar, housing, human resources, campus safety and the card office in the same room, because each owns part of the entitlement answer and none of them currently sees the whole picture.
Schedule go live for a quiet period rather than move in week, and expect the affiliate policy decisions rather than the engineering to set the pace.
Is CBORD enough for a university with two access control platforms?
For card issuance, dining and declining balance accounts, yes, and you should keep it. Where it stops is a boundary rather than a defect: it assumes its own ecosystem and treats the access control system as an export target rather than a peer.
Once you run two head ends plus wireless offline locks and an elevator controller, the card platform is publishing into a black box. At that point the entitlement decision needs to live above CBORD rather than inside it.
How much does a second access control head end add?
Roughly $15,000 to $30,000 once the entitlement service exists, which is exactly why sequencing matters. Building the grant model and integrating one platform properly first makes the second materially cheaper, whereas doing both at once doubles the surface area you are debugging at go live.
Ask any developer to name the specific products and interfaces they have worked with rather than accepting a general claim, because Lenel OnGuard, C-CURE 9000 and Genetec Synergis are three different problems.
Can we build only the deactivation and offline lock view?
Not really on its own, because a revocation completeness figure depends on the entitlement service knowing what was granted and by what authority. It is $12,000 to $25,000 as part of the first release rather than a standalone item.
What it buys is the answer you cannot give today: which doors a lost card would have opened between the moment it went missing and the moment it was flagged, and which buildings have caught up since. Any developer who tells you a revocation is instant has not worked with battery powered residence hall hardware.
Does taking card payments for account top ups change the decision?
It changes the architecture rather than the build or buy answer, and the objective is to stay out of Payment Card Industry Data Security Standard scope rather than to comply the hard way.
Use a hosted payment page or a tokenising gateway so primary account numbers never reach your servers, and let the stored value ledger hold tokens and transaction references. Building payment handling into your own infrastructure is the single fastest way to multiply the cost of this project, and it is avoidable.
What is the cheapest credible version of this system?
Around $90,000 for an institution with one head end, entitlements from two authorities and no stored value scope, covering the entitlement service, event driven synchronisation and near real time push.
Be sceptical of a cheaper quote from anyone who whiteboards a cardholder record with a list of door groups. That is the access panel you already own, and it misses the point, which is where grants come from and when they expire.
Can custom software connect to the tools we already use, like QuickBooks, Stripe, and Google Workspace?
Yes, and connecting your existing tools is one of the main reasons to build custom: mainstream platforms like QuickBooks, Stripe, Shopify, and Google Workspace all publish documented APIs. Budget 1 to 3 weeks of work per integration depending on API quality and how much data flows in both directions. Ask any vendor whether they have integrated with your specific tools before, because quirks like QuickBooks' OAuth token handling and API rate limits get learned on someone's project, and it should not be yours.
Can we migrate years of data out of our current system into new custom software?
Almost always yes, through CSV exports or the vendor's API, and migration should be scoped as its own workstream with field mapping, a dry run, and a planned cutover window rather than an afterthought. The real time sink is rarely moving the data; it is cleaning it, since years of duplicates, free-text fields, and inconsistent formats surface all at once. Pull a full export from your current vendor before committing to anything new, because some SaaS plans restrict exports on lower tiers.
How much should a small business budget for its first custom app or website?
For a focused first build, most small businesses land between $8,000 and $60,000: roughly $8,000 to $45,000 for a custom website and $25,000 to $60,000 for an internal tool or simple web app, based on Digital Heroes delivery across 2,000+ projects. Customer-facing products with payments, logins, or a mobile app start around $40,000. Quotes far below these bands usually mean a template with your logo on it, not software shaped around your workflow.
Is it cheaper to customize Salesforce than to build a custom CRM from scratch?
If you use less than a third of what Salesforce does, a custom CRM is often cheaper by year three. Salesforce Enterprise lists at $165 per user per month, so 25 seats cost about $49,500 a year before admin and consultant fees, while a focused custom CRM runs $60,000 to $100,000 once plus 15 to 20% a year in maintenance. If you genuinely need Salesforce's ecosystem, reporting, and app marketplace, customizing it beats rebuilding it; the mistake is paying enterprise prices to use it as a glorified contact list.
How small can the first version of my software be and still be worth building?
One workflow, end to end, for one type of user: the single process that currently burns the most hours or loses the most money. In Digital Heroes delivery experience, first versions scoped to 6 to 10 weeks of build time ship, get used, and generate the feedback that makes version two obviously right, while 9-month first versions routinely launch with features nobody touches. Everything you cut from v1 gets cheaper to build later, because real usage reorders the roadmap for you.
Should we build an MVP first or go straight to the full system?
MVP first, for almost everyone: ship the single workflow that carries the business value in 10 to 16 weeks, learn from real users, then fund phase two from evidence instead of guesses. The caveat is that an MVP is a small version of a well-built system, not a badly built version of a big one; the data model must already support what comes next. An agency that cannot tell you what they deliberately left out of your MVP has not designed one.
Does it matter which tech stack the agency wants to use?
Yes, but not in the way most buyers expect: the goal is boring, popular technology such as React, Node.js or Python, and PostgreSQL, because any future team can maintain it and hiring a replacement developer takes days, not months. The red flag is an agency-proprietary framework or an unusual language, which welds you to that one vendor no matter what your contract says about code ownership. A useful test: could you find three freelancers fluent in this stack within a week? If not, push back.
What is a discovery phase, and is it worth paying for separately?
Pay for it, and treat the output as yours. A discovery phase runs two to three weeks, typically 5 to 10% of the eventual build budget, and produces a written scope, wireframes, and a fixed quote you can take to any vendor, including a competitor of the agency that wrote it. Skipping it is how projects end up quoted from a two-paragraph email and delivered at twice the price.
How do I make sure custom software is secure and compliant with rules like HIPAA?
Start with the baseline every business system should have: encryption in transit and at rest, role-based access control, and audit logs. If HIPAA applies, the hosting provider must sign a Business Associate Agreement, which AWS, Azure, and Google Cloud all offer, and access controls have to be designed in from day one, not bolted on. SOC 2 certifies a company's operating practices, not a codebase, so ask vendors what they have shipped in your regulated domain rather than which logos are on their website.
Who can build a custom software system?
Digital Heroes builds custom software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
Published · Last updated .
