How we work
From specification to live system.
Design, build, integrate, support. Most clients do not start at the beginning — they arrive with a half-built system, a specification somebody else wrote, or something already live that needs looking after.
Design & specification
Interface design, data modelling and technical specification. We map the process, agree the scope and settle the architecture before development starts, so the build is not the place where requirements get discovered.
Development
Conventional, well-supported technology rather than novel choices. Work is version-controlled, peer-reviewed and tested as it is written, in short cycles against a backlog you can see.
Integration
Connecting to the ERP, CRM and line-of-business systems already in place — including older platforms without a modern API, where an adapter has to be written before anything else can happen.
Deployment & support
Environment setup, release management and monitoring. After launch we can stay on for maintenance and updates, or hand the system to your team with the documentation to run it.
Technology
What we build with.
Mainstream, long-supported tools. The test we apply is whether another engineer could pick the system up in five years without specialist knowledge.
Backend
- Python
- Node.js
- PHP
- PostgreSQL
- MySQL
- REST & GraphQL
Frontend & mobile
- TypeScript
- React
- React Native
- Next.js
- HTML & CSS
Cloud & infrastructure
- Oracle Cloud
- AWS
- Vultr
- Docker
- nginx
- CI/CD
Data & AI
- Reporting pipelines
- Supabase
- Document processing
- Applied LLMs
Onboarding
Working with procurement.
Vendor paperwork is easier to deal with at the start than halfway through a build.
Confidentiality
We sign client NDAs, and can provide our own. Either way it is dealt with before system or data detail is exchanged.
Security questionnaires
Vendor security assessments, insurance and compliance questionnaires are part of onboarding. Send them with the enquiry if that speeds things up at your end.
Contracting
A master services agreement covering the relationship, with a separate statement of work per engagement setting out scope, deliverables and price.
At a glance
- Coverage
- Remote, worldwide
- Contracting
- NDA, MSA, SOW
- Engagement basis
- Fixed scope or monthly
- Source code & IP
- Transfers to client
- Infrastructure
- Held in your accounts
- Documentation
- Provided at handover
Common questions
The things procurement asks first.
Who owns the code, the data and the infrastructure?
The client does. Cloud accounts are normally opened in your organization's name with access granted to us, rather than the reverse, and source code sits in your repository. Under our standard terms intellectual property transfers to you on completion — there is no licence to renew and no platform of ours in the middle.
What happens at the end of an engagement?
You keep the system and it keeps running. Documentation and runbooks are produced as part of the work, so your own team or another supplier can pick it up. Where we hold credentials or accounts, those are handed over and our access is removed.
Can you work with our IT, security or compliance teams?
Yes, and engagements go better where we do. We work to existing client policies on access, data handling and change control, and we regularly complete security reviews and vendor questionnaires as part of onboarding.
Do you subcontract?
Most work is done by our own engineers. Where a specialist is genuinely required — a particular integration, or a compliance area outside our expertise — we say so, and they work under the same confidentiality terms as the rest of the team.
How are scope changes handled?
Changes outside the agreed statement of work are written up and quoted for approval before the work starts. It is the most common way projects go wrong, so it is worth being formal about.
How is our data handled?
Development and testing normally run on anonymized or synthetic data rather than a copy of production. Credentials are kept in a managed vault rather than in documents or chat, and access is granted per person and removed at the end of the engagement.
What size of organization do you usually work with?
Clients range from city and state government departments to manufacturers and professional services firms. The common factor is not headcount — it is having a process important enough that the software supporting it has to be correct and maintainable.
Can you take over a system somebody else built?
Often, yes. We start with a short assessment of the code, infrastructure and documentation, and give you a straight read on whether it is better maintained, refactored or replaced — including when the answer is that it is fine as it is.
Next step
Something here not covered?
Send it with your vendor questionnaire and we will answer it in writing. If it is the sort of question another procurement team would ask, it ends up on this page.