mbranch SIA FqvB

Riga, Latvia / Two developers

We build software that still works the way you expected it to six months after launch.

mbranch is a two person studio. Emils leads the build, Georgiy takes the groundwork and reviews everything that goes out. We take on a handful of projects a year, which is a limit we picked on purpose: the person who wrote your code is the person who answers when it breaks.

Practice
Web and mobile products
Team
Two developers, no account managers
Base
Riga, Latvia, working across the EU
Entity
SIA FqvB
release/2.14 7 commits
How a change reaches production at mbranch main split billing out of checkout retry the webhook, not the job cover the partial refund path fix the invoice timezone reviewed by georgiy merge release/2.14 deployed 14:02, nobody noticed
Every change is read by the other one before it goes anywhere near production. That is the whole quality process. It has been enough so far.

What we do

Four kinds of work, and nothing outside them

If your project is not one of these, we would rather say so on the first call than three weeks into an invoice.

  1. 01

    New products, built from nothing

    You have a business that works and a process that has stopped scaling. We build the first real version, put it in front of actual users, and keep changing it while you find out what it needs to be. The first version is deliberately small.

    • Scoping
    • TypeScript
    • PostgreSQL
    • Deployment
  2. 02

    Codebases somebody else left behind

    A contractor stopped replying. An in house developer moved on. We read what is there, write down what it actually does rather than what the documentation claims, and give you a plan with honest numbers before we change a line.

    • Audit
    • Refactoring
    • Test coverage
    • Documentation
  3. 03

    Applications people actually use on a phone

    Built once in React Native, shipped to both stores, with the offline behaviour thought through early instead of patched in later. We handle the store submissions too, because that part goes wrong quietly.

    • React Native
    • Offline first
    • App Store and Play
    • Crash reporting
  4. 04

    The long quiet part after launch

    Dependencies age, certificates expire, and tax rules change in January. For software we built, we keep a small monthly arrangement so that the first you hear about a problem is us telling you it has been fixed.

    • Monitoring
    • Security updates
    • Small changes
    • On call by arrangement

How a project runs

The same four stages every time

Nothing here is unusual. It is written down so you can hold us to it.

  1. 01

    A call, then a scope in writing

    Thirty minutes to understand the problem, then a document from us: what we would build first, what we would leave out, what it costs and how long it takes. If the scope is wrong you find out while it is still a document.

  2. 02

    Something running in two weeks

    Not a prototype and not a slide. One narrow path through the product, deployed somewhere you can open it on your phone. It is usually ugly. It is also the point at which most assumptions get corrected.

  3. 03

    A build you can click every second Friday

    Fortnightly, with a short written note on what changed, what we got wrong and what is next. You can redirect the work at any of those points without renegotiating anything.

  4. 04

    A handover written as though we leave

    Repository, infrastructure, accounts and a document that explains the parts a new developer would get wrong. We would like to keep working with you. You should not be stuck with us to keep the thing running.

Who you get

Both of us, on your project, for the whole of it

There is no bench and no team we scale up from. When you hire mbranch you get the two people below, which is why we are careful about how much we take on.

  • Portrait placeholder for Emils Gustavs Sangovics

    Emils Gustavs Sangovics

    Lead Developer

    Owns the architecture and writes the code that touches money, sessions and anything you cannot afford to lose twice. If you book a call, you are talking to him.

  • Portrait placeholder for Georgiy Furanets

    Georgiy Furanets

    Junior Developer

    Interface work, test coverage and the unglamorous parts of a release that decide how Monday morning goes. He reviews every pull request Emils opens, which is an arrangement we both wanted.

Next step

Thirty minutes on a call tells you more
than any proposal document will.

Bring the problem in whatever shape it is in. Half a spec, a spreadsheet that has outgrown itself, a codebase nobody wants to open. We will tell you what we would do first, and whether we are the right people to do it.

  • No sales call, you speak to the developers
  • Thirty minutes, video or phone
  • A written summary from us within two days
  • We say no when the fit is wrong