Premise
Tertium Labs researches, designs, builds and looks after mobile apps and websites. When a decision arrives framed as a choice between two imperfect options, we test the framing before we pick a side.
Tertium quid is Latin for “a third something”: the thing that is neither of two known positions but resolves the tension between them. We named the studio after it because most software briefs reach us as a binary. App or website? Build or buy? Launch now or wait until it is right?
Both sides of those questions are usually reasonable. That is exactly why arguing between them rarely helps. What helps is evidence: who will use the product, how often, on which device, and what they are trying to get done. With that in hand, the shape of a better answer tends to appear.
We design and build iOS and Android apps, websites and web applications. We run the research and interface design that decides what those products should be. We help publish them to the App Store and Google Play or put them live on the web, and we maintain them afterwards.
Test the question before you choose the answer.
Early on you will hear a lot of questions from us, and you will see your assumptions written down and sorted by how risky they are. In the middle you will receive working builds at regular intervals, each with a short note on what changed and what we learned. At release, you will get a checklist rather than a celebration.
Throughout, everything we make is held in your name: code repositories, developer accounts, designs and documentation. You can continue without us at any point, which we think is the only honest basis for working together.
Pick a familiar product dilemma. The explorer shows the two positions people usually argue about, and the kind of third option our research often points towards. These are general patterns, not advice for your specific case.
Illustrative generated image
Before anything is built we watch people attempt the task, reframe the problem from what we see, sketch widely, and test clickable prototypes with a handful of participants. The output is a tested design and a documented set of components, so the build matches the intent.
Cross-platform where a single codebase serves you well; native Swift and Kotlin where hardware or performance demand it. Signed test builds throughout, accessibility checked with VoiceOver and TalkBack.
MobileCompany sites, content platforms and web applications with logins and data. Semantic, quick on modest phones, and built with as few dependencies as the job allows.
WebDeveloper accounts in your name, honest store listings, privacy declarations built from a data inventory, and website launches with a rollback plan.
PublishingMonthly dependency and security updates, yearly operating-system compatibility work, and a structured way to report faults. Choose maintenance only, maintenance with an improvement allowance, or work quoted on request.
Every engagement ends with a handover complete enough for another team to continue: code, credentials, designs, a dependency register and a maintenance guide.
SupportEvery feature is a bet that something will change for someone. We write that bet down before estimating it, which makes priorities easier to argue about and easier to drop. Draft one below; nothing is sent to us.
Drafts persist on this device only if you accept optional storage.
You describe the problem. We ask what is known, what is assumed and what nobody knows yet, and write the answers down.
You receive a short assumptions list, sorted by risk.
A discovery period of research and prototyping. It may confirm the brief or change it, which is the cheapest moment for change.
You receive hypotheses, a tested prototype and a scoped plan.
Short cycles, each ending with a working demonstration you can install or open, and a note on progress, learning and risk.
You receive builds, cycle notes and a decision log.
Testing against an agreed device list, accessibility checks, store submission or go-live, monitoring and a rollback plan.
You receive a release checklist and live product.
Maintenance and improvement, or a clean handover to your own team.
You receive documentation and everything in your name.
Live software drifts as operating systems, browsers and libraries change. Support keeps it current; a clear report gets faults fixed quickly. We read requests Monday to Friday, 09:00–18:00 London time.
Report a faultPlease leave out passwords and your customers' personal data.
Accessibility is a design input
The W3C’s WCAG 2.2 overview explains the standard we design and test against, in readable terms. W3C WAI
Read the rules before you design
Apple’s App Store Review Guidelines shape what an iOS app may do. Reading them early saves rejections later. Apple Developer
Collect only what you need
The ICO’s UK GDPR guidance covers data minimisation, lawful basis and retention. ico.org.uk
We will build to an agreed specification, but we will question it first. If research suggests a different approach, we explain why and you decide.
No. If you already have evidence and tested designs, we review them and move to building. If not, a short discovery is usually cheaper than building the wrong thing.
You do. Repositories, developer accounts, hosting and designs are created in your organisation's name from the start.
Nobody can; Apple and Google decide. We prepare thoroughly, answer reviewers promptly and never promise a date that depends on their queue.
Our City Walk address is for correspondence. We work mainly remotely and arrange in-person sessions in advance.
Yes. We begin with a review of code, dependencies, accounts and release process, then report what is sound and what is at risk.
Tell us what you are trying to decide or build. We reply in working hours with questions, a framing, or a suggested first step.
team@tertiumlabs.link
+44 7888 619205
Monday–Friday, 09:00–18:00