There is no fixed service list. These are the jobs that came back most often over the last three years; most projects are a combination of two or three of them.
Most of what an enterprise client needs is really a panel: who sees what, who can change what. When the permission matrix is not right from the start, the project stalls within its first year, so that is where we begin.
We prefer building on top of a working system rather than replacing it. Usually that means a queue that reads from and writes to the ERP and retries itself on failure, so neither side has to wait for the other.
The service you expose becomes one of the faces of the company. We write the contract up front, set the versioning policy and produce the client libraries, so whoever integrates can work from the documentation alone.
On a project whose developer has left, the first job is not writing code but seeing what runs where. We set up monitoring and backups first; we touch nothing until there is a point we can roll back to.
For work with a clear shape. Price and timeline agreed up front; anything that comes up later is written as separate scope.
For work that takes shape as it goes. Dedicated developers for a fixed monthly fee, with you setting the order of work.
For systems already in production. Monitoring sits with us, and the response time for critical failures is written into the contract.
We try a new technology on our own products before it goes anywhere near a client project. If you run something that is not on this list, talk to us anyway — half of our takeover work starts on a stack somebody else chose.
Write a few sentences about what you want to build and we will come back within three business days.