How We Actually Ship at Mangobaz: Process, Tools, and a Cat
This one is different from the technical pieces on this site. It is a behind-the-scenes look at how we actually ship software at Mangobaz — the process, the tools, and the small habits that add up to a working studio. If you are thinking of starting your own product studio, or if you are curious what a small team looks like in practice, this is the article.
I am writing this from a desk in Lahore, on a Friday afternoon, with a half-finished mug of coffee. We are a two-person team plus a cat, and we have been shipping client work and our own products for about six years now. Here is what works for us.
The week starts Monday, not Sunday
Most productivity advice tells you to plan your week on Sunday evening. We do not. We plan on Monday morning, together, in a 30-minute call. By the end of it, every active project has a clear list of what is getting shipped this week and who is doing what.
This works for two reasons. First, Monday morning is the only time we are both guaranteed to be fresh and not in the middle of something. Sunday planning fights with weekend rest. Second, planning together means we are both bought in. There is no "I thought you were doing that" later in the week.
The plan lives in a single shared document. It has columns: this week, next week, backlog. Anything not on the page is not real. We do not use Jira, Asana, Linear, or any of the other tools. We tried them. They added overhead. A shared Google Doc works better for two people than a dedicated PM tool.
We work in two-week cycles, not one-week sprints
One-week sprints are too short. By the time you have set up the work, done the work, and reviewed the work, the week is over. Two weeks is the minimum cadence that lets us do all of that without feeling rushed.
At the end of each two-week cycle, we do a short retro. What went well, what did not, what do we change. The retro is 20 minutes. Anything that would take longer to discuss gets pushed to "next cycle's planning."
This is unglamorous. It is the kind of process that nobody talks about on Twitter. It works because it is consistent. We have been doing the same loop for years. The cadence is the value, not the specific format.
Code review is on the same day
If you push code on Friday and the review happens on Monday, you have lost three days of context. We have a rule: pull requests opened before 2pm get reviewed the same day. After 2pm, the next morning. The review itself should take 15-30 minutes for a typical change. If it is taking longer, the change is too big. Break it up.
Reviews focus on three things: does it do what it says, is it testable, and will I understand it in six months. We do not get into bikeshedding about naming or formatting; we have a linter and pre-commit hooks for that. The review is for the things the linter cannot catch.
We deploy multiple times a day
Every commit to main goes through a CI pipeline and lands in production within five minutes. There is no "release day." There is no "freeze." The fastest path from "I fixed it" to "users have the fix" is direct, and we have spent a lot of effort making it that short.
The pipeline does four things. Run the linter. Run the test suite. Build the artifact. Deploy to the server. The whole thing is visible on a wall-mounted monitor in the office. Green dots, mostly. When it goes red, someone looks at it within 60 seconds.
This is not unique. Most modern teams do this. The reason it is worth saying: it took us about two years of incremental work to get to this point, and most of that work was on the boring parts (test suite, build pipeline, deployment scripts) that you skip when you are in a hurry. The compound effect of doing it right is that every new feature we ship moves faster than the last one.
Tests are not a phase
We write tests as we write code, not after. A feature is not "done" when the code is pushed. It is done when the code is pushed, the tests are written, the tests are passing, and the feature works in production. All of those are part of the same commit. There is no separate "testing" task on the board.
This is not "TDD" or "BDD" or any other acronym. It is just the habit of leaving the code slightly better than I found it, every time. Sometimes the tests come first. Sometimes they come second. What is non-negotiable is that they exist before the work is "done."
The test suite has about three to four times as much code as the production code. That ratio is normal. It is what gives us the confidence to deploy at 4pm on a Friday without flinching.
We say no to most things
The most important skill in a small studio is saying no. We say no to most client work that comes in. We say no to most feature ideas. We say no to most "quick wins" that turn into weeks. The things we say yes to get our full attention. The things we say no to never become a distraction.
This is harder than it sounds. There is a real cost to saying no to a paying client. There is a real cost to ignoring a feature request from a long-time user. But the alternative is a queue of half-finished things, and a team that is constantly switching context. We have done that. It is worse.
Our rule: if a new request would push any active project back by more than a week, we either say no or we explicitly drop something else. Nothing gets added without something else coming out. The cycle stays the same length. The team stays the same size. The quality stays the same.
Communication is mostly async
We are not in the same room every day. We use a chat tool for quick questions, a shared doc for long-running discussions, and a weekly call for the things that really need real-time conversation. The default is async. Sync is the exception.
This is not because we are remote-first (we are not, we share an office). It is because async communication respects time. When you ask a question in chat, the other person can finish what they are doing before answering. When you interrupt someone with a verbal question, you have broken their flow for what is, in retrospect, often a 30-second thing.
The exception is design reviews and architecture decisions. Those are real-time, with a whiteboard or a screen share, because the back-and-forth is the point. For everything else, async is faster, even if it feels slower at the moment of asking.
The cat is non-negotiable
Our cat Mango sits on whichever keyboard is warmest. She has caused at least three production incidents by sleeping on a key. We do not regret any of them. The cat is a feature, not a bug.
This is a joke, but only halfway. A studio that has no room for the small absurdities of being alive is a studio that is going to burn out its people. We do not optimize for maximum output. We optimize for being able to do this for another ten years. That means coffee breaks, walks, an actual lunch, and a cat on the desk.
What this all adds up to
A two-person team that ships a lot, sleeps enough, and has been doing this for a while. The processes above are not clever. They are the standard practices of a well-run small team, applied consistently over years. That is the whole secret. There is no hack. There is no magic tool. There is just the daily choice to do the boring things well, and to protect the time to do them.
If you are starting your own thing, do not copy anyone's specific tool or process. Pick one boring habit, do it for 90 days, and add another. Within a year, you will have a studio that runs the way you want it to. That is what worked for us. Hopefully some part of it is useful for you too.
Frequently asked questions
Where is Mangobaz based?
Lahore, Pakistan. We work with clients in the US, UK, EU, and the Middle East. Time zone overlap with European clients is the easiest part of the day; US clients usually means an early start or a late finish.
What kind of work do you take on?
Custom web applications, admin panels, customer portals, and the odd DevOps engagement. We do not do marketing sites, mobile apps, or design-only work. The narrow focus is on purpose; we would rather be excellent at one thing than average at five.
How do I get in touch about a project?
Use the contact form on the site. We reply within one business day, usually faster. For very small jobs, we will tell you honestly that we are probably not the right fit and suggest someone else.
Related articles
← More in Studio Notes