Common questions

We assess business processes, build workflow automation and supervised AI systems, create custom software where nothing off the shelf fits, draft operational AI policies, and train teams. Most work starts with the assessment we call the map, because it shows what is worth changing before anything gets built. Production readiness is the one exception — it starts on its own, because the app already exists and the question is whether it will hold up.

The assessment is quoted at a fixed price before work begins. Build work is priced item by item in the plan. Support is optional and priced separately.

You hold the code, the software accounts, the written instructions and the training, so anyone can maintain the system: us, someone on your staff, or another firm. Support from us is optional and priced separately, and cancelling it stops nothing. We are usually the first call because we built it, but you are never stuck with us to keep it running.

The timeline depends on the number of workflows, systems, and people involved. The proposal states the assessment timeline before work begins. Each build item has its own estimate.

We need time with the people doing the work and temporary access to the systems involved. Most of your effort is a few focused conversations. We do the mapping and prepare the plan.

We draft it, you approve it. The draft covers what regulators and auditors actually check: which tools your staff may use with which kinds of data, how vendors are vetted — including what they train on and how long they keep things — how long you keep data, and who is accountable for every decision AI feeds into. Where a framework applies to you (HIPAA, SOC 2, state privacy law), the policy is written to slot into your existing compliance program rather than sit beside it. Your leadership or counsel makes it final. We draft the policy; we do not replace your judgment or your lawyer.

Least privilege by default: we request the narrowest access the work requires, scoped to the systems in the plan, and nothing more. All work happens under named, individually attributable accounts, never shared logins, so your audit trail shows exactly who did what and when. Credentials never appear in code or config; they live in a managed secrets vault and every credential we touch is rotated at handover. Offboarding is a deliverable, not a hope: when the engagement ends you receive written confirmation that our access is revoked, itemized by system, suitable for your own access review records.

It stays in your accounts, under your controls, for the entire engagement. We do not copy it into our systems, sell it, or use it to train models. Anything AI processes during a build runs under provider terms that prohibit training on your data, and the plan names each provider so your team can verify the terms themselves. Everything we build logs what each automated decision was based on, so when an auditor asks why the system did something, the answer is on record. When the engagement ends, our access ends, confirmed in writing.

No. Any hosting or service accounts a build needs are laid out in the plan first, what they are, what they cost to run, and what the alternatives are, and nothing gets created until you approve it. Once a build is paid for, everything transfers to your name at handover. If you end ongoing support later, the systems are already yours; nothing stops working.

A chat window is useful, and it is a different job. The waste usually sits between systems, not inside them: the same figures typed into three places, which drafting text does not fix. What we build runs inside the systems you already use, so an order moves into the books and a report builds itself. It stops and waits for you when something is unclear instead of guessing, and nothing reaches a customer until a person on your side signs off. If a chat window already covers what you need, the plan says so.

Yes. A session covers what current tools do well, where they fail, and what to ask a vendor before you sign anything. It is priced on its own and requires no other engagement. If your team leaves able to spot the difference between a real use case and a sales pitch, the session did its job.

Almost never. The waste usually sits between systems, not inside them: the same figures typed into three places that do not talk to each other. Integration work connects what you already have. Replacement only enters the plan when a system is the problem, and it shows up as a priced item you can decline.

If you started a business to cook, build, design, or fix things and now spend your week on invoices, spreadsheets, and chasing paperwork, you are exactly the right size. The point of this work is to hand the admin work to software so your hours go back to the thing you actually opened the doors to do.

They keep the job and lose the parts of it nobody wanted. The work we remove is the copying, the chasing and the re-typing; what is left is the part that needs a person, which is also the part that was getting squeezed. In the shop we published, the administrator who ran the paperwork was the one shown how to run the new system, on the live system, and still runs it. We are hired to give hours back, not to cut a desk.

We work remotely with clients worldwide. In-person meetings and workflow observation are also available in the Phoenix metro area.

One. Arizona Auto Wraps, in Scottsdale: one system takes inquiries in and asks a person before anything goes out, and the owner reports about twenty hours a week back. That figure is the owner’s; we have not measured it ourselves. We publish results only when the client approves and the numbers hold.

Read the full case study→

Then the plan says so and you have spent a fixed fee to learn your operation is already tight. We would rather tell you that than invent work. The findings document is still yours to keep.