Start a Project
Buyer's Guide

How to evaluate an app development company - a practical checklist.

Choosing who builds your product is a bigger decision than most people treat it as. This checklist walks through what to actually check before the sales call, what to ask during it, and what to confirm before you sign - so you're evaluating substance, not a polished pitch. We're a dev shop ourselves, so judge our own answers against this list too.

Talk Through Your Project Compare Agency vs Freelancer vs In-House Read FAQs
12-point checklist
Research, call, and contract stages
Red flags included
5-minute read
Guide Coverage Live Before the call Covered During the call Covered Before you sign Covered Red flags Included

Before You Take a Call

Do this research first - it takes 20 minutes and rules out weak candidates fast.

01

Look at real shipped products, not slides.

Ask for links to live apps or websites they've built, not just portfolio screenshots. A slide deck can show anything; a working App Store listing or production site is much harder to misrepresent.

Ask for live links
02

Read reviews outside their own website.

Testimonials on a company's homepage are self-selected. Check Clutch, GoodFirms, or Google reviews for a fuller picture, including any critical ones - and how the company responded to them.

Check third-party review sites
03

Check how long they've actually been operating.

A polished website can be built in a weekend. Look for evidence of sustained operation - years in business, repeat clients, a consistent public track record - not just how recent the site looks.

Verify operating history
04

See if their tech stack rationale is specific to you.

Some shops default to the same stack for every client regardless of fit. In the first conversation, ask why they'd choose a particular technology for your specific requirements - not just what they usually use.

Ask "why this stack"

During the Conversation

Questions that separate a real process from a good sales pitch.

05

"How do you handle QA and testing?"

A vague answer ("we test everything") is a signal to dig further. Look for specifics: automated testing, staging environments, and QA handled separately from the developer who wrote the code.

Expect specifics, not reassurance
06

"What happens if my main developer becomes unavailable?"

Continuity risk is real, especially with solo freelancers. Ask about backup coverage, documentation practices, and whether you'd effectively be starting over with someone new mid-project.

Ask about backup coverage
07

"How do you handle scope changes?"

Every project's scope shifts. Ask how change requests get estimated and approved, and whether that process is written into the engagement terms or handled informally as it comes up.

Get the change process in writing
08

"What's included after launch?"

A finished app still needs monitoring, bug fixes, and updates. Confirm what post-launch support is included, for how long, and what it costs once that window ends - before you sign anything.

Confirm the support window

Before You Sign

Confirm these in writing, not just verbally.

09

Who owns the IP?

Confirm in the contract that you own the code, designs, and any custom work product once paid for. This should be explicit in writing, not assumed because it "usually works that way."

Get IP transfer in the contract
10

Is the pricing model actually transparent?

Fixed-bid and time-and-materials can both work. Ask what's excluded - extra revision rounds, third-party API costs, infrastructure - so a low headline number doesn't turn into scope-creep billing later.

Ask what's excluded
11

Will they sign an NDA without pushback?

Established companies often have a standard NDA-review process that takes a few days - that's normal. Outright refusal to protect your idea before a detailed discussion is worth asking about directly.

Protect your idea in writing
12

How do they handle security and compliance?

If you're handling health, financial, or personal data, ask specifically how they approach secure coding, data storage, and any compliance frameworks - HIPAA, GDPR, PCI-DSS - relevant to your industry.

Ask about your specific compliance needs

Red Flags

Signs worth walking away from.

Pressure to sign immediately

Legitimate vendors give you time to review a proposal and compare options. Urgency tactics ("this rate expires today") are a sales technique, not a sign of genuine demand.

No written contract or SOW

If deliverables, timeline, and payment terms aren't in writing before work starts, there's nothing either side can be held to once something goes wrong.

They can't name who's on your team

If a company can't tell you which specific people will build your product, you may be evaluating a sales team rather than the people who'll actually do the work.

How We Stack Up

Judge Zetrixweb against this same checklist.

We're not neutral - we're a vendor you'd be evaluating. So rather than tell you to trust us, here's where to check for yourself.

Security & compliance, specifically

Our approach to secure coding, data handling, and compliance frameworks is laid out on Security and Trust Center - not just a badge on a page.

IP ownership & contract terms upfront

What you own, what's included, and what isn't - spelled out plainly on Our Promise before you ever get to a contract.

FAQs

Frequently asked questions.

Whether you can see and use real, live products they've shipped - not just portfolio screenshots or slide decks. A working app in the App Store or a live production website is much harder to misrepresent than a case study page.

It's worth asking why. Some established companies have a standard NDA-review process that takes a few days, which is normal. Outright refusal to protect your idea before a detailed discussion is a signal worth weighing, not necessarily a dealbreaker on its own.

Not automatically, but ask what's excluded from it. A low headline number that omits QA, project management, post-launch support, or clear IP terms often ends up costing more once those gaps surface mid-project.

Three is usually enough to spot real differences in process, transparency, and communication without dragging the decision out for weeks. More than five tends to add noise rather than clarity.

Ready to put this checklist to use?

Ask us anything on this list - team, QA process, IP terms, security - directly. We'd rather earn the decision than rush it.

Start a Project Compare Delivery Models