Choose a software engineer in Indonesia by matching their demonstrated responsibilities to your problem, then agreeing on a small, testable first delivery. Review relevant projects, communication, data handling, and handover before comparing proposals on price alone.
These are the questions I’d ask before hiring an engineer—and the ones I’m happy to answer about my own work.
Describe one workflow before requesting an estimate
“We need a dashboard” leaves important decisions unresolved. A more useful brief describes who uses the system, what they do today, where work stalls, and what a successful first release changes.
For example, an operations manager might need to review field reports, return incomplete submissions, and export an approved monthly summary. That brief gives an engineer a concrete workflow to discuss. Include existing spreadsheets, a sample record with sensitive data removed, the decision owner, and any deadline imposed by another system or team.
Ask the engineer to explain the unknowns before presenting an estimate. A useful proposal makes assumptions visible and separates essential functionality from later improvements.
Read project evidence carefully
A screenshot shows presentation. A stronger project discussion explains the original problem, the engineer’s role, the constraints, and what was delivered. Ask which parts they personally designed or implemented, how they tested the system, and how it was supported after launch.
An internal application may have no public login. In that case, ask for an appropriate walkthrough, an architecture explanation, or an anonymized workflow. Access restrictions should be explained clearly; confidential client information should remain protected.
My portfolio includes knowledge management, scholarship monitoring, quality management, and sports-management applications. Use those examples to ask about comparable workflows rather than assuming that experience in one sector automatically solves every problem in another.
Compare proposals using the same questions
| Decision area | Ask the engineer | Look for in the proposal |
|---|---|---|
| First release | What can a user complete end to end? | A small set of demonstrable workflows |
| Existing data | How do we migrate and validate records? | Sample migration, checks, and recovery steps |
| Quality | What happens when a request fails? | Error handling and acceptance checks |
| Delivery | How will we review progress? | Named checkpoints and a decision process |
| Operations | Who owns hosting, accounts, and maintenance? | Explicit responsibilities and handover materials |
| Change | How will a new requirement affect the plan? | A transparent way to revisit scope and estimates |
Ask each candidate to respond to the same brief. Compare the boundaries of the work and the assumptions behind the estimate. A low initial quote can describe a much smaller delivery than a detailed proposal.
Make security and accessibility reviewable
Discuss which data is collected, who can access it, how access is removed, and how backups are restored. Request evidence of access-control testing for sensitive actions. A shared checklist can make this conversation more concrete: OWASP ASVS provides requirements for verifying application security controls.
For user-facing software, include keyboard operation, understandable form errors, readable contrast, and mobile use in acceptance reviews. The W3C WCAG overview introduces the international accessibility standard and its testable criteria. Agree on the intended evaluation scope rather than relying on a broad “accessible” label.
For AI features, ask where the source material comes from, how incorrect answers are handled, and which decisions require a person. A prototype should show the difficult case as well as the successful demonstration.
Agree on communication and handover
A Surabaya team, a Jakarta stakeholder, and a remote engineer can work together when meeting times, written updates, and decision ownership are explicit. Confirm the languages used for discovery, documentation, and support. Clarify whether on-site work is required before building the schedule around it.
Before starting, list the handover items: repository access, deployment instructions, environment-variable names, account ownership, backup procedures, and a maintenance arrangement. Keep secrets out of ordinary documentation. Ask the future maintainer to follow the instructions during a review so gaps become visible while the delivery team is available.
A useful first engagement
Consider beginning with a focused discovery or implementation milestone: one workflow, a realistic sample of data, and agreed acceptance criteria. Review the result with actual users. Use that evidence to refine the next phase, including cost, delivery sequence, and unresolved risks.
This is a planning approach, not a fixed price or a universal schedule. A small public website and a multi-department internal application need different discovery and verification work.
Frequently asked questions
Should I hire a freelancer or a software agency?
Choose based on the responsibilities you need covered. Ask who makes technical decisions, who writes and reviews the code, who covers absences, and who provides support. The organization label alone does not answer those questions.
Does the engineer need to live in Surabaya or Jakarta?
Location matters when on-site access or regular in-person work is necessary. For remote delivery, prioritize clear working hours, a shared review process, and reliable communication. Confirm the actual arrangement with the engineer.
Which technology stack should I request?
Start with your users, integrations, data, and maintenance team. Ask the engineer to explain the proposed stack against those constraints. A recognizable framework is useful only when the team can operate and maintain the resulting product.
What should I send for an initial discussion?
Share the problem, users, current workflow, relevant integrations, and known constraints. You can contact me with that brief and browse my experience to assess the fit before discussing a delivery plan.