This post covers the practical setup: network, addresses, browser shortcuts, locking down shared devices and keeping them charged and accounted for.

Put the devices on the right network

A web app that lives on a computer in the shop is only reachable from the same local network. That makes the Wi-Fi layout the first decision.

• Staff network and guest network should be separate. Customers browsing while they wait should never share a network with the machine that holds your tickets. Most routers can broadcast a guest network that is isolated from local devices; turn it on and keep staff devices off it.
• Tablets go on the staff network only. If a tablet ever connects to the guest network by mistake, it will simply fail to load the app, which is confusing at the worst possible moment. Remove the guest network from the saved list on staff devices.
• Turn off VPN apps on shop tablets and phones. A VPN routes traffic away from the local network, and the app will appear to be down.

Give the server a stable address

Bookmarks break when the address changes. On most home and small-business routers, a DHCP reservation pins a fixed local IP to the computer that hosts the app. Do it once, write the address on a label inside a drawer, and every device keeps working after a power cut or router restart.

If your app offers a secure https address, prefer that for bookmarks: the browser shows a padlock and stops warning staff about an insecure connection.

Make it feel like an app

Nobody wants to type an IP address on a tablet keyboard. Two minutes per device fixes that:

1. Open the address once in the browser.
2. Use Add to Home Screen (iOS Safari share menu, or the Android browser menu).
3. Name the icon something obvious, such as "Repairs".
4. Remove other clutter from the first home screen so the shortcut is the only thing a new hire sees.

Most mobile browsers will open a home-screen shortcut without the address bar, which gives you more room for the ticket screen.

One person, one login

The convenience of a shared tablet tempts people to stay signed in as one user all day. Resist it. When every action on the bench tablet is logged as the owner, change logs stop being useful and anyone walking past can reach sensitive settings.

• Give each staff member their own account, with the lowest role that fits their job.
• On a shared device, sign out at the end of a shift. On a personal phone, the tech can stay signed in, but the phone itself must have a screen lock.
• Set a short auto-lock on tablets (a minute or two) so an unattended screen does not stay open on the counter.

Lock shared tablets to one task

Both major mobile platforms can pin a single app to the screen: Guided Access on iPad and screen pinning on Android. Pinning the browser keeps customers and curious hands from wandering into settings, photos or email. Combine it with a passcode on the device itself so the pin cannot be lifted without staff help.

Physical care

• Cases and stands. A rugged case and a stand at a consistent height make the bench tablet usable with dirty or gloved hands.
• Charging stations. Give each shop device a fixed charging spot and check it at closing. A dead tablet at opening time wastes the first ten minutes of the day.
• Inventory the devices. Keep a short list of which tablets and phones are shop property, their passcodes in a sealed record, and who has them.

Know the limits

A local app on the shop network is not meant to be opened from home or from a café. That is a security feature, not a gap. If someone needs to check a ticket from outside, they do it when they are back on site.

Where this fits

This setup is how RepairAmigo is designed to be used: it runs on your computer in the shop, and every desktop, tablet and phone connected to the shop's network can load it in a browser tab. The phone view enforces the same prices, rules and checks as at the counter, which lets a tech change a ticket or do a stock count without leaving the bench, and after setup you can bookmark a secure https address or add it to a home screen. The Owner adds Managers and Technicians, each with their own login.

— RepairAmigo Team

The shape of the deployment

The app ships as a single appliance file (.ova). You import it into VirtualBox with File → Import Appliance, press Start, and the guest boots to a splash screen that prints its IP address. Type that address (something like http://192.168.1.50/) into a browser on a counter PC, tablet or phone, and the first visit runs Setup: shop name, time zone and an Owner account.

Sizing is modest but fixed. The guest gets 2 CPUs and 4096 MB of RAM, and the host should be a 64-bit Intel or AMD machine with roughly 8 GB of memory and four logical cores. Shrinking the guest's memory is discouraged.

Networking: bridged, not NAT

VirtualBox defaults to NAT, which hides the guest behind the host, so nothing else in the shop can reach it. This appliance uses a bridged adapter instead: the guest gets its own address on the LAN, like one more computer plugged into the switch.

What follows from that:

• If the host has several network cards, pick the right one under Settings → Network → Name. A "Physical network interface not found" error usually means the adapter points at a card that is gone.
• Some guest or mesh Wi-Fi setups block bridged traffic. A network cable on the host avoids the problem.
• DHCP may hand the guest a new address after a reboot. A DHCP reservation on the router keeps everyone's bookmarks valid.
• Shortly after its initial boot, the guest also prints an https:// address that browsers trust without warnings. The bare IP still works.

A small attack surface on purpose

Living on the LAN only helps if the guest is locked down too:

• No port is opened on the router, and the guest does not use UPnP to open one, so internet scanners never see it.
• The guest firewall admits two services, only from the local network: the web app on port 80 and SSH on port 22.
• SSH is key-only; neither root nor password authentication is accepted.
• The database socket is bound inside the guest and never exposed.
• Outbound, the guest makes an HTTPS check-in every five minutes; the responses carry signatures, and customer data is not part of that traffic.
• Remote support is disabled by default. An Owner or Manager can grant a 24- or 48-hour window.

Most malware that reaches small shops is written for Windows. The appliance is a locked-down Linux system, so a Windows .exe or an Office macro cannot execute inside it, even if the host PC gets infected.

Keeping it running without babysitting

Two host-side details matter day to day:

• Headless start. Launched headless, the guest keeps running after you close the VirtualBox Manager. The host must stay on and awake, so disable sleep.
• Hypervisor conflicts. If a Windows host shows a small green turtle in the guest window, VirtualBox is running on top of Hyper-V and paying for it. Switching off Hyper-V together with the Virtual Machine Platform feature usually restores full speed. If the guest refuses to boot with a VT-x or AMD-V message, enable virtualization in the BIOS.

Backups: copy the whole machine

Every ticket, price list, inventory count and user account lives inside the guest, so the unit of backup is the VM itself. According to the docs, a copy of the whole guest can be started on a different computer the same way the original was set up.

In plain VirtualBox terms, shut the guest down cleanly, then either export it to a fresh .ova with File → Export Appliance or copy its folder (the .vbox file plus its virtual disk). Keep the copy on another drive, not on the host, and lock that drive away, because it holds customer data. Habits that make the copy worth having:

• Put the host on a UPS so a power cut never lands mid-write.
• Watch the drive's SMART status and replace a disk that starts reporting errors.
• Remember that deleting the VM in VirtualBox deletes the data inside it.

Moving between app versions is a separate job from moving between computers. A Migration Package carries the data into a fresh install, and a one-time transfer code carries the paid status.

Where this pattern fits

A local VM won't stop someone carrying the computer out the door, and it is meant for the shop network, not remote use. For a counter that wants fast, predictable software and its records on its own hardware, though, it is a tidy architecture: one file to install, one address to bookmark, one object to back up.

The example app in this post is RepairAmigo, which handles tickets, inventory and the counter for shops that fix phones, computers and consoles. It runs on your computer (Windows PCs and Intel Macs) inside VirtualBox, with a 30-day free trial, then an optional one-time $99 paid version with no subscription.

Before you plug anything in

Look the console over with the customer watching:

• Outer shell. Note cracks, scratches, missing feet, stickers and broken clips.
• Screws and seals. Stripped screws or a torn warranty sticker mean someone has been inside before. Write it down.
• Ports. Check HDMI, USB and power ports for bent pins or debris with a flashlight.
• Smell and sound when shaken gently. A burnt smell or something rattling inside is worth noting before you power it on.

Take photos of all sides. They take seconds and settle most "that scratch wasn't there" conversations.

Power-on tests

If the console turns on, run through a short list in front of the customer:

1. Does it power on and stay on for at least a couple of minutes?
2. Is there picture and sound through your test monitor?
3. Do the fans spin up, and are they unusually loud?
4. Does a controller pair and respond?
5. Does the disc drive accept, read and eject a test disc, if the model has one?
6. Does it reach the home screen, and does it connect to Wi-Fi?

Record each result as pass, fail or not tested. "Not tested" is a valid answer and much better than a blank.

If the console doesn't power on, write exactly that, along with which power cable you used. Don't promise anything about the other functions; they're simply unknown.

Accessories and accounts

List every item the customer leaves: controllers, cables, discs, stands, memory cards. Ask them to take home anything that isn't needed for the repair. Fewer accessories on the shelf means fewer missing-item claims.

Ask the customer to sign out of accounts or remove parental-control PINs if testing after the repair will need them. Never ask for their account password.

Talk about data and firmware

Some repairs, such as storage replacement, can wipe saved games. Say so before the work starts and suggest a cloud backup if the console supports it. Note on the ticket that the customer was told.

Set a clear expectation

Before the customer leaves, read back three things: the problem being repaired, the results of your check-in tests, and when you'll be in touch. Have them sign the receipt. Then put a barcode or ticket label on the console itself, not just on the box or bag it came in.

A quick checklist to print

• Visual condition noted and photographed
• Power, picture, sound, fans, controller, disc drive and network tested
• Accessories listed
• Data risk explained
• Customer signature on the receipt
• Label on the device

How RepairAmigo handles intake

RepairAmigo was built for phone, computer and console repair. Intake uses pickers for the device, brand and model, with a problem list for each device type, and returning customers are found by their phone number. It prints a receipt with a barcode, and the trip from intake to a printed receipt takes three clicks. Technicians add comments to the ticket as they work. It runs on your computer (Windows PCs and Intel Macs), with a 30-day free trial, then an optional one-time $99 paid version with no subscription.

— RepairAmigo Team