Outsource Software Development to Indonesia: A Checklist for Singapore Companies

For many Singapore companies the question is no longer whether to work with a development team outside Singapore, but where. Indonesia comes up often. Jakarta is one hour behind Singapore, a short flight away, and has a large and growing pool of software engineers. The harder question is how to set up the work so that what comes back is software you can run, own and maintain.

This checklist is for Singapore companies that want to outsource software development to Indonesia as a project, rather than hire individual contractors. It covers the engagement model, contract and intellectual property terms, personal data under the PDPA, working across the time zone and communication style, milestones, and handover. A note on where we stand: Etzal Group is a Jakarta company that builds software for clients in Indonesia and Singapore. The checklist applies to any vendor you consider, including us.

Why Singapore companies outsource software development to Indonesia

• Working hours overlap almost completely. Jakarta runs on Western Indonesia Time (UTC+7), one hour behind Singapore (UTC+8). A 10am meeting in Singapore is 9am in Jakarta.
• It is close. Flights between Singapore and Jakarta are short and frequent, so on-site workshops at the start of a project are practical.
• The talent pool is large, and rates are usually lower than in Singapore. Cost should not be the only reason, though. The cheapest team often becomes the most expensive one through rework and delays.
• Regional context. If your product also serves Indonesian customers, a team that knows local payment habits, languages and regulations saves time.

Choose the engagement model first

A project with a vendor. The vendor commits to delivering defined outcomes, usually in milestones. You manage scope and acceptance; the vendor manages the team. This suits companies without an in-house engineering lead.

A dedicated team. You direct the work day to day, and the vendor provides and employs the people. You carry more of the delivery risk and need someone senior on your side to lead.

Hiring individuals directly. This can look cheapest, but it brings employment, tax and social security questions under Indonesian law. If you go this way, get local employment advice, or use a company or employer of record that handles it properly.

The pricing model matters as much as the engagement model. Our guide on fixed price vs time and materials explains which one fits which kind of scope.

Contract checklist

• The contracting entity. Contract with a registered Indonesian company and ask for its registration documents, rather than with a person acting for one.
• Governing law and disputes. Agree which law applies and how disputes are resolved. Many cross-border contracts in the region choose arbitration. Indonesia and Singapore are both parties to the New York Convention on the recognition of foreign arbitral awards, but take legal advice on the wording.
• Intellectual property. Under Indonesia's copyright law (Law No. 28 of 2014, Article 36), unless agreed otherwise, the party that makes a commissioned work holds the copyright. Paying for the software does not transfer ownership by itself. Write the assignment of the code, documentation and designs into the contract, and say when it takes effect.
• Third-party and open source components, listed with their licences.
• Payment terms. Agree the currency, who bears transfer fees, and how any withholding taxes are handled. Ask your tax adviser before signing.
• Confidentiality and non-solicitation, in both directions.
• Exit terms. What the vendor must hand over if the contract ends early, and how long it must support the transition.

Personal data: PDPA and Indonesia's PDP Law

If the vendor will see personal data of your Singapore customers or staff, the PDPA's Transfer Limitation Obligation applies. You must make sure the recipient protects the data to a standard comparable to the PDPA, typically through contract terms. In Indonesia, Law No. 27 of 2022 on Personal Data Protection also applies to the processing done there.

In practice, the safest approach is to keep personal data away from development altogether:

• Use masked or synthetic data in development and test environments.
• Give production access only to named people who need it, and log that access.
• Agree how quickly the vendor must tell you about a suspected breach, so you can meet your own obligations under the PDPA.
• Have accounts closed the day someone leaves the project.

Time zone, communication and the calendar

The time zone is the easy part. The harder part is how problems get raised. In many workplaces in Indonesia, as in much of Asia, people avoid saying no directly to a client or a senior person. "Can do" may mean "we will try". Make bad news easy to deliver:

• Ask open questions such as "what could stop us from finishing this by Friday?" rather than "are we on track?"
• Keep a written risk log that both sides update every week.
• Thank people for raising problems early, and never punish the messenger.
• Make sure the vendor's project lead is fluent in English, and put decisions in writing after every call.

Plan around the calendar too. Indonesia's public holidays differ from Singapore's, and around Idul Fitri many teams take an extended collective leave period. Agree the plan for that period in advance, including who covers urgent issues.

Milestones and visibility

• Bill by milestones that you can test, each with acceptance criteria and payment on acceptance.
• Host the code repository under your own organisation from day one, or at least get read access from the start.
• Ask for a short demo every week on a test environment you can open yourself.
• Run acceptance testing with your own users, not only with the vendor's testers.

Handover and the long run

At the end of the build you should receive the full source code with its history, documentation that lets another team build and run the system, all credentials and accounts in your company's name, and a warranty period for defects. Then agree maintenance terms: response times by severity, what counts as a defect versus new work, and how the agreement can end.

Red flags when choosing a vendor

• A quote that arrives without any questions about your business.
• No named project lead you can speak to before signing.
• No access to the code until the very end of the project.
• "No problem" as the answer to every question about scope and timeline.
• No live systems they have built that they can show you.

At Etzal Group, Enterprise Software projects use milestone billing, with source code ownership on final payment, documentation, and a 30-day warranty before maintenance begins. You can see systems we have built on our work page, and the free consultation is thirty minutes to map the scope, flag the risks, and give you an honest read on cost and timeline.