Web platform development in Edinburgh
Every August, Edinburgh's festivals fill the city for a few weeks, and then demand for tickets drops away. Ticketing, venue management, performer registration, listings and box office systems all have to handle that peak, and most are run by organisations that cannot afford to pay for peak capacity the rest of the year.
We build web platforms for events and venues that plan for the spike: listings served from cache, ticket inventory that never oversells when thousands of people want the same show, and queues that are fair when demand outruns supply. We load-test against the shape of a real on-sale, keep the infrastructure small for the other eleven months, and make sure the box office still works when the internet at the venue does not.
Edinburgh is a money town with a major research university in the middle of it, and its software work reflects both. On one side sit the fund managers, life and pensions firms and banks: Baillie Gifford, NatWest Group's headquarters at Gogarburn, and a long tail of platforms, administrators and wealth managers. On the other side sit the University of Edinburgh's informatics and data science groups, and EPCC, which hosts the national supercomputer ARCHER2 and was chosen in 2025 as home for the next one, with up to £750 million of government funding.
The financial side needs systems that are careful rather than fast. Pension and investment products carry decades of rules, and much of the administration runs on platforms that predate the people maintaining them. Customers expect to see their pot, their charges and their options clearly on a screen, and advisers expect the platform to answer as fast as the one they used yesterday. So the work is usually integration, data, reporting and customer screens around an old core, with every change tested before it ships. Fintechs sit in between, often selling back into those same banks and fund managers.
The university side needs something different: research code that works on a GPU in a lab and has to become a product that works for a paying customer. That gap, between a model that is right and a service that is reliable, is where many spin-outs stall. Hiring is competitive. ITJobsWatch puts the median advertised software engineer salary in Edinburgh at £70,000 over the six months to September 2026, on a smaller sample than London, and the banks and fund managers take many of the experienced engineers.
Working with us from Edinburgh fits the day you already have. Four hours of every working day overlap with yours, set across your morning, so stand-up, review and the decisions that follow happen live with the engineer who writes the code. The rest of the day runs on written updates and pull requests in your own Slack, GitHub and Linear, waiting for you after lunch, with runbooks and architecture notes written as the work goes.
We are the right fit for a defined piece of work, a spin-out's first production system, or a project that needs senior engineers this quarter while your own hiring catches up. Start with a fixed-price two-week piece and judge us on what ships. For agencies, we work white-label under your name, in your repositories and tools.
Four ways this arrives.
We replace the role column with a permission model that can express teams, access to individual resources and roles the customer defines, add SAML or OIDC sign-in, and write the audit log their security questionnaire will ask about.
Or very nearly did. We find every query that can cross a tenant boundary, enforce the tenant in one layer rather than in every handler, and add tests that try to read across that boundary on purpose.
We build the admin side properly: search across organisations, an audited view-as-user mode, and screens for access and usage. Support stops asking an engineer to run a query against production every time a customer says something looks wrong.
An early Next.js app with auth stitched into middleware, a custom server, and a release process that lives in someone's head. We move it forward in small steps, with preview environments and a pipeline anyone on the team can ship from.
A Next.js platform scoped per organisation, where an administrator can view the app as any other user and each Tableau report opens only for people granted it.
Read the write-up →Asked by Edinburgh teams.
How do you work with teams in Edinburgh?+
Four hours of every working day overlap with yours, set across your Edinburgh morning, so stand-up and code 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. The rest of the day carries on in pull requests and written updates that are waiting for you after lunch, with runbooks and architecture notes written as we go.
Do you build for Edinburgh fund managers and pensions firms?+
Yes. For pensions and investment platforms we build services around the administration core: APIs that expose what it knows, transfers and switches processed exactly once, and tools for the exception cases that live in spreadsheets today. For fund managers we build investment data pipelines that trace every figure back to its feed, research search that cites its sources, and customer screens that make pots and charges clear.
How does your rate compare to hiring in Edinburgh?+
ITJobsWatch puts the median advertised salary for a software engineer in Edinburgh at around £70,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 work with a university spin-out?+
Yes, and it is a good fit. Spin-outs usually have strong research code and nobody whose job is running it in production. The research team stays in charge of the science, and we build what surrounds it: the API, the data handling, the deployment and the monitoring. A fixed-price two-week piece fits a grant or accelerator budget, and the code belongs to the company from the first commit.
What is wrong with a role column?+
Nothing, until you have more than one kind of customer. A role says who a user is; most real questions are about what they can do to one specific thing, inside one specific organisation. Encoded as role checks, every new requirement becomes a code change in many places. We model permissions as data, check them in one place, and test them like any other logic.
Should we use an auth provider or build our own?+
Use a provider for identity: passwords, magic links, SSO and multi-factor. It is a solved problem and getting it wrong is expensive. Authorisation, meaning what a signed-in user may do, is specific to your product and usually belongs in your own code and database. We wire the first to the second and keep the line between them clear.
How do you handle multi-tenancy?+
Usually one database with a tenant ID on every row, enforced in one place: Postgres row-level security, or a data-access layer every query has to pass through, rather than each handler remembering. A separate database per tenant is sometimes right, for one very large customer or strict isolation, and we will say if that applies to you.
Where does it get hosted?+
Wherever suits your team. Vercel is the least effort for Next.js and fine for most platforms. If cost or long-running background work make that awkward, we run it in containers on Railway, AWS or your own Kubernetes. The repository, the cloud accounts and the bill are in your name either way.
What do enterprise customers ask for, and can you build it?+
Single sign-on through SAML or OIDC, audit logs, role management, session controls, encryption and data export. We build each of them into the platform and help you answer the technical questions on a customer's checklist accurately, so the security conversation speeds the deal up instead of stalling it.