How a three-person team ships a release

By Darko Bačić, founder of App Tube · 9 October 2026

A three-person team can ship a release in five plain steps, with no release meeting. You do not need sprints or a release manager. You need a scope, one cut and a few real phones. We make devBoard, so this is our view.

A release is a named batch of work that ships together, like version 1.4.0. What a release is explains the term. Here is how Luka, Mira and Ivan ship 1.4.0 of a client's shopping app. It is one of the opinion pieces on our blog.

Pick the scope

Write one line that says what the release is for. Theirs is "New checkout, and the two crash fixes." That line decides what goes in.

Then add the tasks. Five come from the new checkout epic. An epic is a big piece of work split into smaller tasks. Two more tasks are bug fixes. Set a target date, and tell the client. Anything that does not fit the line goes in the next release. Dark mode is a good idea. It is not 1.4.0.

Cut it once

A week before the date, look at what is left. Ask one question of each card. Will it be done and tested in five days? If not, move it to 1.5.0.

Do this once. Then stop cutting, and stop adding. A team that trims a little every day never knows what it is shipping.

Here is their board on the day of the cut:

• Done: Design the checkout screen. Build the cart summary. Fix the crash on sign-in. Fix the crash on old Android phones.
• In review: Add Apple Pay, built by Luka.
• In progress: Add Google Pay, with Ivan. Show a clear error when a card fails, with Mira.
• Moved to 1.5.0: Save a card for next time.

Three cards left, three people, five days. That is a release. If your board looks nothing like this, start with kanban for a team of three.

Test on real devices

A simulator is a fake phone on your computer. It is good for building. It is bad at showing what users will see. Payment sheets, slow networks, small screens and old phones all act differently on the real thing.

So swap phones. Luka built Apple Pay, so Ivan tests it. Ivan built Google Pay, so Luka tests it. Mira tests on the oldest phone in the office. Each bug they find becomes a task. It goes in 1.4.0 if it must be fixed now, or in 1.5.0 if it can wait.

Ship

One person presses the button. For this studio that is Mira, because she talks to the client. She sends the builds to the App Store and Google Play. Both stores let you release to a small share of users first. Use that.

Do not ship on a Friday afternoon. If something breaks, you want the next day to be a work day.

Write it down

Mark the release as shipped. Then write three lines where the whole team can see them: what shipped, what moved to the next release, and what broke. This takes five minutes. In six months, it answers "when did we change the checkout?" in five seconds.

Then open 1.5.0. "Save a card for next time" is already waiting.

Where this argument is wrong

This plan is for apps that ship in versions, through a store, every few weeks. A website that ships many times a day does not need releases like this. Each change goes out when it is ready.

It also assumes the three of you decide the scope. If a client's contract sets fixed sprints and a review every two weeks, follow the contract. And if the app handles money or health data, you may need a written test plan and a sign-off. Three people swapping phones is not enough there.

What we did about it

devBoard has releases and no sprints. A release has a name and a target date. You add tasks to it, and you mark it shipped when it goes out. A saved view filtered by release shows what is left for 1.4.0 on one screen. devBoard does not write release notes or send builds to the stores. That part stays in your own tools. Releases in devBoard shows the screens, and the guide to planning a release walks through the first one.