Most software houses in Indonesia sell time and labor.
You pay for a developer's hours. They deliver what was scoped. If the scope is wrong, you pay to change it. If the product doesn't perform as expected, that's a separate conversation. One that usually doesn't go well for you.
What you actually need isn't a vendor who delivers a deliverable. You need a team that cares whether the product works. Those are different things. Telling them apart before you sign a contract is the skill this article is about.
Why Most Software House Relationships Break Down
The failure mode is predictable. You start with a promising sales conversation. The vendor presents a senior team. The proposal looks detailed. The timeline seems reasonable. You sign.
Six weeks in, you notice the team on your project looks different from the one in the sales meeting. Juniors are doing the work. Progress updates are vague. The "discovery phase" you paid for hasn't produced anything you can ship. When you raise concerns, the response is "We need to revise the scope."
This pattern is common enough that it has a name in the industry, the bait-and-switch. You're sold on outcomes, delivered on hours.
Understanding why this happens helps you avoid it. The fundamental issue is incentive misalignment. In a time-and-materials (T&M) engagement model, the vendor gets paid whether the product works or not. Long projects are more profitable than short ones. Scope changes generate more billable hours. The vendor's business model isn't aligned with your goal.
5 Questions to Ask Before Signing Any Contract
These questions won't guarantee a good outcome. But they'll reveal a lot about who you're actually working with.
- "Can I talk to a client whose project scaled past launch?" Portfolio case studies are marketing. Reference calls with real clients, especially ones whose products are live and growing, tell you something true. Ask specifically about what happened when things went wrong, not just what went right.
- "Who will actually work on my project — and can I meet them now?" Not the head of delivery. The engineer who will write your code and the designer who will build your flows. If a vendor can't commit to specific team members before you sign, that's a signal.
- "What's your definition of done for the engagement?" Listen carefully to this answer. "Working software that meets the specification" is a vendor answer. "A product that achieves [specific metric] with [specific user behavior]" is a partner answer. The difference tells you whether they're thinking about your outcome or their deliverable.
- "How do you handle it when the spec turns out to be wrong?" It always does, at least partially. How a team responds to this reality tells you everything about how the engagement will feel in month three. Vendors bill for changes. Partners help you figure out what actually needs to change.
- "What does your pricing model look like if the project takes longer than estimated?" Pure T&M shifts risk entirely to you. Fixed-fee shifts it entirely to them — which is often good, but can lead to corners being cut near the end. Outcome-based pricing, where fees are tied to delivery milestones and measurable results, aligns incentives. Ask which model they offer and why.
Engagement Models: T&M vs Fixed-Fee vs Outcome Pricing
Time and materials (T&M) is the most common model in the Indonesian market. You pay a rate per developer per month. Straightforward, but it means all scope risk is yours. If the project takes twice as long, you pay twice as much.
Fixed-fee gives you budget certainty. The vendor commits to a price for a defined scope. The problem when the scope needs to change (and it will), you're back in negotiation. Fixed-fee projects often involve vendors who protect their margin by delivering the minimum that fulfills the spec, not the best solution.
Outcome pricing ties payment to milestones: production deployment, user acquisition thresholds, performance benchmarks. It's harder to structure and requires both parties to agree on what success looks like, but it aligns everyone toward the same goal. Sprout uses this model for engagements where outcomes can be clearly defined.
The right model depends on how well-defined your product is. Early-stage, exploratory builds benefit from a short, fixed-scope pilot. Scaled engineering work with measurable outcomes is where outcome pricing shines.
Red Flags: Software Houses to Avoid
They charge heavily for discovery before shipping anything. Discovery is valuable. But a discovery phase that runs for two months, costs significantly, and produces only documents rather than working software is often a delay tactic. Good product teams discover and build simultaneously.
The people in the room during sales aren't the people on your project. This is the classic bait-and-switch. Ask directly: "Will the team presenting today be the team assigned to our work?" Get the answer in writing.
They haven't shipped anything to production in the segment you're building for. A team that builds e-commerce applications doesn't automatically know how to build an OJK-compliant banking system. Domain context matters. Ask to see production examples in your specific industry.
They can't explain their QA process. How they test software reveals how they think about quality. "We test before delivery" is not a QA process. A real process includes automated testing, staging environments, and clear acceptance criteria before any sprint is closed.
They discourage you from running code reviews. Your code is your asset. You should be able to review it. Any vendor resistant to code access or transparency during the build is protecting something — and it's not you.
What "Product Engineering" Means and Why It's Different
There's a meaningful difference between a software house and a product engineering partner, even if both write code.
A software house fulfills a brief. You tell them what to build, they build it, they deliver it.
A product engineering partner participates in figuring out what to build. They bring product thinking not just engineering execution to the engagement. They push back when the spec doesn't serve the user. They instrument the product to measure what matters. They think about sprint 12, not just sprint 1.
Sprout operates as a product engineering partner, not a labor vendor. Our FDE model Full-stack, Delivery-accountable, Engineering-led means the team assigned to your product owns the outcome, not just the tickets. We ship production code from sprint 1, not polished demos. We measure on Friday what we ship on Monday.
This is a different relationship. It requires more alignment upfront. And it produces very different results.
8-Point Checklist Before Choosing a Vendor
Before you sign any software development contract in Indonesia, verify these:
- You've spoken to at least two past clients with live products in production.
- You know exactly who will work on your project, by name and role.
- You've reviewed at least one example of their production code or live product.
- Their pricing model is written down and you understand how scope changes are handled.
- They've offered a short, scoped pilot before committing to a full engagement.
- The contract specifies who owns the code and IP.
- You understand their QA and testing process in concrete terms.
- You have a clear definition of what "done" looks like and it's in the contract.
Choosing a software house in Indonesia isn't just a vendor selection. It's a decision about who will have meaningful influence over your product for the next 6 to 18 months. Take the time to do it right.
