BlueHorizon
BlueHorizon Innovations · London Docklands
A small web and mobile application development studio at 1 Canada Square, working with UK product teams on software they intend to run — and explaining every decision that shapes it.
Monday to Friday, 9:00 AM – 6:00 PM · Remote-first, London-based
About the studio
BlueHorizon Innovations is a web and mobile application development studio based at 1 Canada Square in London. We work with UK businesses on products they intend to run, not demonstrations they intend to present.
The studio is deliberately small, which means the people who scope your project are the people accountable for it. What follows explains how we work, what we build, and what we expect from a collaboration — so you can decide whether it fits.
How the studio is built
Four plates, one studio. Each one is a decision we made about how the work goes — not a service brochure.
A compact team of developers and designers working out of the London Docklands, close to Canary Wharf. We take on a limited number of projects at once — a constraint we chose rather than one imposed on us. It means clients get attention from people who know the codebase, not a rotating cast.
We hire for the ability to reason about a problem and explain it plainly, because both matter more than familiarity with any particular framework.
We build web applications and mobile applications: portals, dashboards, internal tools, marketplaces, cross-platform releases.
We do not run a general digital agency service, we don't do SEO retainers, and we're not the right call for a five-page brochure site. Saying no to work outside that range keeps the work inside it good. If your project sits outside what we do, we'll usually be able to suggest who does it well.
In range: web portals, dashboards, internal tools, marketplaces, cross-platform mobile
Out of range: brochure sites, SEO retainers, ad campaigns, social media management
Technical decisions here follow from constraints, not preference. What stage is the product at? Who maintains the code in two years? Which platform matters most to users? Those questions eliminate most options before anyone argues about frameworks.
Where there's a genuine trade-off, we write the reasoning down so it can be challenged later. Decisions that can't be explained are usually decisions that were made for the wrong reasons, and the cost arrives in year two.
Our office is at 1 Canada Square, E14 5AA, and we're happy to host a kickoff meeting or a workshop there. Most day-to-day collaboration happens remotely, since that's how distributed teams work well together.
We keep communication plain: a shared channel, a weekly written update, and no ceremonial status theatre. If something is behind or a decision needs to be revisited, we say so early rather than at the deadline.
Contact the studioWorking together
Four positions on the engagement — the parts of working with a studio that clients ask about most, answered plainly.
Shape of engagement
Capacity, second opinion, or one specific piece of the build.
Where it earns time
Boilerplate, test scaffolding, refactors, documentation — reviewed at the same rigour as anything else.
Coverage
Maestro for mobile flows before a release; web builds cover the critical paths and integrations.
Two things
Reachable decision authority, and an honest brief including the untidy parts.
Not every project needs a full studio. Some clients have developers already and need extra capacity, a second opinion on architecture, or someone to take a specific piece of the build.
We work alongside in-house teams regularly, and it changes the shape of the engagement: fewer handoffs, more direct collaboration between developers. The code gets reviewed by both sides, which tends to raise the standard rather than slow it down.
Mobile UI testing gets automated early with tools such as Maestro, covering the flows that matter most before a release goes out. Web builds get their own coverage around the critical paths and integrations.
Automated tests don't prove software is good. They prove the scripted flows still work, which is a different and still useful claim. The judgement call about whether something is ready sits with people, not with a green checkmark.
AI tooling has changed what a small team can carry, mostly on the parts nobody enjoys writing: boilerplate, test scaffolding, refactors, documentation. We use it where it genuinely saves time, and we review what it produces with the same rigour as anything else.
What we don't do is ship code nobody understands. A studio's value isn't typing speed; it's knowing which decisions will still look sensible when the product has real users.
Two things, mostly. Someone with authority over the product decision should be reachable, so questions don't travel through relays. And the situation should be described honestly, including the parts that are untidy.
A brief that says "we do this manually today and it breaks weekly" is worth more than a polished feature list, because it tells us what the software actually needs to replace.
Principles
Four principles, written down. Not slogans — the specific failures they exist to prevent.
Maintainability
Software should be maintainable by someone other than its author. Code that only makes sense to the person who wrote it is a liability the moment the engagement ends.
Scope
Scope should be written down before work starts. Verbal agreements drift into different projects within a month, and the drift is always paid for somewhere.
Estimates
Estimates should reflect uncertainty rather than hide it. A range with its assumptions is more useful to plan against than a confident single number.
Drift
A project that starts without them doesn't fail dramatically. It just drifts, and drift is expensive — quietly, and then all at once near the release date.
"A studio's value isn't typing speed. It's knowing which decisions will still look sensible when the product has real users."
BlueHorizon Innovations · 1 Canada Square, London
Where the work goes
A real project type from the studio's range, walked at the level of detail that matters for a decision.
Representative engagement
The brief arrived as a stack of spreadsheets and a dispatch process that had grown by hand. We rebuilt it as a single web portal with role-based views, ran the critical-path automation alongside the existing process for a fortnight, and handed the codebase to the client's own two-developer team with the reasoning written down alongside the release notes.
Named on the project
Two BlueHorizon developers, paired with the client's in-house engineering lead
Read our case studiesYou'll get in touch with
The developer who would scope the work — not a sales layer between you and it.
First reply looks like
A considered answer to what you described, including a direct yes or no.
What follows a yes
A short discovery or a call, not a proposal deck and not a sales sequence.
How to start
Send a description of the situation and what you're trying to change. We'll tell you whether it's something we should take on and, if so, suggest a short discovery or a call. You'll get a considered reply rather than a sales sequence, and if we're not the right fit, we'll say so directly.