Choosing a Software House in Indonesia: 12 Key Questions

Choosing a vendor to build your app is like choosing a contractor for your house: you'll live with the result for years, yet the decision is often made after one or two meetings and a single-page quote. This article is our checklist for choosing a software house, put together so you can evaluate any vendor fairly, including us.

There are 12 questions. Not all of them need a perfect answer, but each answer tells you a lot about how that vendor works.

12 questions to ask before you sign

1. Who exactly will work on my project?

Ask for the names and roles of the people who will actually write the code and do the design, not just the salesperson. Also ask: is this done by an in-house team or passed on to a third party? Subcontracted work isn't always bad, but you have the right to know, because it affects the quality of communication and accountability.

2. Can I see products you've built?

A portfolio made of client logos is easy to assemble. What's harder to fake: a product you can open and try yourself. Vendors who build their own products (not just client projects) usually have a better feel for what maintaining an app long-term is really like, because they bear the consequences of their own poor technical decisions.

3. What's your process, and how often will I see progress?

A healthy answer describes clear stages and a regular demo rhythm, weekly for example. If the answer is "we'll let you know when it's done," that's a major risk: you only find out something's wrong after three months. A reasonable picture of the stages is in the SDLC explained for business owners.

4. Who owns the source code, repository, and accounts?

This is the question most often skipped and the most expensive to get wrong. Make sure, in writing:

• The source code and repository belong to your business once payment is complete.
• Domain, hosting, cloud accounts, app store accounts, and third-party services are created in your business's name, not the vendor's.
• You have admin access to all of them, not just the vendor.

If you ever want to switch vendors, this is what decides whether that takes a week or turns into a disaster.

5. What do I receive besides the app?

Technical documentation, deployment instructions, the database structure, and a list of accounts. Without these, the next vendor (or your future in-house team) has to guess. Ask to see sample documentation from a previous project if possible.

6. How do you test the app?

"We test it manually before delivery" isn't enough on its own for an app that will be used for years. Ask whether there's automated testing, code review between team members, and what happens when a bug appears after release. Vendors who treat testing as a default rather than an add-on cost tend to deliver more stable apps.

7. How are estimates made, and how do I pay?

Two common models:

Both are legitimate. What's problematic is a fixed price for unclear scope: one side is guaranteed to lose. Ask for a breakdown of what's included in the price: design, testing, deployment, training, how many rounds of revisions. For a deeper look at cost structure, read how much an app costs in Indonesia in 2026.

8. What happens after the app launches?

An app isn't finished at launch. Operating systems get updated, third-party services change, new bugs surface. Ask: is there a bug-fix warranty period? How long? After that, what's the maintenance arrangement and what does it cost? A vendor with no answer here may not be planning to be around when you need them.

9. How is my customers' data protected?

Ask where the data is stored, who has access, how passwords and sensitive data are encrypted, and whether there are regular backups. If your project involves AI, also ask what data gets sent to the AI model provider. A serious vendor will have concrete answers, not "don't worry, it's safe."

10. What does day-to-day communication look like?

Through what channel (WhatsApp, email, a project management tool)? How quickly do they usually reply? Can you talk directly to the engineers, or always through an intermediary? Slow or layered communication is the most common source of projects running late.

11. If we part ways, what happens?

An uncomfortable question, but an important one. Is there a handover process? Are the code and accounts handed over in a state another vendor can pick up? Is there a "ransom" fee? A vendor confident in the quality of their work won't mind this question.

12. For AI projects: what have you built with AI, and where are its limits?

If your project involves AI, ask about their real experience: what products have they built with LLMs, how do they handle wrong answers, and how do they measure accuracy. Be wary of vendors who promise AI that's "100% accurate" or "can do anything." An honest vendor will explain the limits, as we do in our articles on WhatsApp AI chatbots and RAG for business documents.

Honest note: we're not perfect on every point here either. As a young company, our client portfolio isn't long yet; what we can show are the products we've built ourselves, Cuplikin and KosPro, and the open way we work. We'd rather you know that up front than discover it later.

Red flags to watch for

A few signs that, in our view, should make you think twice:

• A price given within 10 minutes without asking for details. A good estimate requires understanding the scope.
• Every feature gets a "yes, we can." No vendor can do everything. An honest one will tell you what's easy, what's hard, and what's better left undone.
• Refusing to give you access to the repository or accounts. This is deliberate lock-in.
• No demos or visible progress for weeks on end.
• Pressure to sign immediately with a discount "valid today only."
• Can't explain technical decisions in language you understand. You don't have to grasp everything, but a good vendor can explain the "why" simply.
• Never says "no." A vendor who agrees to every mid-project request without discussing the impact on timeline or cost is storing up problems for later.

How to compare quotes fairly

Three quotes at Rp 40 million, Rp 90 million, and Rp 200 million (roughly $2,500, $5,600, and $12,500) for "the same app" are almost certainly not the same app. To compare fairly:

1. Equalize the scope. Write the core user flow and a Must/Should/Could feature list, then send the same document to every vendor. How to put it together is in MVP vs full product.
2. Make a table of what's included. Design, testing, deployment, documentation, training, warranty, maintenance. Ticks and crosses are more honest than a single total.
3. Compare assumptions, not just prices. A vendor who writes out their assumptions clearly ("payment integration with one provider," "a maximum of 3 design revisions") is more accountable than one who writes a single number.
4. Count the 2–3 year cost, not just the build cost. Maintenance, servers, third-party subscriptions. A cheap quote with expensive maintenance can cost more in total.
5. Notice the quality of their questions. A vendor who asks a lot about your business before quoting usually understands better what they're about to build.

Freelancer, software house, or in-house team?

For completeness, a software house isn't the only option:

For small businesses without technical staff, a software house or an experienced freelancer with a clear process is usually the most sensible choice. An in-house team makes sense once the product is proven and needs continuous development.

Next steps

Keep these 12 questions and put them to every vendor you're considering, including us. If you'd like to try, tell us about your app plans in a free initial consultation and ask anything from this list. See our services, then send a message through the contact form or chat on WhatsApp.