The questions people actually ask.

Any business that runs on people moving information from one system to another. Orders retyped from email into the system that ships them, quotes built by hand from old jobs, schedules kept by phone and spreadsheet, paperwork chased from desk to desk. We start with one of those jobs, done properly, inside the systems you already run.

No. Transport is where the founder’s own operations are, which is why some examples on this site come from it. It is where we started, and it sets no limit on who we work with. The work itself is the same in any business: orders, quotes, scheduling and paperwork moved by hand between systems. We start with one job and build from there.

If work is keyed twice or jobs slip through follow-up, you are large enough for an Operations Diagnostic. It is deliberately small so this question can be answered with evidence instead of a guess.

No, and it is fine if you have never used it. Most of what we fix is process before it is technology. Where AI helps, we bring it; where a simpler change would do the same job, we say so.

We do the work. There is no MexaBuild licence to buy. We build systems inside your business, using tools you own, and we run them with you. When an engagement ends, what we built stays yours.

Yes. The person who builds it comes to your floor and works inside your operation, on your real day, instead of taking requirements from a distance and handing back software. We sit with every process owner during the Diagnostic, connect to the systems you already run, and stay to run what we built.

Both. The strategy is the Operations Diagnostic: every system and process mapped, the exceptions ranked by what they cost, and a plan for what to fix first, written so you can act on it with or without us. A build follows only if the numbers say it earns its keep.

It can, when it is built to look up the answer in your own documents first and answer only from what it found, with the source attached. You need it when the answers already exist in manuals, rate cards, contracts or past jobs and people keep asking the same two colleagues. If your problem is missed calls or slow follow-up, you do not, and we will say so.

The Operations Diagnostic: about two weeks, paid in full, upfront. It maps every system, process and procedure in the business, and ends in a signed baseline, a demo on your own data and a ranked plan. You keep all of it, so you can judge the quality of the thinking before committing to a build.

The Diagnostic takes about two weeks. We agree one number to move and baseline it from your records. We sit inside how your business actually runs, map every system, and show you a demo on your own data. If a pilot follows, it starts with one job and runs beside the old way until you trust it.

Whatever number we agreed to move, measured against your own baseline — calls answered, jobs booked, time to first response, detention billed, follow-ups completed. We do not report on activity we cannot tie to that number.

Usually not. Most businesses have adequate tools that nobody has connected properly. Replacing systems is expensive and disruptive, so we recommend it only when the Diagnostic shows the current tool is genuinely the constraint.

That is the normal case and the work is designed around it. Training is done in your own workflow with your own job names, not as a generic seminar, and the playbooks we leave behind are written for the person doing the job.

For a build, yes — scoped to exactly what the work requires, with your own accounts and permissions, revocable by you at any time. We never need access to banking, payroll, or stored customer payment details.

You do. The configurations, workflows, playbooks and documentation are yours and stay with you if the engagement ends.

There is no fixed price: every engagement is quoted on the work it involves, after a pilot call. The Diagnostic is paid in full, upfront. The pilot and each stage of the build are paid half at the start, half on completion. Run & Improve is a monthly retainer priced against the labour it displaces, not against competing software. Scope drives price, and we would rather quote accurately than advertise a number that turns out to be wrong.

A Diagnostic returns a signed baseline and a demo in about two weeks. A build starts with one job and is tested side by side with the old way, on your real work, before it goes live. Anything promising transformation in days is selling you something.

Not for the Diagnostic, the pilot or the build. Those are deliberately narrow and paid, so both sides can walk away cheaply if it is not working. Run & Improve is different — a twelve-month agreement with sixty days' notice either way — because keeping your systems alive means holding capacity for you instead of selling it to someone else. What does not change is that everything stays yours: every credential, every record, every configuration, throughout and afterwards. Leaving costs you the notice period and nothing else.

Then we say so. The Diagnostic includes the option of recommending you do nothing, and we have no incentive to hide a negative result because it is small enough that nobody is trapped by it. A pilot runs beside the old way first, so switching it off leaves the desk working as before.

Yes. We disclose it. Pretending otherwise damages trust the first time somebody notices, and it creates legal exposure that is not worth the small gain.

It hands to a human. Every deployment has an escalation path defined before it goes live, and emergencies are routed to a person by rule, not by the system's judgement.

Recording is configurable and off unless you ask for it. Where it is enabled, disclosure and consent requirements apply and must be confirmed with your own legal counsel before launch — we will not give you a legal opinion on it.

MexaBuild is small, and you should plan as if that matters. So everything we build lives in your own accounts, with the workflow, the configuration and the documentation beside it, and it keeps running whether we are reachable or not. If we disappeared, you would lose a phone number, not a system: any competent contractor could pick it up from the documentation, because that is what the documentation is for. Monitoring alerts go to a person, not a mailbox, and a person is accountable for every system we run.

Systems we run are monitored, so a failure is caught by us, not by your customer. That monitoring is part of the running retainer, and it is the reason we do not hand over unmonitored automation and walk away.