The questions worth asking

Yes. A mutual NDA is signed before project details are shared. That is our default, not something you have to ask for.

Because both sides share things worth protecting during discovery. A mutual agreement covers your commercial information and our technical approach in one document.

Yes. We review it and come back with anything that needs discussion rather than insisting on our own paper.

Only with written permission. Several of the case studies on this site describe delivered systems without naming the client for exactly that reason.

Project delivery with fixed scope, embedded engineers working inside your process, extended team capacity added to an existing team, and support plans after delivery. They cover the full lifecycle from inception to support.

Every engagement has a dedicated project manager and a team lead with years of industry experience, plus the engineers and quality assurance the scope requires.

Both are available and the mix is agreed with you. We do not name the country of any team.

A cadence is agreed at the start and the project manager holds it. You see working software at each stage rather than status reports.

Yes. The embedded team model puts engineers inside your tooling, your standups and your review process rather than running a parallel project.

Five steps. Tell us the problem. We map it. We build it. You test it. We ship it, with full handover of code, intellectual property and documentation.

We ask about the work rather than the software. What the process is, where the time goes, what systems hold the data, and what a fix would be worth. Then we say what we would build and whether it is worth doing.

A session with engineers rather than a sales conversation, covering your systems, the interfaces available, the data and the constraints that will shape the architecture.

Before we ship. Testing by your team is a stage of the process rather than a courtesy at the end.

Source code, intellectual property assignment, documentation, credentials and a deployment guide.

No. We do not claim any certification we do not hold. What we do describe is our actual practice: access control, secrets management, least privilege, and data handling written into each engagement.

In a platform secret store scoped per environment, never in a repository or a chat thread, with access limited to the people who need it and a documented rotation procedure.

Not unmasked. Copying live customer records into a lower environment is a privacy problem with no upside, so we seed realistic data instead.

Yes. We design for data minimisation, purpose limitation, retention rules, export and deletion, and we document where data is stored and processed. Your own legal advisers confirm what applies to your organisation.

No. Payment integrations use processor hosted fields or a processor managed checkout, so card details go from the browser to the processor and never reach your systems or ours. Sawhorse is not a payment processor and holds no PCI certification.

Usually yes, through an API, webhooks, a database replica or a supported export. Where the only route would be brittle we say so and describe the risk before you commit.

No, and you should not want us to. Accounting stays the financial record and we integrate with it.

Failures queue rather than disappear, retries run with backoff, anything that exhausts its budget is visible and replayable, and a scheduled reconciliation reports drift whether or not anyone is worried.

Yes. Plenty of established platforms speak SOAP, fixed width files or scheduled drops. We build an adapter so the rest of the estate sees a modern interface.