Software that runs the store when you are not in it.

Laundromat management software runs a self-service laundry store from one place. It connects washers and dryers, takes card and app payments, watches machine health, and reports revenue per machine and per store. It is different from dry cleaning software, which tracks individual garments through intake, cleaning, assembly, and delivery. A laundromat system tracks machines, cycles, payments, and faults, because the customer serves themselves.

Buy a maintained product when it connects your machines and payment readers cleanly and its pricing makes sense for your store count. Cents, for example, says more than 5,000 stores use its platform, and its machine layer reports real-time performance and usage. Build custom when your machine mix, pricing rules, or multi-store reporting do not fit any maintained product, or when you need one system across machines and payment readers from different vendors. If the rules of the operation are still changing every week, wait and settle them first.

Every payment has to land in the same record as the machine cycle it paid for. Card and app systems give digital reports that are hard to fudge, which is why owners who buy a store often check them first. For cash, use a consistent collection schedule and method, and reconcile collections against machine cycles and utility bills, which are a good check on real usage. The test to ask for in any demo: show one day where cash, card, and app revenue reconcile against cycles per machine, with the gap named, not hidden.

Yes, with the right systems in place: card or app payments so no coins or cash sit on site, remote machine monitoring that reports faults and usage, cameras with alerts for unusual activity, and locks that open and close on a schedule. The software has to tell you a machine is down before a customer does, and it has to keep taking payments when the connection drops. Unattended does not mean unmonitored: someone still needs the alert, the repair list, and a way to refund a customer whose cycle failed.

The system should report cycles and revenue per machine, per day and per hour, so you can see the mix clearly: the large washers that earn on weekends, the dryers that sit idle on weekday mornings, the machine that runs half as often as its neighbour. That record is what justifies replacing a machine, changing its price, or moving it. A demo should show this per-machine view on your own store layout, not a generic dashboard.

The software cannot set your service schedule, but it should keep a repair and service record per machine so patterns show up: dryer heating elements and motors, washer drain pumps, belts, water valves, and control boards are the common failures owners report. Log every service visit and fault against the machine, and the record tells you which machine keeps breaking, when a repair costs more than a replacement, and what to show an insurer. A machine with no service history is a guess; a machine with a record is a decision.

Card and app payments give you three things coins cannot: a digital revenue record, price changes in small steps instead of large coin jumps, and customers who do not need to carry coins. Owners report that small incremental increases, in steps of ten or twenty-five cents, are easier for customers to accept than the fifty-cent or one-dollar jumps coin machines force. The cost side is real: readers, hardware, and card processing fees, plus what happens when a reader fails. Ask any vendor for the full cost, including hardware and processing, before you compare it with coins.

Raise prices in small steps, one machine type at a time, and watch cycles per machine before and after. Card and app payments make small steps possible; coin machines force large jumps. Tell regulars what changed and why, keep the change visible on the machine, and refund a failed cycle without argument. If cycles drop on one machine type but not the others, the price moved too far on that type, not on the store.

Three things have to work: the machine reports the fault to you, the customer gets a clear message on the machine or in the app, and the refund or re-run is handled without a visit. The system should log the fault against that machine with a time stamp, so the repair visit starts with the symptom, not a guess. Ask in the demo: show me a failed cycle from fault to refund, with the record the attendant sees the next morning.

The first paid phase may cover a bounded audit, a proof of concept, a recovery plan, or a small first release. The final price depends on how many machines and stores it covers, which payment readers and machine controllers it must connect to, whether data needs moving over, whether phones or tablets are involved, and the condition of existing code. The agreed phase is priced in writing before it starts. For maintained products, most vendors keep pricing behind a sales conversation or tiered quote, so budget from a demo, not a headline number.

Only when the machine controller, pay station, reader, or vendor exposes a documented and permitted interface. We confirm protocols, credentials, commands, safety states, warranty and vendor constraints, test equipment, and failure behaviour before committing to a connection. An unavailable or restricted interface can change the product boundary. CleanCloud, for example, connects with card systems such as LaundryCard, FasCard, SpyderWash, and Tangerpay, while Cents runs its own payment hardware. Which readers and controllers you already own decides what is possible.

Define one authoritative record for each store, machine, price, promotion, attendant, and refund rule. Each store reports cycles and revenue in the same shape, so a slow store and a busy store can be compared honestly. Price changes, promotions, and refunds follow the same rules everywhere, with a named override when one store genuinely differs. Duplicates, failed payments, and disputed cycles enter a staff review path with reason and a record.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the workflow agreed at the start: pay for a cycle, watch it report, break a machine on purpose, check the alert and the refund. Progress is reported in plain language: what changed, what's next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your business.

You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

Every launch includes post-launch warranty cover for defects in the agreed scope, release support, and small screen corrections. After that, work can continue as another fixed phase or an ongoing product engagement. The code and accounts stay under your control either way.

For a small, well-defined task with someone technical managing it, freelancers are often cheaper. The pattern that goes wrong is a non-technical buyer coordinating several freelancers becoming the project manager, the tester, and the person who discovers the pieces don't fit. A custom software development company earns its fee when the work needs coordination across screens, rules, data, and connections: one accountable party, one phase price, and checkpoints against the whole workflow. If your need is one screen or one fix, hire the freelancer.