Choosing the wrong technology partner is the most expensive mistake a business can make in software. It is not just the wasted budget — it is the months of lost momentum, the opportunity cost of launching late, and the painful reality of starting over with a new team that has to untangle someone else's code. In Hong Kong's fast-moving market, where competitors are digitising at speed, a bad partner choice can set you back an entire year.

After years of building custom software for Hong Kong businesses — and inheriting projects from agencies that did not work out — we have seen every pattern of what goes right and what goes catastrophically wrong. Here are the seven questions you should ask before signing anything, and the red flags that should make you walk away.

Question 1: Who Actually Does the Work?

This is the single most important question, and the one most businesses forget to ask. Many agencies send their best people to the sales pitch — articulate senior engineers who understand your business, ask the right questions, and inspire confidence. Then, once the contract is signed, the project gets handed to a team of junior developers you have never met.

This "senior bait-and-switch" is endemic in the industry, and it is the root cause of most failed projects. The solution is straightforward: ask to meet the actual engineers who will write your code. Request their LinkedIn profiles or portfolios. Ask which team member will be your primary technical contact throughout the project. If the agency hesitates or says the team "has not been assigned yet," treat that as a warning sign.

A good partner will be proud to introduce their team. They will tell you who is responsible for frontend, who handles backend architecture, and who is leading QA. If the person in the pitch is the same person who builds — even better. That is the model we use at Astera: the senior engineer who scopes your project is the one who delivers it.

Question 2: Do I Own the Code?

This sounds like a simple yes-or-no question, but the answer is often buried in contract fine print. Some agencies retain intellectual property rights over code they write for you. Others build on top of proprietary internal frameworks, which means your "custom" software only runs inside their ecosystem. If you leave, you leave empty-handed.

Ask explicitly: "Will I own 100% of the source code, designs, and documentation?" Then check the contract. Look for clauses about licensing, proprietary tools, or frameworks that remain the agency's property. If your software depends on any component you do not own, you are locked in — even if the contract technically says the code is yours.

The ideal partner builds on open-source technologies and standard frameworks — React, Next.js, PostgreSQL, AWS — that any competent developer can pick up. Your code should live in a Git repository you control, with clear documentation, so another team could take over tomorrow if needed. That is not a sign of distrust; it is a sign of good engineering practice. For a deeper look at cost structures and what you should expect to receive, see our guide to app development costs in Hong Kong.

Question 3: What Happens if I Want to Leave?

No one enters a partnership planning to exit, but smart businesses plan for every scenario. Ask your prospective partner: "If we decide to part ways mid-project, what does the handover look like?" The answer reveals a great deal about how they operate.

A trustworthy partner will have a documented offboarding process. They will export all source code, provide database schemas and migration scripts, hand over API documentation, transfer domain names and hosting credentials, and brief your incoming team. They will do this professionally, without holding anything hostage.

If the agency cannot describe this process clearly, or if the contract includes long lock-in periods and punitive termination fees, proceed with caution. You want a partner who earns your continued business through quality work — not one who keeps you through contractual barriers.

Question 4: How Do You Handle Scope Changes?

Every software project changes scope. New requirements emerge, market conditions shift, users give feedback that reshapes priorities. The question is not whether scope will change, but how your partner handles it when it does.

Some agencies treat any change as a formal change request with a separate quote, additional timelines, and re-negotiated contracts. Others take a more agile approach, absorbing minor adjustments within the sprint and only flagging changes that genuinely affect budget or deadline. Neither model is inherently wrong, but you need to know which one you are signing up for.

Ask: "If we realise halfway through that a feature needs to work differently, what is the process?" Then ask about their pricing model. Fixed-price contracts give you budget certainty but can make scope changes expensive. Hourly or retainer models offer flexibility but require you to trust the team's efficiency. The best partners are transparent about trade-offs and will recommend the model that fits your situation — not the one that maximises their revenue.

Question 5: Can I See Working Software Weekly?

If an agency says they work in "agile sprints," verify what that actually means in practice. True agile development means you see working, deployable software at the end of every sprint — typically every one to two weeks. Not wireframes. Not progress reports. Working software you can click through in a staging environment.

Ask for access to a staging server from week one. Ask whether you will receive weekly demo sessions where the team walks you through what was built, what is next, and what blockers exist. Ask whether you can test features yourself between demos. Transparency is not a feature — it is a requirement. If the first time you see your product is at the "final delivery" three months later, you are almost guaranteed to be disappointed.

Weekly visibility also protects both parties. If the project is heading in the wrong direction, you catch it in week two — not month three. That is the difference between a minor course correction and a full rebuild. At Astera, we give every client access to a live staging environment and run weekly demos, because surprises at launch are always bad surprises.

Question 6: What Is Your Post-Launch Support?

Software does not end at launch. Bugs surface in production that never appeared in testing. Users behave in ways nobody predicted. Third-party APIs change without warning. Server loads spike during promotions. Without a clear post-launch support plan, you are on your own when things break — and things always break.

Before signing, ask about the warranty period. A reputable agency includes at least 30 days of post-launch bug fixes at no additional cost. Beyond warranty, ask about ongoing maintenance plans: What are the SLAs for critical bugs versus minor issues? Is there a dedicated support channel? What is the monthly cost for ongoing maintenance and feature development?

The best partnerships evolve from a project engagement into a long-term retainer, where the same team that built your product continues to maintain, optimise, and extend it. This continuity is invaluable — a new team inheriting unfamiliar code will always be slower and more error-prone than the original builders. If you are interested in this model, our CTO-as-a-Service approach is specifically designed for businesses that need ongoing technical leadership without the overhead of a full-time hire.

Question 7: Are You Based Where I Am?

Remote work has made it possible to hire developers anywhere in the world. But "possible" and "optimal" are different things — especially for complex projects that require close collaboration, rapid iteration, and deep understanding of your local market.

A Hong Kong-based partner operates in your timezone, understands local business culture, and can meet you in person when it matters. They know that your users expect Traditional Chinese interfaces, Octopus and FPS payment options, and PDPO-compliant data handling. They understand the nuances of selling to Hong Kong customers versus Southeast Asian markets. These are not things you can easily brief into an offshore team working eight hours ahead of you.

That does not mean offshore is always wrong. For well-defined, modular tasks with clear specifications, distributed teams can work well. But for strategic projects — the ones that define how your business operates — having your technology partner in the same city, available for a same-day whiteboard session, is a genuine competitive advantage.

Red Flags to Watch For

Beyond the seven questions, watch for these warning signs during your evaluation process:

Making Your Decision

Choosing a technology partner is one of the highest-leverage decisions your business will make. The right partner accelerates your growth, de-risks your technology investments, and becomes a trusted extension of your team. The wrong one costs you time, money, and — worst of all — confidence in the idea itself.

Take the time to ask these seven questions. Compare answers honestly. And look for a partner who is as invested in your success as you are.

If you are evaluating IT consulting partners in Hong Kong and want a candid conversation — no pitch deck, no pressure — book a free consultation with our team. We will tell you honestly whether we are the right fit, and if we are not, we will point you in the right direction.