Evaluating an Engineering Partner

Most bad software engagements start in the sales call: a polished deck, a "team," and nobody who will write the code. Evaluating an engineering partner is how you find that out before a six-month SOW. It is not a scorecard of fake certifications. It is a short set of questions, a look at how they write, and optionally a paid slice.

This is the process we recommend buyers use on us and on anyone else. It pairs with paid discovery, NDA and IP, and how to hire engineers on a company SOW. You are hiring a company, not a profile.

Who Must Be on the First Real Call

If the first technical conversation is only a salesperson, you have not started. Ask for:

• The engineering lead who would own the work
• Optionally a founder or delivery lead who can bind a SOW
• Your product owner - not five observers who cannot decide

A steering audience without an owner produces a demo of the vendor, not a demo of the work. Weekly demos later will fail the same way.

Timezone overlap should be explicit. Myrafy is in Noida; we say the overlap hours. A partner who hides where the work happens is hiding who will do it.

Questions That Surface the Method

Skip "how many years" as a personality test. Ask:

1. Who is on the engagement next month, by name and seniority? If they cannot say, you are buying a bench.
2. Whose GitHub org holds the repo on day one? If theirs, read the IP clause twice.
3. Show a redacted SOW page - scope list, acceptance, change control. A capability brochure is not a SOW (what belongs).
4. How do you handle a wrong increment? You want a change log, not "we are agile."
5. What will you refuse to put in v1? A partner who never says no will also never finish.
6. How do secrets, staging, and production credentials work? If the answer is a shared .env in chat, leave (secrets in git).

For AI work, add: what is the eval set, who owns the corpus, what is the fallback. Shipping past the demo is the bar.

Do not ask them to "complete a take-home" that is your actual product for free. That is a build, not an evaluation.

A Trial Milestone Beats a Bake-Off

A paid one- or two-week slice (discovery packet, a thin vertical, a production bug you already understand) tells you more than three vendors' slideware.

Rules:

• You own the artifacts even if you do not continue
• The people on the trial are the people on the follow-on, or you renegotiate
• Success is written (checklist), not "we liked the energy"

Unpaid "proof of concept" on your IP is how you train vendors to cut corners and how you leak the domain. Pay. Cap it. Read the packet.

Bake-offs with four firms building the same prototype in parallel waste four invoices and still do not tell you who will be there in month four.

Red Flags (Not Price)

• Volume metrics with no named method ("200 apps," "99% on-time")
• No named engineer until after signature
• Case studies that are stock photos and first names
• NDA that assigns your ideas
• "We will staff from the bench after kickoff"
• Reluctance to work in your cloud account
• Years in the slide titles as a substitute for a plan

Price can be high because seniors are on the work. That is a different conversation from fixed vs hourly. Cheap plus anonymous is the expensive path.

Compare Models, Not Brands

You are choosing direct company contract vs marketplace vs large SI, not collecting logos. The tradeoffs are in freelance vs a software company. A small senior company can be the right size; a ten-layer program can be the wrong one for a twelve-week MVP.

Write down the engagement shape you want after v1: project, retainer, or team extension. If they only sell one shape, they will force it.

FAQ

Should we issue an RFP? If procurement requires it, keep the technical appendix short: outcome, constraints, who will be on the call. A 40-page RFP that never names the product owner selects for proposal writers.

How many vendors? Two is enough if both will put an engineer on the call. Five is a project in itself.

What if they will not do a paid trial? Then the first SOW is the trial: a small milestone with an exit. Do not sign six months to "see."

The Bottom Line

Evaluating an engineering partner is names, a sample SOW, a paid slice, and the right to own the repo. Decks are optional. The people who will write the code are not.

If that bar feels awkward to ask, you already know the answer.

Want that conversation with Myrafy? See about the company, how we work, the OrgPlaza workplace OS, or contact us - typical estimate in one business day when the brief is usable.