The companies we have shipped for, and the platforms and tools those products were built on.
We work with these week to week, which is why we are willing to recommend them.
Clients we ship for
Companies whose products we have designed, built and released.
Platform partners
We do not list every store and cloud on the market. These are the ones we have years of production work on, and the ones we will recommend when they fit the product.
App Store
Apple
Apple is how our native iPhone and iPad apps reach people. We build in Swift, run TestFlight with the client's testers, and take the listing through App Store review and release ourselves.
It is the platform we recommend for products that need to live on iPhone properly: payments, notifications, camera, and the kind of performance a wrapped website will not give you.
Google Play is where our Android apps go live. We handle Play Console, signing, review and the release cycle ourselves.
Android is the right platform for products that need to reach devices that are not iPhones. Gemini sits in the same family when an AI feature should run on Google's models.
Google Cloud is the infrastructure we use for products that already sit in GCP, and for clients whose ops team wants Google rather than AWS or Azure.
We design the architecture, deploy it, and keep the running cost readable. Firebase and Gemini live in the same family, which keeps the stack simpler when the product already uses Google for apps or AI.
Amazon Web Services is the cloud a lot of our live products run on: compute, storage, queues, and the day-to-day ops around an app that is already in production.
We have been shipping on it for years, so we can set it up, run it, and hand it over in a shape the client's ops team can maintain.
Microsoft Azure is the cloud we use for clients whose IT already lives in the Microsoft estate, including Azure OpenAI when models have to stay inside their tenancy.
Most of that work is for teams that already have Microsoft accounts, licences and security reviews in place, so the product lands where their IT can support it.
Unity is the engine behind titles we have shipped, including SpaceCatch on mobile and desktop. We use it for games and for real-time 3D in VR and AR.
The same team builds the client, takes it through the stores, and stays on for live ops after launch. If you need a game or an XR product, this is usually where we start.
WordPress is the CMS we use for marketing sites, blogs and editorial work. The Pixelfield blog runs on it, so editors can publish without waiting for a developer release.
It is the right tool for sites that need to be updated often. Logged-in products, payments and custom workflows usually want a web app, and we sort that out before anyone starts building.
Ethereum is the chain we build on when wallets, tokens or on-chain ownership are a real part of the product. That means Solidity contracts, tokens (ERC-20, 721, 1155), minting, NFT flows, and wiring the contract to an app.
If the product does not need a chain, we will tell you before anyone writes a contract.
The languages, frameworks and tools our developers work in day to day, plus the models we put into live products. This is what we hire for.
Partner programme
Leadinfo
Leadinfo shows which companies visit a website, instead of leaving sales with a pile of anonymous sessions. We run it on pixelfield.co.uk, so inbound from our own site maps to a company name.
We are in the Leadinfo partner programme, and we put the same setup on a client site when they need to see which companies are visiting.
OpenAI's GPT models are what we use for LLM features in live products: chat inside an existing app, search over a client's own documents, classification, and agents that call tools.
A typical job is wiring GPT into software the client already has, with logging and a person reviewing the setup before anything customer-facing goes live.
Anthropic's Claude models are a strong fit for longer documents, tighter instruction-following, and teams that want a second provider next to OpenAI.
We use Claude in the same kind of production setup: behind an API, with logging, and written so the product is not locked to one vendor in the codebase.
Figma is where we design product UI. Screens are handed over as a UI kit engineers can build from, with components and states rather than a deck of pictures.
What leaves Figma is what goes into production, with spacing, states and components the engineers do not have to invent again.
React is the frontend we hire for and ship on, written in TypeScript. It is what we use for dashboards, customer portals, and the parts of a site a page builder cannot do.
The same team also ships React Native when that frontend needs to land on iOS and Android as an app.
TypeScript is the language we write React, Next.js and Node.js in. Types live in the repo from day one, which keeps a growing codebase from falling over as more people touch it.
We hire frontend developers who work in TypeScript. Older JavaScript only shows up when we are replacing something that already exists.
Python is what we use for APIs, data work, and the service layer around AI features: retrieval, evaluation, and the jobs that should not live in the frontend.
A lot of our AI delivery sits here, next to the app the user actually sees.
Flutter lets us ship iOS and Android from one codebase. We hire Flutter developers and train juniors on it, so the client is not dependent on a single specialist.
We recommend it when both stores are in scope and the product does not need the deepest native APIs on day one.
Firebase gives a product authentication, data and hosting without standing up a custom backend on day one. We use it for early products and for apps that will stay in that shape for a while.
If the product later needs a proper API, we move it.