Square handles the queue on King's Parade until a college charges it to a student account

An account charging and booking layer on top of your existing till runs £16,000 to £38,000. A full custom POS with pricing rules and account ledgers is £40,000 to £80,000. Multi-site platforms with agency billing reach £140,000. Payment integration and PCI scope are the biggest single drivers.

Yes, and this is the most common reason Cambridge college bars and butteries move off Square. The system needs a member ledger, credit limits, statement generation and a settlement process, none of which standard terminals provide. Done properly it also removes the weekly paper tab reconciliation that currently occupies someone's Friday.

Potentially, because you can negotiate directly with an acquirer rather than accepting a bundled rate. Square publishes 1.75 percent for UK in-person card payments, which is competitive for low volume and expensive at scale. Run the arithmetic on your actual annual card turnover before deciding, since below a certain volume the saving will not fund a build.

Two things: date-driven pricing so peak rates apply automatically, and an interface fast enough that a queue moves. We design the common transaction to be two or three taps and test it against a simulated rush before launch. Seasonal staffing is the other half, which is why training time is an explicit design constraint rather than a manual.

The terminal keeps trading. Transactions are stored locally with the payment captured against the processor's offline rules, then reconciled when connectivity returns. Any system that simply stops when the connection does is unusable at an outdoor Cambridge pitch, and you should test this specifically during the sales process.

Yes. The design pattern is a single payable account with per-person or per-item detail behind it, so the agency receives one invoice and you can answer a query about a specific student's consumption. Cambridge summer language schools generate exactly this pattern every year, and it is invisible to standard hospitality tills.

Different rates apply across your lines, and getting it wrong compounds quietly across a season. Build rate handling per product with correct treatment for mixed transactions, and make the export to your accounting system Making Tax Digital compatible so VAT returns are generated rather than assembled.

In your quietest weeks, with the old system available for a fortnight. Launching a till during May Week or graduation is how a good build becomes a disaster story. For most Cambridge operators that means a January or February go-live, which also means starting the project in the previous autumn.

Whoever you contracted to, so contract for it explicitly. Hospitality support needs evening and weekend coverage with a defined response time, plus a documented fallback your duty manager can execute alone. Ask any prospective partner what their Saturday coverage costs before you sign, because retrofitting it later is expensive.

The software can be built entirely remotely, but plan for on-site time at two points: hardware installation and go-live week, when printers, cash drawers, and network fallback get tested inside your actual Cambridge location. Digital Heroes runs this as a remote build with scheduled on-site launch support, which costs far less than paying local development rates for the whole project. A pre-configured hardware kit with a guided video install works for a single counter, but multi-terminal sites deserve a physical visit.

Yes, and integrations are often the strongest reason to go custom, since you control the sync logic instead of waiting on an app marketplace. QuickBooks and Xero have stable public APIs, and a daily sales journal sync is a 1 to 2 week build item in most Digital Heroes POS projects; loyalty and online ordering connections typically run 2 to 4 weeks each depending on the vendor's API. List every integration in the initial scope, because each one added mid-project reopens the data model.

Yes. Square and Lightspeed both provide exports and APIs covering transactions, catalog, customers, and inventory, and migrating them is a standard 2 to 4 week workstream inside a POS build. The usual gaps are stored card tokens, which cannot leave the original processor without a formal token migration request, and gift card balances, which need careful reconciliation. Plan to run both systems in parallel for one or two weeks during cutover.

A POS build needs backend, client app, payments integration, and hardware testing skills running at the same time, which is more surface area than one freelancer reliably covers. Freelancers make sense for narrow additions, like a reporting module on an existing system, at typical rates of $30 to $90 per hour. For a ground-up build, an agency with a dedicated QA function is the safer choice because a register failure stops your revenue at the counter in real time.

A one-page brief beats a 40-page requirements document: the business problem in plain words, who will use the system, the 5 to 10 workflows it must handle, the tools it must connect to, and your budget range and deadline driver. You do not need wireframes, a specification, or technical vocabulary; producing those is the agency's job during discovery. Stating a budget range up front is the single best move, because it gets you honest scoping instead of a quote engineered to win the meeting.

Because an accurate quote requires real work: mapping your workflows, finding the edge cases, and writing a specification, which typically takes 1 to 3 weeks and costs $2,000 to $10,000 at Digital Heroes depending on system complexity. You leave discovery owning a written spec and a fixed price you can take to any vendor, so the money is not locked into one agency. Free estimates are guesses, and the guess usually becomes your budget overrun six months later.

Ask to see a live POS or payments product they built, then ask exactly how they handled offline mode, receipt printing, and PCI scope, because those three areas expose anyone who has only built ordinary web apps. A competent agency will name the payment SDKs they used, such as Stripe Terminal or Adyen, and describe their terminal certification process without checking notes. If the portfolio is all marketing sites and dashboards, keep looking.

The crossover usually shows up between 20 and 50 seats on premium tiers. Salesforce Enterprise lists at $165 per user per month, so 40 users cost about $79,000 a year in subscriptions, which is real money against a custom system you would own outright. Run the comparison over three years: if subscription spend beats the build cost plus 15-20% annual maintenance, custom wins on price before you even count workflow fit.

No, most software projects run fully remote without any quality penalty, and what actually matters is 3 to 4 hours of working-hour overlap and a fixed weekly demo call. A team based in Cambridge earns its premium in specific cases: hardware installations, warehouse or clinic floor shadowing, and discovery workshops where watching your staff work beats any written brief. Choose for senior engineers and a track record first, and treat geography as a tiebreaker.

Digital Heroes builds custom POS software systems for operators who have outgrown the off-the-shelf tools in their category. The work is delivered remotely: our engineers work from Delhi and Lucknow, leadership is in New York, and some team members live in London and Sydney and work remotely from there. We have no office in Cambridge. You can chat with the team directly, and every form gets an email reply within 24 hours.