SaaS development in Manchester
Plenty of Manchester agencies have built the same tool for five different clients and started to wonder whether it is a product. Sometimes it is. Turning it into SaaS means a different kind of engineering: one codebase with tenants instead of five forks, sign-up and billing, permissions that work for customers you have never met, and support that does not depend on the developer who wrote it.
We help with that transition. We look at the five versions, find what is truly common, and build the multi-tenant core with tenant isolation enforced in the database, subscription billing, and an admin view your support team can use. We will also tell you if the tool is better kept as a service your agency sells, because not every repeated build has a market behind it.
Manchester's software market has two centres of gravity, a tram ride apart. MediaCityUK in Salford is home to BBC North and ITV, and to the production companies, post houses and broadcast suppliers that grew up around them. Their systems are about media and rights: asset libraries, scheduling, metadata that has to follow a programme from edit to broadcast to streaming, and the comments, votes and uploads that now come with so many shows. Anything that hosts what the public posts needs moderation designed in from the first episode, because the busiest night is usually the launch.
The other centre is online retail. Greater Manchester is home to THG, boohoo, AO and Auto Trader, and that concentration has produced a generation of engineers and smaller brands who think in conversion rates, warehouse cut-offs and peak trading. The mid-sized retailers we hear from have usually outgrown their first platform in stages, and the joins between the shop, the warehouse and the finance system are where the money leaks. Between the broadcasters and the retailers sit the city's digital agencies, building for clients across the North and London, and they often need engineering capacity for a quarter rather than another permanent seat.
Hiring here is cheaper than London but not cheap. ITJobsWatch puts the median advertised salary for a software engineer in Manchester at £75,000 over the six months to September 2026, and GCHQ, which opened its Manchester site in 2019, now competes for the same security-minded engineers. Retailers and agencies feel the squeeze most in the run-up to peak, when a build has a fixed date and a permanent hire would arrive after it.
Working with us from Manchester fits the day you already have. Four hours of every working day overlap with yours, set across your morning, so stand-up, review and decisions happen live with the engineer who writes the code. The afternoon runs on pull requests and written updates in your own Slack, GitHub and Linear, waiting for you when you get back from lunch, with runbooks and architecture notes written as the work goes.
We are the right fit for a defined build, a deadline before peak, or a quarter of extra senior capacity for an agency that has won more work than it can staff. Start with a fixed-price two-week piece and judge us on the result. For agencies, we work white-label under your name, in your repositories and your tools.
Four ways this arrives.
Then SCIM, then role mapping, then a security questionnaire. We add SAML and OIDC through a provider or your own identity stack, provision users from their directory, and keep the permission model working for the self-serve customers who never asked for any of it.
Shared tables with a tenant column and every query trusted to filter on it. We enforce isolation below the application, with Postgres row-level security or separate schemas, and write tests that try to read across tenants and must fail.
Moving from seats to usage, adding a free tier, or selling annual contracts beside monthly plans. We model plans and entitlements separately from the payment provider, meter usage into a ledger you can audit, and make proration and dunning tested code rather than a monthly surprise.
Every larger customer asks who changed what, who can reach production and how access ends when someone leaves. We build exportable audit logs, least-privilege access and change control through pull requests, so your answer is a screen, not a spreadsheet.
A multi-tenant platform scoped per organisation, with admin screens for users, access and login alerts, and a way for an administrator to view the app as any user.
Read the write-up →Asked by Manchester teams.
How do you work with teams in Manchester?+
Four hours of every working day overlap with yours, set across your Manchester morning, so stand-up and review happen live. We join your calls and work in your tools: Slack, GitHub and Linear. You talk directly to the engineer who writes the code. When you get back from lunch, the afternoon's work is waiting in pull requests, with notes on what changed and why, and runbooks written as we go.
Do you build for Manchester retailers and media companies?+
Yes. For online retailers we build the joins that decide the margin: stock that is right across the website, marketplaces and warehouse, returns that flow back into sellable stock, and order data that reconciles with the 3PL and the payment provider. For broadcasters and suppliers at MediaCityUK we build content and rights metadata services, delivery APIs for streaming partners, and audience features with moderation designed in.
How does your rate compare to hiring in Manchester?+
ITJobsWatch puts the median advertised salary for a software engineer in Manchester at around £75,000. Our published rate is $35/hour with a $5,000 minimum, or $5,400 a month for one engineer embedded in your team. There is no recruiting time and no employment overhead, and we can start within days of the first call. A fixed-price two-week piece at $2,800 lets you judge us on output first.
Can you take over a platform a Manchester agency built?+
Yes. In Manchester a retail or media platform often outlives the agency that built it, so this is familiar work. After a 30-minute call with the engineer, we read the code, run it, and write down how it actually works: architecture notes, the risky paths and what we would change first. That becomes a written plan within a week. A fixed-price two-week piece then ships the first real change.
Shared database, separate schemas, or a database per tenant?+
Shared tables with row-level security for most products, because it is the cheapest to run and the simplest to migrate. Separate schemas or databases when a customer contractually needs isolation, data kept in a particular region, or its own backup schedule. We design so a large tenant can move to its own database later without rewriting the application, because that request usually arrives with the biggest contract.
When should we add SSO and SCIM?+
Before the deal that needs them, not in the first month. Design the user and organisation model so SSO slots in without a data migration, then switch it on when a paying customer asks. A provider such as WorkOS saves you building SAML and SCIM yourself, which rarely pays off until enterprise customers are a large share of your revenue.
Stripe, or a merchant of record like Paddle?+
Stripe gives you the most control over plans, invoices and the checkout. A merchant of record such as Paddle takes a larger fee and becomes the seller, handling tax wherever you sell. For a small team selling internationally from the start, the merchant of record is often the simpler path. We lay out both at your price point before you choose.
Can you make the product ready for enterprise buyers?+
Yes. Enterprise buyers ask for the same things every time: single sign-on, directory provisioning, roles they can define, an audit log they can export, and admin screens their IT team can use. We design those into the data model early, so saying yes to the next large customer is a configuration change rather than a quarter of rework.
What have you built that carries over to SaaS?+
Multi-tenancy, per-organisation access and admin tooling run through most of what we build. FM360 is a multi-tenant platform with all three: organisations, apps and access managed per customer, usage analytics and login alerts. Subscriptions and billing logic we build inside the product, tested like any other code rather than left to a dashboard.