A Manchester software team that has built and run its own products.

No. We work with clients across the UK and internationally, and have done for years. Being in Manchester matters for the clients who want a team they can sit down with, and for the simple fact that we understand the market we have worked in for two decades. It has never been a restriction on who we take on. Most projects run as a mix: some sessions in person where that genuinely helps, the rest remote, with the same working rhythm either way.

Mostly software that people use to do a job: SaaS platforms with subscriptions and multiple customer accounts, web applications like customer portals, booking systems and operational tools, ecommerce and payment platforms, and bespoke internal software replacing spreadsheets or ageing systems. We also take on existing products that need rebuilding, extending or bringing back up to standard. What we do not do is one-off brochure websites with no application behind them—there are other Manchester agencies better suited to that, and we would rather tell you so early.

Cost follows scope, so we give a range against a defined brief rather than a figure up front. The things that move it most are how many distinct user journeys there are, how many roles and permission levels the software needs, how much integration work is involved, and how much discovery and design is needed before engineering starts. A focused internal tool is a different proposition to a customer-facing platform with billing, reporting and several integrations. We would rather scope it properly than quote blind, so we start with a conversation and come back with a realistic range once the scope is clear.

It depends almost entirely on how much has to exist in the first release, which is the single decision that changes a timeline most. Often the most valuable early work is separating what the first version genuinely needs from what can follow it. We estimate after discovery and definition, once scope, user journeys and the technical approach are agreed, and then deliver in iterations so you see working software early and regularly rather than waiting for one handover at the end.

Yes, and we often do. That might mean taking one product or module while your team continues on the rest, providing design and product capability to developers you already employ, or working as the engineering team for a business that has the domain expertise but no in-house build capability. We are a small senior team, so you get the people doing the work rather than an account layer between you and them, and we fit around how your team already runs rather than importing a process nobody asked for.

We choose the stack to suit the project rather than applying the same one to every brief. In practice that means modern, well-supported web technologies with a large talent pool behind them, so you are not locked into anything obscure and could hand the codebase to another team if you ever needed to. The decisions that matter more than the framework are the data model, the access and tenancy model, and how the software is deployed and monitored—those determine whether it is still quick to change in year three.