How to Choose a Software Development Partner

Most founders pick a development partner the way they pick a contractor for a kitchen: get three quotes, take the one in the middle, hope for the best. With a kitchen you can at least see the cabinets going in. With software, the work is invisible until it isn't, and by the time you can tell whether you chose well, the money is mostly spent.

I'm the CEO of CloudAnts, a seven-person studio in Pasig that builds web, mobile, and AI products for clients worldwide. I've been on both sides of this table, pitching, and watching clients arrive bruised from a previous build that went sideways. This is the advice I'd give you across a table, including the parts that don't favor us.

The four kinds of partner, and what each is actually good at

There are roughly four options, and the marketing blurs them on purpose. Sort them out first.

Freelancers. One person, hourly or per-project, hired through a marketplace or a referral. Cheapest by a wide margin. Genuinely the right call for a small, well-defined job: a landing page, a single integration, a bug nobody else can find. The risk is concentration. One person gets sick, takes a better offer, or simply goes quiet, and your project goes quiet with them. There's no second engineer who knows the code, and usually no tests or documentation to hand to the next person.

Offshore body-shops. Large outsourcing firms that sell developer-hours at scale, often very cheaply. They can throw ten people at a problem next week. The catch is structural: the people who scope your project in the sales call are rarely the people who write the code, and the people who write the code rotate. You communicate through a project manager who is translating between you and a team you never meet. It can work for huge, well-specified backlogs. It tends to struggle when the spec is fuzzy and judgment matters.

Boutique studios. Small senior teams, ours included. More expensive than a freelancer, less than a big agency. The people who scope your project are the people who build it, so context doesn't get lost in a handoff. The honest limitation is capacity: a small studio can't absorb a sudden demand for forty engineers, and a good one will tell you when your project is bigger than it should take on.

Big agencies. Large, full-service, often with brand-name clients and account managers. They bring process, polish, and the ability to staff almost anything. You pay for all of it, including layers of management that never touch your code. Great when you need scale and a name on the contract. Slow and expensive when you need a focused product shipped without ceremony.

The questions that actually predict the outcome

A portfolio tells you what a team has done, not how they'll treat your project. These questions predict the outcome far better. Ask all of them in the first call.

How do you scope work, and is the price fixed or hourly? This is the single most revealing question. A partner who works fixed-scope, meaning a written scope, a fixed price, and a fixed timeline, is carrying the risk of their own estimates. If they're wrong about how long something takes, that's their problem, not your invoice. Open-ended hourly flips that: every estimate miss becomes your cost, and you're asked to trust that more hours always mean more value. Every CloudAnts engagement is fixed-scope for exactly this reason. There's a fuller breakdown of what drives the number in how much it costs to build custom software.

Who owns the code and the IP when we're done? The answer should be "you do," in writing, including the repository, the infrastructure, and any credentials. Some firms keep your code on their accounts so leaving means rebuilding. Ask where the code lives and whose name is on the cloud account. If the answer is fuzzy, that's the answer.

How often will I see working software running? Not slides, not a status report that says login is "80% done" for a month straight. Working software, deployed somewhere you can click it. A partner confident in their process will happily show you progress every two weeks. One who wants to disappear for a quarter and return with a big reveal is asking you to absorb all the risk of being wrong. This matters enough that we wrote a whole post on why we demo every two weeks.

Who actually writes the code? In the sales call you meet the polished people. Ask who's on the keyboard, how many of them, and whether they'll change mid-project. A small senior team that builds what it scopes is a very different bet from a sales team fronting an interchangeable pool you'll never speak to.

What does "done" mean? Pin this down. Does "done" include tests, a staging environment, documentation, and a deploy you control? Or does it mean the feature worked once on someone's laptop? Vague definitions of done are where fixed prices quietly become hourly.

What happens after launch? Software isn't a building you cut a ribbon on and walk away from. Dependencies age, security patches land, the platform underneath shifts. Ask whether maintenance is in the contract or a separate negotiation you'll have under pressure later. We put maintenance in the contract because the alternative, ship and disappear, is how good software rots.

Timezone and communication: less scary than it sounds

Founders worry about hiring a team in another timezone. The worry is usually misplaced. We're in Manila, GMT+8, building for clients worldwide, and the distance is rarely the problem. The cadence is.

What actually matters is a predictable rhythm. A regular demo of working software. Fast responses; ours average around 24 hours, and we treat that as a floor, not a target. Decisions that don't sit in a queue for a week. A few hours of daily overlap is plenty when demos are recorded and sprint decisions can happen async.

A partner in your exact timezone who goes dark for three weeks is worse than one eight hours away who shows up every other Friday with something running. Judge the cadence, not the map.

Red flags worth walking away over

Some signals are bad enough on their own to end the conversation.

A price before any real questions. If a firm quotes a number before understanding your users, your constraints, and what "done" means, that number is fiction. Either they'll pad it heavily to cover their ignorance, or they'll lowball it and claw the difference back through change requests. A real scope takes questions first.

No staging, no tests, no handover plan. These are the unglamorous things that separate software you can build on from a demo that falls over the first time real users touch it. If a partner can't describe their testing approach or how they'll hand you the keys, they're optimizing for the demo, not for the year after.

Vague AI claims. "We'll add AI" is not a plan. AI in a product has real, specific questions behind it: what does a call cost, what happens when the model is wrong, what's the fallback, how do you measure accuracy. A partner who waves at AI without answering those is selling a buzzword. We've written about what actually works when you add AI to a product, and almost none of it is the magic the word implies.

"We'll figure out the scope as we go." Sometimes dressed up as agility. Usually it means the meter runs and the destination is never agreed. Iteration within a fixed scope is healthy. An open-ended scope with an open-ended bill is how projects quietly double.

What "good" looks like in practice

Since I've been throwing rocks, here's the standard I'd hold us to as well. Use it on anyone, us included.

We work fixed-scope. The contract says what ships, for how much, by when. The bands are public: web builds run 6 to 12 weeks, mobile apps 8 to 16, cloud work 4 to 10, integrations 3 to 8. You can see the full set on our services page. A range that specific is only possible if a team scopes carefully before quoting, which is the whole point.

We demo working software every two weeks, on a Friday, deployed to a URL you can click. No black boxes. If we're the wrong team, you find that out in week two while the project is still small enough to steer, not in month four when the budget's gone.

The seven people who scope your project are the people who build it. Small teams ship faster. Seven people who all know each other beats twenty who don't, and nothing gets lost in a handoff because there isn't one.

Maintenance is in the contract. We don't ship and disappear. Our own infrastructure is Terraform-managed and boring on purpose, which keeps the upkeep small for the clients who stay on with us.

The clearest proof is the work that's already out there. The Mitsubishi Motors Philippines companion app and the rest of our portfolio shipped on this exact rhythm. So did Denti, our own multi-tenant dental SaaS. Its AI receptionist, the one on the homepage that books real appointments over Facebook Messenger, started as a rough Friday demo and got better in front of us every two weeks. We trust the process because we run our own product through it.

A checklist you can run this week

Before you sign anything, get these answered in writing:

• Is the engagement fixed-scope, or open-ended hourly? Get the scope, price, and timeline on paper.
• Do you own the code, the IP, the repository, and the cloud accounts when it's over?
• How often will you see working software running, and where can you click it?
• Who actually writes the code, how many of them, and do they change mid-project?
• What does "done" include: tests, staging, documentation, a deploy you control?
• Is maintenance in the contract, or a separate negotiation later?
• What's the real communication cadence and response time, regardless of timezone?
• If there's AI in the build, what does it cost per call, and what happens when it's wrong?

If a partner answers those cleanly and the answers hold up, the timezone and the logo on the contract matter a lot less than you think. If they dodge even two or three, keep looking.

One more decision sits upstream of this one: whether you should build custom at all, or buy something off the shelf. If you haven't settled that yet, start with custom vs. off-the-shelf vs. no-code before you pick anyone to build it. And if you want a second opinion on your specific project, including scope, options, and whether we're even the right fit, tell us what you're building. We'll tell you straight, including when the answer is someone other than us.

Frequently asked questions

What questions should I ask a software development company before hiring them?

+

Ask how they scope work and whether the price is fixed or open-ended hourly. Ask who owns the code and IP when the project ends. Ask how often you will see working software running, not slides. Ask who actually writes the code versus who you meet in the sales call, and what happens after launch. The answers to those five predict the outcome better than the portfolio does.

Should I hire a freelancer, an offshore agency, or a software studio?

+

A freelancer is cheapest and fine for a small, well-defined job, but you carry the risk if they vanish. A large offshore body-shop scales headcount but often separates the people who scope from the people who build. A boutique studio costs more than a freelancer and less than a big agency, and the people who scoped your project are usually the ones writing the code. Match the option to the size and risk of the work.

What are red flags when choosing a software development partner?

+

A firm price before they have asked any real questions is the biggest one. Others: no staging environment, no tests, and no handover plan; vague claims about AI with no detail on cost, accuracy, or fallback; and any version of we will figure out the scope as we go. Each of those moves risk from them onto you.

Does fixed-scope or hourly billing protect the client better?

+

Fixed-scope protects you on a project with a clear goal because the partner carries the risk of bad estimates, not you. A written scope, fixed price, and fixed timeline mean overruns are their problem. Open-ended hourly can make sense for genuinely exploratory work, but it asks you to trust that more hours always equal more value, and that is hard to verify from the outside.

How important is timezone overlap when working with a development partner?

+

Less than people fear, if the cadence is set up well. What matters is a predictable rhythm: a regular demo of working software, fast responses, and decisions that do not wait days. A few hours of daily overlap is plenty when the partner records demos and handles sprint decisions async. A partner in your exact timezone who goes quiet for weeks is worse than one eight hours away who shows up every two weeks.