Coworking Space Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a coworking build turn into rebuilding the platform you already pay for?

Because the specification gets written as a comparison. Somebody opens Nexudus or OfficeRnD, lists every screen, and hands it to a developer. Community feed, events module, marketing site builder, visitor kiosk, newsletter tool. None of those are why you are spending money, and each is months of work a funded product company already did.

The reason you are considering a build is narrower than the platform, and you can usually state it in three sentences. Your enterprise contracts do not fit the plan model, so they are billed by hand. Your doors and your memberships disagree. Your meeting rooms are booked far more than they are used and nothing releases them. Everything else the incumbent does is adequate.

The build that succeeds is the one that owns the canonical member and entitlement record, the resource inventory, the rating engine and the access decision, and leaves the rest alone or reads it from where it already lives. A focused first release along those lines runs $60,000 to $130,000 and ships in twelve to sixteen weeks. A specification that reproduces a mature platform runs past a year, and you keep paying the incumbent subscription for every month of it, because you cannot switch off a system you have not finished replacing.

The practical test when reviewing a scope document: for every feature listed, ask what it costs you today in money or hours, and cut it if the honest answer is nothing.

What goes wrong when you migrate members, invoices and credit balances?

The member list exports cleanly, which is what fools people. The money does not.

Historical invoices carry part period proration calculated by the old system's rules, and reproducing those rules exactly is not always possible, so a reissued or credited invoice in the new system will not match the original. Outstanding credit balances sit in places that are easy to miss: unused day pass bundles, meeting room hour pools with their own expiry, deposits held against contracts, and goodwill credits somebody issued by hand. Members who upgraded mid cycle carry proration in both directions. And any member on a payment method tokenised inside the old platform's processor account may not transfer without re authorisation, which means asking hundreds of people to enter card details again, in the same month you also changed their door credential.

Treat migration as its own phase, budgeted at three to five weeks for a multi site operator, with reconciliation to the penny as the acceptance test. Run both systems in parallel for one full billing cycle and compare every invoice line before cutting over, not a sample. Agree in advance what happens when the two disagree, because they will, and the decision of whether to honour the old figure or the new one is a commercial one rather than a technical one.

Have a rollback plan for the first live billing run and say out loud what triggers it, because an operator who discovers on the third that four hundred invoices are wrong needs a decision path that already exists.

Why do door, payment and accounting integrations break after launch?

Because they are usually wired with a no code hop that fires a webhook and hopes.

That is fine for one site and a hundred members. At nine hundred members across five sites it fails in ways you cannot audit. There are no retry semantics you can reason about when the access interface is unavailable for forty seconds, no record your insurer will accept, and no way to answer who had physical access to the third floor between seven and ten on the fourteenth, because the only evidence lives in a vendor's log with no link to membership state.

Integrate at the interface level with Kisi, Brivo or Openpath directly, and use an outbox pattern so a provisioning instruction is retried until it lands and is never silently lost. Derive access from entitlement state rather than syncing two lists, so a subscription going past due at day fourteen downgrades access to business hours automatically and a terminated contract revokes credentials in the same second, with the event logged.

Then run a nightly reconciliation reporting drift in both directions: every credential with no matching active entitlement, and every active member with no working credential. The second half matters more than operators expect, because a paid member who cannot get through the door on their first morning is a churn event nobody finds until they complain.

Accounting is the quieter one. Multi entity and multi currency billing roughly doubles the billing scope the moment you cross a border, because tax treatment differs per entity and a build scoped for one entity does not extend to three by configuration.

What happens when enterprise contract terms are not covered?

They move into a PDF, then into somebody's head, then that person leaves.

The revenue you want is the twenty desk, twenty four month deal. The data model you have is plan per member with a monthly price. So a contract with a three month ramp from eight desks to twenty, two free room hours per desk per month pooling across the team and rolling over one month, a four percent annual uplift, a forty five day break clause and a five desk flex allowance has left the software behind before it is signed. Every nuance becomes a manual credit note, and when the account manager renegotiates in month fourteen, nobody can reconstruct what was agreed versus what was billed.

Model the contract as a first class object: a versioned agreement with dated line items, entitlement pools with their own expiry and rollover rules, ramp schedules, uplift triggers and notice terms. Billing becomes a rating engine that reads the contract rather than a person reading a PDF, and every invoice line carries a traceable link back to the clause that produced it, so a procurement query is answered in thirty seconds rather than three days.

The related gap is the room. Off the shelf tools model a meeting room as a calendar entry with a price, so a four hour booking used for forty minutes counts as fully utilised, and you turn away paid guest bookings for an empty room. Model rooms as inventory with a state machine, take an occupancy signal from a low cost sensor or the door events you already have, and auto release on no presence after a short window with a notification and a partial credit. Operators recover meaningful sellable room hours from release alone, before any pricing change.

Should you build custom or configure what you already own?

Stay on Nexudus, OfficeRnD or Cobot if you are under roughly four locations and four hundred members. At that scale the manual work is about four hours a month, not three days, and spending six figures to remove four hours a month is a bad trade against putting the same money into sales. We would say that to an operator on a first call and have.

Stay on the incumbent too if your membership model is homogeneous: everyone on the same handful of plans, no enterprise contracts, one access control vendor. The platforms handle that case well and the cost difference is an order of magnitude.

Before building, exhaust configuration. Most operators have not tested whether the incumbent can express their contracts using custom plans, add ons and credit products, and a firm conversation with the vendor about a specific billing case is cheaper than a discovery phase.

Build when the signals appear together. Your finance lead loses more than two days a month to adjustments. More than a quarter of revenue comes from contracts the plan model cannot express. You run more than one access vendor across sites, or are about to inherit one through an acquisition. You have already paid for two custom add ons on top of the platform and still do not have what you need. Or the clearest signal of all: your sales lead says you cannot do a ramped contract because the system cannot bill it. At that point the software is choosing your deals.

How do hidden costs get into the quote?

• Hardware. Every access control vendor has its own behaviour, and mobile credentials over Bluetooth or near field communication add device certification work a pure web build never touches.
• Multi entity and multi currency billing. Roughly doubles billing scope because tax treatment differs per entity, and it arrives the moment you cross a border or open under a second company.
• Migration reconciliation. Three to five weeks on its own for a multi site operator, and almost never in a quote that describes it as an import.
• Concurrency. If availability feeds a public marketplace or broker feed it must be correct under load, meaning real locking and load testing rather than an optimistic read.
• Data retention. Access logs and visitor records are personal data, so a defined purpose, retention period and deletion path are build work.
• Maintenance. Budget for keeping the door, payment and accounting connections working, because an integration heavy system nobody maintains degrades within a year.

What separates a build that works from one that fails here?

One canonical member record with an entitlement state, and everything else a projection of it. If access, billing and booking each hold their own view of membership, you have rebuilt the problem you paid to remove.

A rating engine that reads a structured contract. Ask a prospective developer to model an enterprise contract on a whiteboard, live. If a member gets a plan identifier as a foreign key, your budget is funding their education. The shape you want is organisation, contract, contract version, entitlement pool, member and invoice line.

Reconciliation as a feature rather than an afterthought. Nightly drift reports on credentials, a daily payment reconciliation, and an exception queue somebody owns. These are unglamorous and they are what stop the leakage that motivated the project.

Named production experience with your access vendors. Ask which interfaces they have shipped against and what broke, and expect specifics about group provisioning limits, token expiry behaviour and what happens to a mobile credential when a phone goes offline. Enthusiasm about integrations means they have read the documentation.

And ownership in writing before kickoff: the repository in your organisation from the first commit, your own payment and cloud accounts, and no runtime licence on anything written for you. A vendor who is precious about the source is planning to rent you the operating system of your own building.