Conçu par Mr Digital

I started Mr Digital in 2016 because I'd just spent years on the operator side of hospitality (running sales and digital marketing for Fuller's Inns with Rooms), and I'd seen too clearly how broken the technology serving multi-site groups actually was.

The agency was supposed to be a temporary thing. A way to use what I'd learned, work with operators I respected, build websites and run paid media campaigns and help groups get more bookings. I didn't set out to build a platform. I set out to be useful.

Since 2016, Mr Digital, the agency behind mDOS, has worked with businesses with a combined turnover of more than £300M. Nine years, 74 RedCat venues and a Coaching Inn Group rollout later, I built mDOS because I'd run out of patience with the alternative.

What we kept rebuilding

The pattern was the same with almost every group we worked with. They'd come to us because their digital felt fragmented. The website was on WordPress, the booking widget was OpenTable or Design My Night, the email was Mailchimp, the EPOS was Zonal or Toast, the loyalty programme was Como or Punchh, the reservations were a separate platform, the WiFi captive portal was Beambox.

Each tool was a competent product. Each had been bought separately, by a different person, in a different year, for a different reason. None of them talked to each other in any meaningful way.

We'd spend the first six months of any engagement doing what I came to call "stack archaeology": mapping which guest data lived in which system, where the customer record was duplicated, which integrations were silently broken, which marketing automations were firing on stale data. We'd build the website, we'd run the paid media, we'd improve the booking conversion. But underneath all of it, the integrations kept breaking, the customer records kept fragmenting, and the operational reality of the group kept being slightly out-of-sync with whatever we were doing on the marketing side.

We got good at this. We launched 74 RedCat websites in nine months. We integrated booking platforms with email marketing for the Coaching Inn Group. We built bespoke Performance Tracker dashboards because the off-the-shelf reporting tools didn't give operators what they actually needed.

But every single project, we were patching over the same underlying problem: the data model was wrong. Twelve to twenty vendors, twelve to twenty customer records, twelve to twenty integration points to maintain. Every group we worked with was paying for the same architectural mistake.

The moment we decided to build it ourselves

There wasn't a single moment. There was a slow accumulation.

There was the 50-venue group whose loyalty integration to their POS broke for six weeks before anyone noticed: six weeks of customers earning no points, complaining to staff, getting compensated with vouchers, eroding trust in the programme. The vendor's response: "the integration is third-party, you'll need to contact the integration provider." The integration provider's response: "the POS API changed, we're working on an update." Nobody was responsible. The operator paid for it.

There was the F&B Director who took three weeks to roll out a "2-for-1 Sunday lunch" promotion across her estate because the price update required individual changes at each EPOS terminal, the website CMS update was a separate ticket, and the email campaign needed manual segmentation against an outdated CRM extract. She told me afterwards: "I used to be able to do this from the back of a napkin in 1998. The technology was supposed to make this easier."

There was the loyalty platform sales call where the vendor proudly demonstrated their integration capabilities: "we work with Toast, Zonal, Lightspeed, all the major POS systems." When pressed on the technical detail, the integration turned out to be a nightly batch sync. The customer's points balance would be 24 hours out-of-date in their app. The vendor genuinely didn't understand why this was a problem.

There was every single procurement evaluation where operators would ask "does it integrate with X?" and the answer would be "yes" in the sense that there was a webhook somewhere, and "no" in the sense that the integration would silently degrade within six months and require ongoing maintenance budget that nobody had quoted for.

I went home from these meetings and started sketching what the platform would look like if you started over. If you treated the customer record as the canonical row. If you put the marketing engine inside the same database as the POS. If you made the menu, the website, and the till the same system. If you eliminated integrations not by integrating better but by removing the need for them entirely.

The sketches turned into specifications. The specifications turned into Postgres schemas. The schemas turned into a working prototype, then a working alpha, then (over the past two years) a production platform. With 50+ features across 36 modules and 1,400+ database tables, that platform is now what mDOS is.

What mDOS is, and what it isn't

mDOS is the platform I wish had existed when I was at Fuller's. It's what 74 RedCat website launches taught me a unified hospitality OS would need to look like. It's the architecture conclusion of nine years of agency work watching the same problems play out across dozens of multi-site groups.

It's not a Toast competitor or a Mews competitor or a Klaviyo competitor. Those vendors are competent at what they do. The reason mDOS exists isn't that any of them are bad. It's that running all of them together is bad, structurally, in ways that integrations can't fix.

mDOS replaces the system of systems. The dozen vendors with the dozen customer records and the dozen integration points become one platform with one customer record and zero integration points between modules. The marketing team's flows trigger off operational events directly. The loyalty points commit atomically inside the POS transaction. The menu changes propagate to all terminals in 200 milliseconds. The CFO's executive dashboard runs a query against the same database the floor manager just took an order into.

This isn't a feature list. It's an architectural argument that has been validated repeatedly across nine years of operator pain.

Why we built it as Mr Digital, and why that matters

We could have spun out a separate company. Raised funding. Hired engineers. Built mDOS in stealth as a venture-backed startup with a CEO and a board and a 5-year roadmap.

We didn't, for a specific reason: I wanted the platform to be built by people who answer the phone when an operator has a problem at 11pm on a Saturday. The agency model means my team and I are still in the trenches doing client work. We see the operational realities every day. We see what's broken. We hear about what's frustrating. We build the platform against that lived experience, not against a deck of customer-research interviews.

Mr Digital exists because hospitality groups need a digital agency that understands them. mDOS exists because that agency, after nine years, has the architecture conviction and the engineering capability to fix the underlying problem rather than just patch the surface.

Same people. Same building. Same standards. Different products serving different audiences: the agency serves operators who need delivery; the platform serves operators who need infrastructure.

What happens next

We're approaching a small number of enterprise hospitality groups about becoming Founding Member customers of mDOS, capped at three to five for the first cohort. Each gets multi-year preferential pricing, direct founder access, co-designed roadmap input, and a bespoke website for every venue in their estate (which is the kind of offer only an agency-owned platform would think to make).

We're also having early conversations with corporate development teams at strategic acquirers: operators with the scale to absorb mDOS as captive infrastructure, and consolidators with the customer book to commercialise it more broadly.

Both conversations are open. Both pathways are credible. The platform is built; the credentials are real; the architecture has been validated in production. The question now is whether we end up as the infrastructure inside one major operator, or the consolidation platform inside a larger SaaS portfolio.

Either way, the thing I'm proudest of is that what we've built actually solves the problem that nine years of agency work taught us was worth solving. The Frankenstack doesn't have to be the answer. There's a better way to do this, and now there's a platform that proves it.

---

If you're a multi-site operator who recognises any of the pain I've described, book a confidential call. We'll walk you through what your estate would actually look like running on one system.

If you're a corporate development team evaluating mDOS as IP, that conversation starts directly with me, not a sales process: ross@mr-digital.co.uk.

Ross Crawford, Founder, Mr Digital Ltd