Automating With No Technical People In-House

What you actually need

Not a developer. Someone who knows how the work is done, can decide between options, and will notice if the system stops matching the business.

Most of our clients have no technical staff at all. The projects that struggle are the ones with no owner, not the ones with no engineer.

How we adapt

• Specifications written in business language, not technical documents
• Demonstrations where you click through the actual path rather than watching slides
• Anything you will want to change built as configuration with an interface
• Managed hosting, so nobody in your business has to run a server
• Monitoring that alerts us as well as you

The design question we ask constantly: could the person who runs this business change that themselves? If the answer should be yes, it goes behind a screen rather than in a config file.

What you will be asked to decide

1. What should happen to the awkward cases — the business rules, not the code
2. Thresholds: above what value does a human check it?
3. Who receives alerts and who approves what
4. What done looks like, in terms you would use with a customer

None of those are technical questions. All of them are ones only you can answer.

Support afterwards

A maintenance arrangement matters more when there is nobody in-house — not because the system is fragile, but because dependency updates and integration repairs need someone whose job it is.

We will tell you honestly when a system is simple enough not to need one.

Getting a second opinion without a technical person

Ask any supplier five things: who specifically will build it, what is out of scope, what would make it late, what would you not automate, and what is wrong with our brief.

You can judge those answers without understanding a line of code, and they predict outcomes better than any technical assessment you could commission.

Frequently asked questions