Service
Cloud Deployment and DevOps
Deployment pipelines, environments, secrets handling, backups and monitoring, set up in accounts you own and documented so your team can run them.
The problem
What usually goes wrong
Software that only one person can deploy is not finished. Neither is software whose database has never been restored from a backup, or whose secrets live in a chat thread.
These gaps are invisible until the week they are not, and then they are the whole problem.
Delivery includes the machinery that keeps the thing running and the documentation that lets someone else operate it.
Scope
What we deliver
Environment layout
Development, preview and production with separate data and credentials, and a promotion path between them.
Continuous integration and deployment
Typecheck, lint, tests and build on every change, deploying automatically on merge with a one step rollback.
Secrets management
Secrets stored in the platform secret store, scoped per environment, with a documented rotation procedure.
Backups and restore
Scheduled backups with a retention policy, plus a restore that has actually been performed and timed.
Monitoring and alerting
Uptime, error rate, latency and queue depth, with alerts that route somewhere a person reads.
Runbook
Written procedures for deploy, rollback, restore, key rotation and the failures most likely to occur.
Method
Technical approach
Everything is provisioned in accounts you own. Domains, hosting, database and third party services are registered to you, so a change of supplier is an access change rather than a migration.
The pipeline gates on the things that break production: typecheck, lint, the test suite and a real build. A deployment that passes those and still fails should be rollback in one action, so releases are immutable and the previous one stays available.
Preview environments are built per change with their own data, which is what makes review possible without risking production.
Backups are only real once restored. We perform a restore into a scratch environment, time it, and write the result into the runbook so the recovery time is a known number rather than a hope.
Alerting is tuned to be quiet. An alert that fires weekly for no reason trains people to ignore the one that matters, so thresholds are set from observed behaviour after launch.
Handover
Deliverables
Everything below is yours at delivery, including the intellectual property. Sawhorse keeps nothing.
- 01Environment configuration for development, preview and production
- 02Continuous integration pipeline with gates and deployment on merge
- 03Rollback procedure, tested
- 04Secret storage per environment with a rotation procedure
- 05Scheduled backups, retention policy and a verified restore
- 06Monitoring, logging and alert routing
- 07Runbook covering deploy, rollback, restore and incident response
- 08Handover of all account access to your organisation
Related
Systems this service builds
- Multi Tenant and White Label SaaSSoftware one codebase serves to many customers, each with isolated data, its own branding and domain, and billing that matches what it uses.
- Ecommerce PlatformsStorefronts built for the catalogue and the fulfilment model you actually have, with checkout through a processor and orders that reach fulfilment without manual steps.
- Customer and Client PortalsA logged in area where your customers see their own status, documents, invoices and history, which removes the phone calls that only exist because they cannot.
FAQ
Questions people actually ask
Do you host our software?
No. Infrastructure runs in accounts you own, and we deliver the configuration, the pipeline and the documentation. Support plans are available separately and are tailored on a discovery or technical call.
Which platforms do you deploy to?
Commonly Vercel for applications, Railway for services that need a long running process, and Neon or another managed PostgreSQL for data. The choice follows the workload rather than a preference.
How are secrets handled?
In the platform secret store, scoped per environment, never in the repository. The runbook includes the rotation procedure and who holds access.
What is the recovery time if the database is lost?
A measured number rather than an estimate, because the restore is performed and timed during the engagement and written into the runbook.
Can our team deploy without you?
Yes. That is the intent of the runbook and the pipeline. Deployment happens on merge, and rollback is one action.
Do you set up staging with production data?
Only with data that has been masked. Copying live customer records into a lower environment is a privacy problem with no upside, so we seed realistic data instead.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.