The Indonesian software development market is fragmented. There are individual freelancers, small studios, mid-sized software houses, and large enterprises all competing for roughly the same projects. Prices vary by a factor of ten. Quality varies by more than that. The signals that look like quality — a professional website, a large portfolio page, impressive-sounding client logos — are often cosmetic.
Most businesses make the decision based on price and presentation. That's why so many software projects go wrong.
Here's what actually matters.
Look at Live, Working Projects — Not Mockups
Any developer can show you screenshots and Figma mockups. Ask for live URLs of projects they've built that are in production use today.
Then use those projects. Log in if they're applications with demo access. Use them on mobile. Try to find the edges — what happens when you submit a form incorrectly? Does it handle that gracefully? How fast does it load? Does it feel polished under actual use, or does it have rough edges that the portfolio screenshot didn't show?
A developer whose portfolio is mostly mockups and designs — rather than live, working systems — is either very new or has a reason for not showing working projects. Both are relevant information.
Ask directly: "Can you share the URL of a project similar to what we need that's currently live?" If they can't, ask why.
Ask for a Client Reference You Can Actually Call
Not a testimonial on a website. Not a logo on a client list. A name and a phone number or email address of someone at a past client who used the system they built.
A good development partner can provide this. A client you can call directly, without the vendor in the room, gives you information that no amount of portfolio review provides. Ask the reference:
- How did the project go relative to the original timeline and budget?
- How did the developer handle problems when they came up?
- What was communication like during the project?
- Are you still working with them? If not, why not?
- Would you hire them again?
These questions, asked directly to a past client, are more predictive of your experience than anything you'll see on a proposal or portfolio.
Watch How They Approach the Discovery Process
Before a developer can quote a project accurately, they need to understand what the project is. A good developer asks more questions than you do in the first meeting.
They should want to know:
- What problem is this software solving?
- Who uses it, and how many users?
- What does the current process look like?
- What systems does this need to connect to?
- What does success look like 12 months after launch?
A developer who hears your general description and sends a quote the same day has not understood your project. They've made assumptions, and those assumptions will surface as scope disputes during development.
The discovery process is not an overhead to minimize — it's how a competent developer builds the foundation for accurate scoping. Be wary of developers who skip it.
Evaluate Communication Quality
Software projects run for months. You'll be communicating with this team weekly, sometimes daily. Communication quality is not a soft preference — it's a project risk factor.
In your early conversations, notice:
- Do they respond promptly?
- Do their messages show that they read and understood yours?
- Can they explain technical concepts in language that's useful to you, without either talking down or retreating into jargon?
- Do they ask clarifying questions, or do they assume?
- When you raise a concern, do they address it directly?
Poor communication during the sales process predicts poor communication during the project. This isn't always true, but it's a reliable enough signal to take seriously.
Clarify IP and Contract Terms Early
Before any proposal is submitted, ask about IP ownership and contract terms. Who owns the code? Is source code delivered at completion? What are the payment milestones? Once you're comparing active proposals, how to evaluate a software development proposal gives you a framework for assessing scope, timeline, and terms — not just price.
A professional software house answers these questions without hesitation — they have standard contracts and clear terms. A vendor who is vague about IP ownership, who wants large upfront payments without milestone structure, or who can't explain their standard contract terms is a risk.
If they push back on assigning IP to you — if the conversation reveals they intend to retain ownership or licensing rights to code built on your budget — that's a disqualifying position.
Understand What Post-Launch Support Looks Like
Ask specifically: "What happens if we find a critical bug the week after launch?"
You want to hear: a defined warranty period, a specific response time commitment, clarity on what's covered as a bug fix (part of the project) vs. what's a change request (additional cost), and a point of contact who knows your codebase.
You don't want to hear: "We'll be available on request" with no further specifics. This often translates to: you'll wait days for a response while your system is broken.
Red Flags Worth Taking Seriously
An immediate quote without any discovery questions. A developer who quotes within hours of hearing a general description has not understood your project — they've guessed at a number.
No clear contract terms. "We'll sort out the paperwork later" leads to disputes where there's no reference document.
Inability to explain their process. If a vendor can't describe how they typically run a project — phases, how decisions are made, how changes are handled — they probably don't have a consistent process.
Overpromising on timeline. A vendor who tells you a six-month project can be done in six weeks to win the business will either fail to deliver or deliver something incomplete.
References they can't connect you with. Every established software house has clients they can point to. If they can't, ask why.
Price in Context
Price matters. A quote 50% lower than all other quotes deserves explanation — either the scope is narrower than the others or there's a quality or experience gap being priced for.
The right question isn't "who is cheapest?" It's "who offers the best value for what we actually need to build?" Value includes the quality of what gets delivered, the reliability of the process, and the relationship quality over a multi-month engagement.
The wrong partner is more expensive than the right one — measured in time, in rebuilds, in operational problems from software that doesn't work properly, and in the cost of changing vendors mid-project.
CERIS takes a structured approach to every engagement: clear discovery before scoping, explicit contracts, milestone-based payments, and post-launch support as a defined commitment rather than an afterthought. See our web development service or get in touch to start the conversation.
