How custom automation projects usually work.

I build practical automation around real workflows. The best projects start with a clear repeated process: what is copied, checked, filled, moved, or repeated often enough that it creates friction.

1. You describe the workflow

Send a short description of the process you repeat. Useful details include the pages or systems involved, where the data comes from, where it needs to go, and what currently takes time.

2. I check automation fit

I look at whether the workflow is practical to automate. I check repeated steps, browser/page structure, data quality, possible edge cases, and whether the automation can be made reliable enough to be useful.

3. We agree scope and price

I prefer a clear first version instead of a vague endless project. The scope should define what the automation will do, what it will not do, what inputs it expects, and what a successful delivery looks like.

4. Payment structure

For custom work, the usual structure is 50% upfront and 50% after delivery/testing. This can change depending on project size, risk, and scope, but staged payment is the default expectation.

5. Access and test data

Depending on the project, I may need access to the relevant environment, a test account, screenshots, sample orders, sample messages, screen recordings, or a call/video showing how the workflow is currently done.

6. Build, test, refine

I build the first working version, test it against real workflow examples, and then refine behavior, UI, reliability, and edge cases based on feedback.

7. Delivery

Delivery usually includes the working automation/tool and basic usage instructions. For larger workflows, support or future improvements can be agreed separately.

If you are unsure whether something can be automated, send the workflow anyway. A short description is usually enough to decide whether it is worth discussing.