A few years ago, a company in Jakarta or Surabaya would usually look for a software vendor whose office was within an hour's drive. Today many projects run with a team in another city. A distributor in Medan works with developers in Yogyakarta, a clinic in Makassar hires a team in Bandung, and the weekly meeting happens on a video call. Working with a remote software house has become a normal choice.
Distance itself is rarely the problem. Projects usually stall because roles are unclear, decisions take too long, or communication has no rhythm. This article covers how to run a project with a team in another city so it stays on track from kickoff to support after launch.
Upsides and risks of working with a remote software house
The most common reason is a wider choice of teams. You are not limited to vendors in your own city, so you can pick the team whose experience sits closest to your problem, such as ordering systems for distributors or patient registration for clinics. Cost structures can differ as well. Office and staffing costs vary from city to city, and that sometimes shows up in proposals. Price still should not be the only factor.
The risks deserve an honest look too. Misunderstandings happen more easily when most conversations are written. A team in another city cannot see how your warehouse or cashier counter actually works. And if the vendor is not disciplined, you can lose sight of progress for weeks. Almost all of this can be managed with clear working agreements from the start.
Kickoff and roles
Kickoff can happen entirely online. One video call of one to two hours is usually enough to agree on goals, go through the scope, and set a schedule. If the project touches many parts of the company, an on-site visit at the start can help, but it is optional.
Two things matter most at this stage: a written scope and a single decision-maker. The scope document does not need to be long. A list of features, who will use them, and what is out of scope for the first phase is enough. The decision-maker is one person on your side who can approve designs, set priorities, and answer the team's questions. In a notary office, that might be the notary or a senior staff member they appoint. Without this person, feedback from several people tends to conflict and the team ends up waiting.
Communication rhythm during the project
Remote projects work when everyone knows when updates will arrive and through which channel. A common setup looks roughly like this.
- Regular demos. Every one or two weeks the team shows working software over a video call, so you can click through it and give feedback right away.
- A shared project board. Trello, Jira, Linear, or a similar tool you can open at any time to see what is in progress, what is done, and what is waiting on you.
- WhatsApp or email for quick things. Short questions, files, small confirmations. Agree on reasonable response hours so nobody is on call at night.
- Scheduled meetings for decisions. Scope changes, feature priorities, and anything that affects cost are discussed in a meeting and written down. Chat is fine for reminders.
- Notes after each meeting. A short summary of decisions and next steps, sent the same day.
Keep time zones in mind as well. Indonesia has three of them: WIB, WITA, and WIT. A team in Yogyakarta works on WIB. A client in Makassar or Bali is on WITA, one hour ahead, and a client in Jayapura is on WIT, two hours ahead. The gap is small but worth stating. A 9:00 WITA meeting starts at 8:00 in Yogyakarta. The simplest habit is to write the time zone on every invite.
Access, security, and handover
Decide early which accounts the team needs, for example hosting, the domain, Google Play or the App Store, and the payment gateway. Keep the main accounts in your company's name and add the developers as users. That way you can remove access at any time without losing control. Avoid sending passwords over chat. Use a password manager or the service's own invite feature.
Share only the data the team actually needs. If they need sample customer data for testing, it can be masked first. This also fits the intent of Indonesia's Personal Data Protection Law (UU PDP, Law No. 27 of 2022), which expects companies to look after the personal data they hold.
Before launch, ask for a complete handover. That means source code in a repository you own, technical documentation, a user guide, and a list of accounts with their owners. After launch, agree on how support will work, including a bug-fix warranty period, how to report problems, and response times for serious issues. Remote support is usually enough, because most fixes happen on the server and in the code.
When an on-site visit is worth it
Some moments are hard to replace with a screen. The first is process mapping. Watching how goods move through a distributor's warehouse, how patients queue at a clinic, or how a branch cashier closes a shift often reveals details that no document mentions. The second is user training, especially for staff who are new to the app. One day of training on site can prevent a lot of questions in the first week after launch.
A visit also helps when the project covers several branches with different habits, or when physical devices such as receipt printers and barcode scanners are involved. Otherwise, online meetings are usually enough. Travel costs are best discussed at the proposal stage so they do not come as a surprise.
Working with Averoa
Averoa is based in Kotagede, Yogyakarta, and has been building software for businesses across Indonesia since 2019. Projects can run fully online, with in-person meetings arranged when they are needed, such as for training or process mapping. You can read how we work on the Custom Software Development page.
