Guide · Blog Post
Hiring a Robomotion Developer: What a Production-Ready Bot Includes, and What to Ask
Anyone can record a bot that works once on their own laptop. The bots that cost businesses money are the ones that worked in the demo and then failed quietly at 3 a.m. three weeks later. The difference is not the platform; it is everything around the happy path. This is the checklist I build to, and the questions to ask any Robomotion developer, me included, before you hire.
By Mehadi Hasan 7 min read
1. What production-ready means for a Robomotion bot
It runs on a Production Robot, on a machine that stays on
Development Robots cannot be scheduled or triggered (robot docs). A real deployment uses a Production Robot on a server or VM, authenticated with a per-robot token, which Robomotion's security docs describe as correct "for anything unattended". If the bot drives a headed browser or desktop app, the machine needs an interactive desktop session.
Credentials live in the Vault
Never in the flow, a spreadsheet, or a message. Robomotion encrypts vault items in the browser with AES-256 before upload, and flows reference the item, not the password. Bots log in with service accounts you own, so you can revoke them.
Every item is checked, and one failure never stops the batch
After each submission the bot confirms the result on screen. A failed item is retried, then logged with a screenshot and skipped, and the batch continues. When I built a bill-entry bot for AppFolio, this per-bill check was the feature that mattered most.
It resumes instead of restarting
If the server reboots halfway through 300 invoices, the next run picks up at invoice 151, not 1, and never submits anything twice.
Someone hears about problems the same day
Start, finish, and error alerts go to a channel your team reads, such as email, Slack, Teams, or Discord, with counts: 212 processed, 3 sent to review, 0 failed. Silence should mean "did not run", which is itself an alert.
Your team can change settings without a developer
Account lists, schedules, folders, and thresholds live in a config file or sheet your staff already use. In my utility-bill bots, the client adds a new account by adding a row to the Excel config they already maintained.
Selectors built to survive small website changes
Stable attributes and labels instead of fragile positions, plus a check that the expected page loaded before acting. When a site changes too much, the bot stops and alerts rather than typing into the wrong field.
It is documented and handed over
A one-page runbook: what the bot does, when it runs, where the logs are, what each alert means, and how to pause it.
2. Ten questions to ask before hiring
- Can you show me an unattended bot you built that has run in production for months?
- What happens when one item in a batch fails? When the website is down?
- If the run is interrupted, where does it resume?
- How will I know it ran, and how will I know it failed?
- Where do credentials live, and whose accounts will the bot use?
- Which Robomotion plan and how many Production Robots do my processes need, and why?
- Where will the robot run, and who maintains that machine?
- Whose name is the Robomotion workspace in? (The right answer: yours.)
- How will you test with real data before go-live?
- What does maintenance cost when a website changes?
3. Red flags
- A fixed price quoted before anyone has looked at the actual screens and documents.
- "It never fails" instead of an answer about what happens when it does.
- Passwords requested by email or chat instead of set up in a vault.
- The bot running on the developer's own machine or workspace.
- No plan for go-live beyond "it works on my side".
4. What to prepare before the first call
You will get a faster, more accurate quote if you have:
- A screen recording of someone doing the task once, start to finish.
- Five to ten real sample documents, including awkward ones.
- How often it runs, how many items each time, and how long it takes today.
- Who needs to know when it finishes or fails.
- Any rules about where data may be stored.
5. How I work
I am an automation engineer with 8+ years of experience building RPA bots on Robomotion, UiPath, and Playwright, alongside n8n workflows and AI agents. A typical Robomotion project goes: a free 30-minute call, a written scope and quote, a build in your workspace, a parallel run against real data, go-live with alerts, then optional maintenance. You can see one of these end to end in my utility invoice bots case study: portal login, PDF download, OCR, PostgreSQL, cloud archive, and Discord alerts, unattended.
Looking for a Robomotion developer?
Send me the process and a few sample files. I will reply within 24 hours with whether it is a good fit for RPA, the plan and robots it needs, and a rough budget. See my RPA development service, or read Robomotion pricing explained first.
Get a free 30-min automation auditFrequently asked questions
What should a Robomotion developer deliver?
A bot running on a Production Robot in your own workspace, credentials in the Vault, per-item error handling, resume after interruption, alerts on start, finish, and failure, configuration your team can edit, and a short runbook.
Whose account should the Robomotion workspace be in?
Yours. The business should own the workspace, the robots, and the credentials, and invite the developer in. Offboarding is then just removing their access.
What happens when a website the bot uses changes?
A well-built bot checks that each page is what it expects and stops with an alert rather than entering bad data. The fix is usually a selector or step update, covered by a maintenance arrangement.
What do I need to prepare to get a quote?
A screen recording of the task done once, five to ten real sample documents, how often it runs and how many items, who needs to be notified, and any data storage rules.
Robot types, credential handling, and deployment details checked October 30, 2026 against the Robomotion documentation linked above.