What we build on, and what we operate.
A technology list is not a credential. What matters is whether the people responsible for your estate understand it well enough to be accountable for it. These are the platforms Ferrafox works with day to day.
Cloud and platform
Where systems run, how environments are separated, and how any of it is reproduced.
- Microsoft Azure
- Subscription and resource topology, networking, policy and cost structure.
- Infrastructure as code
- Bicep and Terraform. Environments are defined, reviewed and reproducible.
- Networking
- Connectivity between cloud, offices and existing on-premise systems.
- Containers and compute
- Chosen against the operational burden a client can actually carry.
- Other clouds
- Where an organization already runs on AWS or Google Cloud, we work there rather than propose a migration for its own sake.
Identity and access
The layer everything else authenticates against, and the one most estates get wrong first.
- Microsoft Entra ID
- Directory architecture, conditional access, privileged access and review.
- Single sign-on
- SAML and OIDC across internal and third-party applications, including ones never designed for it.
- Lifecycle and provisioning
- Joiner, mover and leaver as an automated process rather than a checklist.
- Federation
- Access to systems outside the organization’s own directory.
Workplace platforms
The platforms an organization already runs on, treated as managed infrastructure.
- Microsoft 365
- Tenant configuration, governance and lifecycle across Exchange, SharePoint and Teams.
- Information governance
- Retention, classification and legal hold, applied where records actually live.
- Device management
- Intune and endpoint policy, including contractor and shared-device cases.
- Business process automation
- Approvals and provisioning automated inside the platforms already in use.
Applications
The software an organization puts in front of people.
- TypeScript and React
- Next.js for web platforms and customer-facing products.
- .NET and Node
- Server-side services, chosen to match what a client can maintain alongside us.
- Mobile
- Native and cross-platform, with release and distribution operated alongside the build.
- API design
- Interfaces treated as products: versioned, documented and monitored.
Data and integration
How systems agree with each other, and how anyone finds out what happened.
- Relational data
- SQL Server and PostgreSQL, with migrations under the same review as application code.
- Integration patterns
- Queues, events and scheduled transfer, selected against real failure modes rather than fashion.
- Reporting layers
- A defensible position on where a number came from, before anyone builds a dashboard on it.
- Legacy interfaces
- EDI, file transfer and vendor APIs, because most estates still depend on them.
Operations tooling
What makes the difference between a system that runs and one that is operated.
- Pipelines
- GitHub Actions and Azure DevOps. Releases are repeatable and reversible.
- Observability
- Knowing something is wrong before the business reports it, with enough signal to know why.
- Backup and recovery
- A recovery position that has been tested, not merely configured.
- Secrets and configuration
- Held in managed stores in the client’s own tenancy.
No badges we have not earned.
Ferrafox holds no vendor partner status and no platform certifications, and displays none. Listing a platform here means we build on it and operate it, not that its vendor endorses us.
Where an organization already runs on something outside this list, that is usually the right place to keep it. Recommending a migration because it suits the supplier rather than the estate is how the last decade of technical debt got there.
Tell us what your organization runs on.
The first conversation is about the environment as it stands today: what exists, what it costs to keep running, and where responsibility currently sits.