2mrwlabs Say hello

Build the thing tomorrow needs.

2MRWLABS is a small product studio in Bristol. We help teams turn early ideas into mobile apps and websites people return to, then keep them running when the light changes.

The short version

We prototype quickly, test with real people, and only then build properly.

Experiments are cheap; finished software is not. So we spend the early weeks learning what deserves to exist, and the later ones making it solid. Everything we try is written down, including the ideas we threw away and why, so the reasoning survives long after the meeting where it was decided.

We work with founders, small companies and teams inside larger organisations who have an idea, a half-working product or a hunch that software could fix something. We design, build, publish and maintain. We do not sell templates, and we do not hand over a product without the means to run it.

What we make

Four ways into the lab

Mobile apps

iOS and Android products, from first prototype to store release. One cross-platform codebase when it serves you; native Swift and Kotlin when the camera, Bluetooth or background tasks demand it.

  • Test builds you install on your own phone
  • Designed offline, empty and error states
  • VoiceOver and TalkBack checks
  • Source code and accounts in your name

Suits products people use often, on the move. Apps in detail

Websites & web apps

Company sites, content platforms with editors and search, and browser-based tools with logins and data. Fast on modest phones and easy to keep current.

  • Accessible, semantic structure
  • A page-weight budget we stick to
  • Forms that keep your input after errors
  • Hosting and backups in your accounts

Suits reaching everyone, or testing demand cheaply. Web in detail

Interface design

Interviews, journey maps, sketches and clickable prototypes tested with real people. We change what confuses them, not what we merely dislike.

  • Research notes and findings
  • Tested prototype
  • Component system with every state
  • Accessibility designed in, not audited on

Suits new products, or existing ones people struggle with. Design in detail

Launch & aftercare

Developer accounts, store listings, privacy declarations and reviewer notes; domains, certificates and redirects for the web. Then maintenance on a rhythm that suits you.

  • Honest data declarations
  • Rollback plan before go-live
  • Monthly updates and yearly platform work
  • A clear way to report faults

Suits anything going live, or already live. Launch desk

Illustrated harbour skyline at dusk with a large low sun and a person on a bridge holding a phone Illustrative generated image
Where we work

From Bristol, mostly on a call

The studio is registered in Bristol, and most of our work happens remotely: shared boards, recorded demos, written notes. That means you can work with us from anywhere in the UK, and you always have a written record of what was agreed.

Office hours are Monday to Friday, 09:00–18:00 UK time. Meetings in person are arranged in advance.

Sticky notes and index cards arranged in three columns on a sunlit window
Illustrative generated image
How an experiment runs

Questions first, code second

Every engagement starts with a question worth answering: will people trust this enough to sign up? Is the slow part of the job the one we think it is?

  1. Name the risk. Which assumption would hurt most if it turned out wrong?
  2. Design the smallest test. A paper sketch, a clickable prototype or a narrow working build.
  3. Watch real people. A handful of sessions usually shows the pattern.
  4. Decide together. Carry on, change course or stop, and write down why.

Stopping early is a good outcome if it saves you building the wrong thing.

How we ship
Try the planner

Sort tomorrow into horizons

Drop your feature ideas into Now, Next or Later. It is the exercise we run in our first workshop, and it works just as well on your own: anything that is not needed for the first release can wait until that release is teaching you something. Nothing is sent to us.

Now

Needed for the first release

    Next

    Once the first release is learning

      Later

      Worth keeping, not worth building yet

        Your ideas are kept on this device only if you accept optional storage.

        After dark

        How much looking after will it need?

        Shipping is the start of the day, not the end. Tick what applies to your product and the sizer suggests a level of aftercare, with the reasons. It is a rule of thumb, not a quote.

        Your product has…
        Field notes

        Worth reading by lamplight

        GOV.UK Service Manual

        Clear guidance on researching and designing services. gov.uk

        Material Design 3

        Google's design system, useful for Android conventions. m3.material.io

        NCSC Small Business Guide

        Practical security for small organisations. ncsc.gov.uk

        All field notes, searchable

        Questions

        Before you say hello

        Do we need a finished brief?

        No. A paragraph and a few examples of what frustrates you today is plenty. Shaping the brief is part of the work.

        Will you build anything we ask for?

        We will tell you if we think a simpler or cheaper route exists, and explain why. You decide.

        Who owns the code?

        You do, from day one: repositories, developer accounts and hosting are set up in your name.

        Can you support a product someone else built?

        Usually. We start with a review of the code, dependencies and release process, then tell you plainly what we find.

        When do you reply?

        Monday to Friday, 09:00–18:00 UK time.