Skip to content

How a first project works

A first project takes one workflow from a first conversation to daily use, in four steps. We agree the scope and the price in writing before we build anything.

Before you start

It starts with a 30-minute call. Bring the steps, the systems involved, and how you check the result today. We'll say whether the workflow looks like a fit and what a first deployment would cover. Book a call or tell us about the workflow.

1. Workflow assessment

We agree what success looks like. We work through the task with the people who do it today.

  • Map the steps, the volume, and the time each item takes now.
  • Find out which systems the task touches, what access it needs, and where the data must stay.
  • Choose test cases, including cases that should make it stop, and agree the acceptance criteria.

At the end, you have a defined scope, a baseline of today's effort, and an implementation proposal.

Some workflows aren't a good fit, for example when an API already makes the change, or when there's no way to check the saved record and a wrong entry is costly. We'll say so at this step.

2. Build and integration

We connect the systems the work depends on. We use APIs and ordinary code where they fit, document processing for incoming files, and AI for tasks that need it. OpenAdapt handles the steps that only happen on screen.

  • Connect the agreed inputs, applications, and outputs.
  • Build the record checks and a review path for your operators.
  • Test normal cases, exceptions, and cases where it can't tell whether a save went through.

At the end, you have a working implementation with evidence your team can review.

3. Deployment and training

Your operators run the readiness test against the agreed criteria. We work with IT on access and deployment, then train the people who will run the workflow and answer its questions.

  • Choose where it runs: a computer you control, or a computer we host for approved browser work with non-regulated data.
  • Write down the operating steps and who handles a stop.
  • Agree who owns the workflow after handover.

At the end, you have an accepted workflow, guidance for your operators, and a named owner.

4. Maintenance and expansion

Applications change, and so do your processes. Under a support agreement, we review stops and failures, update the connections, and test fixes before they go back into use.

  • Agree monitoring, support coverage, and response times.
  • Review stops and approve fixes.
  • Reuse what already works when you add the next workflow.

At the end, you have an agreed maintenance scope and a measured path to the next workflow. The baseline from step 1 is what you compare against.

What we need from you

  • A person who does the task today and can show it from start to finish.
  • The monthly volume and the time each item takes.
  • Access to the system in a test or training environment, or written approval to work in your production environment.
  • Test records that cover the real variety of cases and are safe to create and change.
  • A second way to read the saved record, such as an API, a read-only database or export, or a report. If none exists, a read-only login is a weaker fallback.
  • A security contact and an IT contact.
  • The person who'll make the go or no-go decision.

Price

We scope implementation and ongoing maintenance per workflow, separately from software hosting. The proposal sets the deliverables, responsibilities, acceptance criteria, and fees. Software prices are on the pricing page.

Technical details

The commercial pages describe the same work in the terms an engineering or procurement review uses: