Red Flags and Frauds to Avoid

Outright fraud exists in this trade as it does in every trade, and it is not what goes wrong most of the time. What goes wrong most of the time is a question nobody asked and an answer nobody wrote down. So a red flag is usually a missing answer rather than a bad person, and the protection is the same either way: ask, and get it in writing.

None of what follows is a reason to distrust the people you are talking to. These are ordinary questions. Anyone who does this work regularly has answered them before, and a straight answer costs nothing to give.

The answers that belong in the contract

Four of them. An email saying the right thing is better than nothing and worse than a clause.

• Who owns the code once the final invoice is paid?
• Whose accounts does it run in?
• Could a different developer take it over, and what would they receive?
• What happens to all of it if we stop working together?

Ours: you own all deliverables on final payment, and you get the full repository plus the documentation for deploying it. No lock-in. Whoever you hire, get their version of those four answers on paper.

A number with no scope behind it

A price only means something next to a written description of what it buys. A very low number and a very high number are the same problem when neither is attached to a scope: there is nothing to hold anyone to, and nothing to measure the finished software against.

So ask for the scope in writing, with what is included, what is not, and how a change to it gets priced and approved. Fixed price and hourly are both legitimate ways to work. What matters is knowing what ends the spending. If it is hourly, ask for an estimate and ask what happens when the estimate is passed.

A date produced before anyone looked at your process

A delivery date given in the first conversation is a guess, however confidently it is said. Nobody can know how long your work takes to model before they have seen how your work runs.

The fix is not asking for a longer date. It is a smaller version one. If the answer to "can you make that date" is yes without anything being removed from the list, ask what was going to be cut instead.

Know who is actually doing the work

Work being split across a team, or given to a subcontractor, is normal and is not a problem by itself. A lot of good software is built that way. The problem is finding out after the fact, because it usually means you also do not know who is accountable when something breaks.

So ask plainly: who writes the code, who is responsible for the result, and who do you call. The people you meet in the sales conversation should be the people on the project, or somebody should tell you straight that they are not and explain who is.

Accounts in your name from day one

Hosting, the domain, the database, the third-party services with keys and monthly charges. Each of those should be an account your business owns, with your billing details on it. Other people can have access to them. That is a different thing from the account belonging to somebody else.

Doing this on day one is filling in a form. Doing it later is a migration, sometimes an unpleasant one. If you cannot log in to the thing your business runs on, you are relying on a relationship rather than on an arrangement, and relationships end for ordinary reasons, including good ones.

Your data, and getting it out

Ask how you get all of your data out, in a form that is still useful to another system, and then do it once before the final payment rather than reading about it. An export nobody has ever run is not a guarantee, it is an intention.

Do the same with the code. Ask to be shown the repository and the deployment documentation while the project is still live, not at the end. Both should exist the whole way through.

Payments that line up with what you receive

A deposit before work starts is normal in every trade. What is worth looking at is the shape of the rest. Ask how payments are staged and what you can see at each stage.

The version to be careful about is one where most of the money is due before anything exists that you can open and use, because that removes your only real lever. You do not need a complicated arrangement. You need the stages to line up with things you can look at.

Checking credibility without hiring an investigator

• Ask about insurance. General liability and professional liability, which is also called errors and omissions. Ask for a certificate. We carry both, and ours is available on request.
• Ask what the paperwork is. A master services agreement with a per-project statement of work is the usual structure, and it is what we use. A single paragraph in an email is not a substitute for either.
• Ask to see something working. Not a portfolio image. Software running, with somebody explaining what problem it solved.
• Ask what happens when it breaks. Who you contact, what they do, and what it costs. Get the answer before you need it.
• Check the ordinary things. A registered business, an address, a phone number that a person answers, and names you can look up.

What a good answer sounds like

Specific, plain, and repeated in writing without a fuss. You are not looking for the most polished response. You are looking for one that survives being written down.

Vagueness under a direct question is the signal worth acting on, and it is worth acting on even when everything else looks right. Not because it proves bad intent. Because a question that cannot be answered clearly now is going to be an argument later.

If a project you are already in feels wrong

Stop adding scope first. More work on top of a project you are unsure about makes every option worse.

• Ask in writing for the current code and for where it runs.
• Take a copy of your data.
• Get the account details for anything your business depends on.
• Write down what was agreed and what has been delivered, side by side.

Then decide with better information. Half-finished software can often be picked up by somebody else, and what decides whether it can is whether you own what exists so far. Which is why the four questions at the top are the four questions at the top.

The whole sequence, from writing down the problem to taking delivery, is in part seven of this series.