How to Vet a Developer When You Cannot Read Code

Somebody who cannot read code is about to judge somebody who can, and every ordinary proof of competence is written for the other person: a code sample nobody in the room can read, a technical screen nobody can run, a walkthrough of files you have never seen and will never open.

Here is the starting position, in an owner’s own words, posted while asking a room of strangers for help:

I’m not a developer either and I know nothing about coding but I used BASE44 to build 13 apps but I’m kind of stuck and struggling a little try to bring them to market.

They were describing being stuck rather than a hire, which is the state most owners are in on the day they go looking for somebody to pay. The apps exist and the judgement to grade whoever touches them next does not.

Five checks cover what an owner who cannot read code can settle about a developer: their public history, a call with somebody who paid them before, the app they say they shipped, a small first job, and whose name the accounts are in. An hour covers the desk work for all five; the reference call waits on somebody’s diary and the small first job runs over days. The sixth has to be bought.

The five checks below were set against what the pages ranking for how to vet a developer currently tell owners to do, read on 26 August 2026, and each one was then held against the documentation of the account it depends on: GitHub’s published rules for what a contribution graph counts, Google Play’s published rules for what a listing shows about the account behind an app, Apple’s App Store Connect role list, and Stripe’s user-role list. Nobody was hired for this page, no candidate was interviewed, and no marketplace profile was contacted.

The checks that point the other way, at the app rather than at the person, run from a browser and a second email address and need nobody’s cooperation at all.

What these checks settle about a person, and what they leave open

Each of the five is aimed at the person you are about to pay. The app itself stays closed throughout, which is the whole reason a sixth check exists. Vetting a developer for an app that already exists is also narrower than what the ranking pages describe, because most of them are written for somebody commissioning a build.

That sounds obvious until you read what is currently published about vetting a developer as a non-technical founder. The guides ranking today share one baseline: look at a portfolio, run an interview, take references, try a small trial, check their GitHub. As of 26 August 2026, not one of the pages read for this page states what any of it fails to prove. Full Scale, a staffing company, published a guide at fullscale.io/blog/non-technical-founder-guide/ on 7 August 2026 giving three checks (can they explain a decision in plain English, does their commit history match what you are paying for, does the agreement confirm you own the code) and then telling the reader to hire a fractional CTO to hold the judgement for them, alongside its own offer to supply engineers. A developer’s guide published on 13 March 2026 on BoilerplateHub at boilerplatehub.com/blog/how-to-vet-a-software-development-company under the name Marcus Webb goes further: it tells readers they need no technical knowledge to judge whether a product they can open works well as a user, and names FeatherFlow, the studio it promotes, in the same breath. Neither address is linked here, because both pages sell into the work this one is about. Neither publishes a limit.

Grading what a candidate says on the call, one answer at a time, is the other half of this and it happens in a different hour: the eight questions and the answer key for them are set out in full elsewhere, and nothing here repeats them. Where these checks sit inside the hire as a whole, from the first message to an agreed start date, is the sequence this page is one part of.

Each row names what you physically end up holding after the check, what that thing proves, and the claim it cannot carry.

All five of these checks are about the person you are about to pay. None of them looks inside the app.

Two of the five produce a fact: a role is displayed on an account screen or it is not, and a name on a store listing matches or it does not. The other three are judgements, which is why the order below runs from cheapest to most expensive rather than from best to worst.

If the money has already gone out and the app has already been delivered, the instrument changes from a check you run to a request you make of the person who built it, and the checks below stop being the right ones.

Their history, and the rules behind a contribution graph

Ask for the accounts they want you to look at, in their own words, and open every one. What you are settling is narrow and worth settling: this person has existed in public, under one name, for longer than your conversation with them.

Treat the graph carefully, because the guides recommending it never say what it counts. GitHub does.

Its profile contributions reference, read on 26 August 2026, says that on a profile page two actions always count as contributions: “Creating a new repository” and “Forking an existing repository”. Commits are the conditional ones. The page says commits appear “if they meet all of the following conditions”: the email address used to make the commits is associated with the account on GitHub, the commits were made in a standalone repository rather than a fork, and the commits were made either on the repository’s default branch or on the gh-pages branch. On top of all three, at least one more thing has to be true: the person is a collaborator on the repository or a member of the organisation that owns it, or has forked it, or has opened a pull request or issue in it.

Read that in both directions and the graph stops being a scoreboard.

A developer whose entire working life has been private client work, under other people’s organisations, with an employer’s email address on the commits, has an honest empty graph. The same page describes what happens when private contributions are publicised: people without access to those private repositories “will see the number of contributions you made each day”, and “They will not see specific details.” A daily count with no detail behind it says nothing about quality, and there is nothing dishonest about it being all somebody can show you.

In the other direction, the two actions that always count are the two cheapest on the platform. Creating and forking repositories fills a graph without anybody writing anything.

A career of private client work produces an honest empty graph, and creating repositories nobody uses produces a full one.

What a profile does settle is continuity. Four years of activity, a real name attached, project descriptions written by somebody who expected another human to read them, and a history that does not restart every few months tell you this is a person with a working life you can ask about. That is useful, and it is smaller than the guides imply.

Marketplace profiles work the same way with one extra caution. Upwork, Fiverr, Toptal, Clutch and their peers all publish a number next to a freelancer’s name, computed by a private formula the marketplace controls. As of 26 August 2026, support.upwork.com, www.upwork.com/help and help.fiverr.com all returned HTTP 403 to a fetch from here, which is why none of the three is linked and why this page states nothing about what those scores measure or what makes one move. Treat a high score as a reason to keep reading a profile rather than as a finding. What is checkable there is what is checkable anywhere else: how long the account has existed, what it says it has done, and whether the jobs it lists resemble yours.

Two questions for somebody who paid them before

Ask for the client whose job was closest to yours rather than the happiest one. That single substitution turns a reference from a formality into a check, and a candidate whose work is all under confidentiality agreements should be able to say so plainly and offer something else.

The current guides do reach for references, and the sharpest version of the idea comes from the BoilerplateHub guide, which puts a question in the owner’s mouth: ask to speak to a client who had a difficult experience. It is a good question because of how the candidate reacts to being asked it, which happens before you speak to anybody.

When you do get the call, two questions carry it.

What did they do when something went wrong? Every job has one of these. The answer you want names the incident and the sequence: what broke, how the client found out, and how long the gap was between the developer knowing and the client knowing. A reference who cannot remember anything going wrong either had a very small job or is being polite, and the follow-up is the same either way: ask what the slowest week felt like.

What would you do differently about how you hired them? This one asks about the buyer rather than the seller, and it is the more useful of the two. Answers are specific and unflattering to nobody: I would have written down what I wanted before the first call, I would have started with something smaller, I would have asked who else would be touching it. Each is a repair you can make to your own process this week, from somebody else’s experience.

Then the limit, worth saying out loud. A reference has never seen your app, so nothing they say transfers to your code, your data or your accounts. Somebody who was excellent on a Shopify integration for a homeware brand can still be the wrong person for a half-built Base44 app with a payments problem.

What the call does settle: whether the last job ended in a way somebody would repeat. You cannot get that from a profile.

The app they say they shipped, checked against the account that publishes it

Open the thing. If they name an app, install it or load the site as an ordinary customer, make an account, and use it properly. Slow screens, a sign-up that emails you nothing, a payment step that throws you back to the start: all visible to anybody, and the part the guides get right.

Then do the part nobody publishes. A store listing carries the account behind it, and the stores document what they show.

Google’s page on the information required to create a Play Console developer account, read on 26 August 2026, states it twice, once for each account type. In the organisation section: “To help improve transparency and user safety on Google Play, Google will display your legal name, legal address, developer email address, and developer phone number on Google Play.” In the personal section: “Google will display your legal name, your country (as per your legal address), and developer email address on Google Play”, and if the developer monetises on Google Play, Google will display the full address.

So a claim of authorship can be held against a name the store itself publishes, with no code and no cooperation from the candidate. If they say they built and published an Android app for a client, the names on that listing belong to somebody, and the question is whose. A mismatch is rarely a lie, because most contract work publishes under the client’s account, and that answer is easy to give and easy to check further.

Apple’s side has the same shape through a different surface. Its App Store Connect role permissions reference, read on 26 August 2026, documents eight roles and reserves a short list of actions to the Account Holder, who it calls “the only user that can sign legal agreements”, along with renewing the membership, requesting API access, pulling auto-renewable subscriptions from sale, submitting Safari extensions and creating developer ID certificates. Apple also documents that whoever completes enrolment holds that role. Every App Store listing has one of those people behind it, and a candidate who has published apps can say whether they were that person or a Developer inside somebody else’s account.

Two honest limits, both skipped by the ranking pages.

The first: the account behind an app tells you who publishes it, never who wrote which part. A candidate who worked on a team of six on an app you admire is not named on that listing, and will say so, and will be telling the truth.

The second is a documented absence rather than a fact. As of 26 August 2026, Google’s required-information page describes what is displayed on a listing and does not describe any public verification badge attached to it. So there is no badge to look for, and the published name is what does the work instead.

Where an app somebody else built with AI is most likely to be weak is a different question from whether the person you are about to pay is any good, and it is the more useful one to have read before the first call.

A first job small enough that a bad outcome is cheap

Pay for something small before you pay for something large. What you are buying is the sample of how they work, and it is the only check on this page that produces evidence about the future rather than the past.

The BoilerplateHub guide endorses this too, calling a small paid trial on a specific bounded component an excellent way to evaluate a team. Its version is about agencies and a full build, which makes the choice of job matter more here than the size of it. This is the last of the things worth checking before paying a developer anything larger.

Pick something visible, self-contained, and useless to steal: a change on one screen, or one thing that has been broken since the app was built and that you can check yourself in the browser. Avoid anything that reaches into payments, customer data, or the sign-in system, because those are the three places where a bad first week is expensive rather than annoying.

Then watch three things, in this order.

What they ask for before they start. Somebody who asks what the change should do for a customer, where to see it working, and whether anything else depends on it is doing the job properly. Somebody who says yes immediately and asks for the keys has told you how the rest will go.

What comes back with the work. The message matters more than the code, because the code is the part you cannot read. You want to be told what was changed, where to look at it working, and what was left alone. A link and one sentence about what to click is worth more to you than three paragraphs of vocabulary you would have to look up.

What they refuse. This is the one worth waiting for. A candidate who says a request is a bad idea and explains why, or says a job is too small to bill for, or says they need something you have not given them, will say the same thing in month three when it costs money. Total agreement in week one is a warning.

Two things the small job cannot do. It proves how they work rather than what your app is made of, because you deliberately kept it away from the parts that matter, and it is no protection against the money going wrong. When the last person took the money and stopped answering, the lesson worth carrying into the next hire is a specific one about how that hire was made.

The size of the job is the piece you control, and it is why this check exists at all. On what the work should cost once you have chosen somebody, the price differences between hiring routes are set out separately, and that comparison belongs after the checks rather than before them.

A price only means anything if the person quoting it was told what the job is, and what to send them before they quote is the piece of homework that comes first. Once you have chosen, what the person you choose gets on day one is a different list again, and a shorter one than most owners expect.

Whose name the accounts are in, checked on screen rather than promised

Open each account and read the role you hold. This is the one check here that is a fact rather than a judgement, and it decides what happens if the arrangement ends badly.

Owners usually ask a candidate to put things in their name and take the answer on trust. Opening each account and reading which role is showing today is the better move, because the platforms publish what each role can and cannot do.

Stripe’s user roles page, read on 26 August 2026, says: “An Account Owner is a special type of Administrator that can perform all actions, including closing the account. There can only be one Owner for an account.” The same page lists what the Administrator role cannot do, and the item that matters is “Change the account owner (only the owner can transfer ownership)”. It also describes the Developer role as one that “has access to the secret key, which grants access to almost all API resources”, and notes that a Developer “can’t invite team members or change the account owner”. So a developer can have everything they need to build against your payment account without being able to take it, and if you are not the Owner today, only the current Owner can make you one.

GitHub’s roles in an organization documentation draws the same line for the code. It says “Organization owners have complete administrative access to your organization”, and it defines an outside collaborator as “a person who has access to one or more organization repositories but is not explicitly a member of the organization, such as a consultant or temporary employee”. That describes almost every developer an owner hires. The arrangement that matches it is an organisation you own, with the person added to the repository they need.

Apple’s role list, quoted above, does the same for a mobile app: the Account Holder completed enrollment and signs the agreements, and no other role substitutes for it.

Four screens, four answers: the payment account, the code, the store account, and wherever the app and its database run. If any of them shows somebody else where your name should be, fix it before the first invoice rather than after the last one. It says nothing about a candidate you have not hired yet.

The full account-by-account list, and what happens to each one if you and the developer part company, runs longer than the four accounts here.

The sixth check, the one that has to be bought

The five checks can all come back clean and the app underneath can still be carrying the kind of problem nobody finds until a person opens the code and holds it against what you told your customers.

Here is the shape of the worry, from an owner talking about their own build rather than about a hire:

But does this put my server at risk now that I am connecting banking info to it? Should I just grit my way through it? Clearly not a developer.

That is a self-build question rather than a hiring one, and it is here because it is the exact class of question none of the five checks can answer. No profile, reference call, store listing, small job or account screen tells you whether the thing you are connecting money to holds. A person has to look.

What such a reading finds is not hypothetical. In AxonBuild’s fixed study of 26 AI-built applications audited in June and July 2026, with every finding checked against the code before it was counted, 22 of the 26 landed in the red band, 4 in amber, and none in green. That is a distribution rather than a verdict on any one app, and it is why a reading is a purchase rather than a formality.

The concrete version of what the five cannot see: in that same fixed 26-app study, 9 of the 26 were still on a release of their web framework that had a publicly disclosed hole an outsider could reach, either to run code or to walk past the login, and closing it was usually one line in a package file. Nothing about the person you hire changes that number. Nothing on a profile page reveals it. It is visible to somebody reading dependency versions against published advisories, and to nobody else.

Buying somebody’s reading of the code, and knowing what should come back for the money, is the whole of the sixth check. What actually happens between handing over read access and the last conversation is set out step by step, and the sellers who do that reading, and what separates them is a shorter list than the search results suggest.

Who does it is a real choice and it is not always a purchase: a senior developer you already know can read an app in an afternoon as a favour, and a candidate you are considering should not be the one reading it. If neither is available, that conversation starts with a free 20-minute call.

One loose end. None of this settles whether you and this person will get on for six months, and owners who have hired well will tell you that mattered more than any of it.

Common questions about vetting a developer when you cannot read code

How do I vet a developer if I cannot read code?

Run five checks that need no code reading: open their public history and read it for continuity rather than volume, call a client whose job resembled yours, hold any app they claim against the account name the store publishes, pay for one small self-contained job and watch how they work, and open each of your accounts to see which role you hold today. An hour covers the desk work, the call takes whatever scheduling it takes, and the first job plays out over days, and that is how to check a developer before hiring them without reading a line of their work. A reading of the code is a sixth thing, and it is bought rather than run.

Is a GitHub profile proof that somebody can do the job?

No. GitHub’s own contributions reference says creating a repository and forking one always count, while a commit counts only if the authoring email is connected to the account, the repository is standalone rather than a fork, and the commit landed on the default branch or gh-pages. So a graph can be filled cheaply, and a developer whose whole career has been private client work has an honest empty one. A profile settles continuity and identity, nothing about quality.

What should I ask a developer’s previous client?

Two questions. What did they do when something went wrong, which tells you how bad news travels. And what would you do differently about how you hired them, which is about the buyer and is usually the more useful answer of the two. Ask for the client whose job was closest to yours rather than the one who is happiest, and expect nothing they say to transfer to your own app, which they have never seen.

How do I check that an app they say they built is really theirs?

Open the store listing and read the account behind it. Google’s page on the information required to create a Play Console developer account says Google displays an organisation’s legal name, legal address, developer email address and developer phone number, and a personal account’s legal name, country and developer email address. Apple documents an Account Holder behind every listing. A mismatch is rarely proof of a lie, because contract work usually publishes under the client’s account, but it turns a claim into a question with an answer.

Should I pay for a small first job before the real one?

Yes, and pick it for what it reveals rather than for what it delivers. Something visible, self-contained, and nowhere near payments, customer data or sign-in. Watch what they ask for before starting, what message comes back with the work, and whether they refuse anything. Total agreement in the first week is the warning sign. The job proves how somebody works, and proves nothing about what your app is made of.

Which accounts should stay in my name while somebody works on my app?

The payment account, the code, the store account, and wherever the app and its database run. Stripe documents one Owner per account and that only the owner can transfer ownership, so being Owner there is a fact you can see rather than a promise. GitHub documents organisation owners with complete administrative access and outside collaborators with access to specific repositories only, which is the shape that fits a hired developer.

What if every candidate I can find is an agency rather than a person?

The five checks still run, with one substitution: ask which named individual will do the work, and run the history and reference checks on that person rather than on the company, because an agency reference only describes the agency’s process. The small first job matters more here, because it is the only check that shows you the human who will answer your messages in month four.

Do I need somebody technical on my side to hire somebody technical?

Not for these five. How to vet a developer as a non-technical founder comes down to a profile, a phone call, a store listing, a small paid job and a screen in an account you already own. A second pair of eyes becomes necessary for the reading of the code, which is the sixth check and a separate purchase, and it is bought for one job rather than kept on.

What if I already paid somebody and I am only checking now?

Then the order changes. Getting the accounts into your own name comes first, because that part gets harder the longer it waits, and the questions you put to somebody who has already delivered an app are different from the ones you put to a candidate. The history and reference checks still work and are worth running, though they will mostly tell you about the next hire.