How to Choose a Software Development Company

Hiring a software company is not the same as hiring a designer for a brochure. You are choosing who will hold your process, your data model, and often your production keys. A polished deck and a low first invoice are weak signals. Process, ownership, and how they behave when requirements change are stronger ones.

This is a buyer’s checklist Palmate would be comfortable being measured against. It is not a claim that we are the only competent shop, and it does not invent awards or client counts. If the real question is still “should we build at all?”, start with custom software versus SaaS and IT consulting.

Write the problem before you write the RFP

Vendors will fill a vacuum with their favourite stack. Give them a problem: users, constraints, systems that already exist, and what happens if you do nothing for 18 months. “We need an app” produces app-shaped quotes that cannot be compared.

Include:

• Who operates the system after launch (you, them, or a third party).
• Compliance or data residency that is actually required — not a buzzword.
• Integrations that are non-negotiable (payments, ERP, identity).
• A budget band, even if it is wide. Surprise is more expensive than honesty.

The website cost estimator is a planning range for sites and portals, not a Palmate price list. How much custom software costs explains drivers (discovery, integrations, environments) without pretending there is a menu.

Ask how they work, not only what they have shipped

A gallery of screenshots does not tell you whether they write down state machines, whether staging exists, or whether you will receive the repository. Ask:

• Who is on the project, by role, and what happens when that person is ill.
• Where the code lives (your git org versus theirs) and who owns licences.
• How they handle change — a backlog and written change control, or endless “small tweaks.”
• How they test — automated tests where it pays, plus a named UAT path.
• How they deploy — git and a pipeline, or live edits on production.

For product work, custom software development should sound like a product with environments and a maintenance path, not a one-off script. For public sites, web development should include handover, not only a Figma file.

Sample architectures on a vendor site can be useful if they are labelled as samples. Palmate’s case studies include clearly marked samples such as the operations dashboard. Treat unnamed “we increased revenue 300%” stories as advertising.

Red flags that show up before a contract

• Guaranteed rankings, guaranteed AdSense, or guaranteed 99.99% with no SLO definition. See 99.9% vs 99.99% uptime for why percentages without a clock are empty.
• No questions about your current systems. A team that does not ask about source of truth will discover it in month four.
• A fixed price on an unscoped integration. Vendor APIs, data cleanup, and auth are where calendars go to die. Use the API project estimator as a shared language for complexity, then insist on discovery.
• They will not name a tech lead you can speak to.
• Intellectual property stays with them by default, or you get a compiled blob without source.
• Communication only through a salesperson after the sale.

None of these prove malice. They prove you will spend management time on the relationship instead of the product.

Compare apples: the same scope, written down

When quotes arrive, line them up:

Topic	What to match
Discovery	Paid, time-boxed, with a written findings doc
Environments	Staging + production, at minimum
Integrations	Named systems, not “API included”
Content / design	Who supplies copy, who does IA
Support	Response hours, what is included after launch
Hosting	Who patches, who restores, who holds keys

A cheaper quote that omits staging, backups, and documentation is not cheaper. Website launch work is part of delivery; so is a Linux baseline if they operate a VPS.

Currency and tax should be explicit. Estimators on this site may show USD for planning; a formal quote should state currency, what is out of scope, and how overruns are approved.

Communication is a deliverable

You want a weekly written status: what shipped, what is blocked, what decision is needed from you. Slack-only progress is how scope evaporates.

You want access to the issue tracker. If the company hides the backlog, you cannot steer.

You want honesty about uncertainty. “We do not know until we see the vendor’s sandbox” is a professional sentence. “It will definitely take two weeks” about an undocumented third-party API is not.

After you choose: still run a discovery

A good partner will still insist on a short discovery before a large build: current-state diagram, risks, and a sequence of slices you could ship. Planning digital transformation is the same idea at programme scale.

If they skip discovery to “get started in the codebase,” you are funding archaeology.

A compact interview script

1. Explain a recent project that went wrong and what they changed.
2. Ask who owns production access and how leavers are removed.
3. Ask for a sample of documentation (runbook, API notes) with secrets removed.
4. Ask how they would staff your project in week one versus month four.
5. Ask what they will not do (stack, industry, or engagement model).

The last question filters generalists who never say no.

Palmate’s bias, stated plainly

We prefer explicit architecture, Docker and Linux when we host, and integrations with retries and logs. We do not invent testimonials. If you need a sounding board before a bake-off, IT consulting is the slower, cheaper mistake to make than a year of the wrong build. If you already know you need a system, custom software is the delivery path — with a quote after discovery, not before.