How do I spec an app before hiring a developer?

Write down the problem, who the app is for, what it must do and the rules it must follow, then have the people who actually do the work check it before any developer sees it. A good spec answers a developer's questions before they are asked, so the quotes you get are comparable and the build doesn't stall waiting on answers.

You don't need technical training to do this. You need the knowledge that is already in your business, written down in a form someone else can build from. Here is how to get there.

1. Start with the problem, not the features

Describe what goes wrong today, in plain words, and what should be true when the app exists. "Tools go missing from the tool room and nobody knows who had them last" is a better starting point than "we need a check-out app with barcode scanning." The problem keeps everyone honest about which features matter.

2. Name the people

List everyone who will use the app and what each of them needs to do: the technician checking out a tool, the manager reviewing who has what, the person in accounting who replaces lost equipment. Then name who decides when people disagree. Every project needs one person who can settle a question.

3. Walk through the work as it happens today

Follow one real case from start to finish and write down each step, including the exceptions. The exceptions are where most of the cost hides: the tool that is out for repair, the contractor who isn't in the system, the approval that happens by phone on weekends. The people who handle them every day often don't mention them unless asked.

4. Write each requirement as one testable sentence

"The app should be fast" can't be tested. "A technician can check out a tool in under 30 seconds" can. Give each requirement a number so it can be referred to later, and say how anyone would check that it works.

5. List the data and the systems it touches

What information does the app keep (tools, people, check-outs, locations)? What does it need from systems you already have, and what does it send back? A developer can't estimate an integration nobody mentioned.

6. Ask each expert separately, then compare

Operations, finance and the front line often describe the same process differently, and each is sure they are right. Ask each person about their part on their own, then compare the answers. Where they disagree, for example on who can approve what, take it to the person who decides and write down the decision and the reason.

7. Decide what is out of scope

A short list of what the first version will not do prevents most arguments later, and it makes quotes from different developers comparable.

8. Decide who will own it after it's built

Someone has to host the app, keep it secure, support its users, and one day retire it. Decide who before the build starts. An app nobody agreed to own becomes a problem quickly.

9. Get it signed off

Have the experts confirm the parts they supplied and the decision-maker approve the whole thing. Changes after sign-off are fine, as long as everyone can see what changed and why.

What should I hand the developer?

The approved document; the list of numbered requirements with how to test each one; the decisions and the reasons for them; the data and integrations list; what is out of scope; and who owns the app after launch. If the developer will use AI coding tools, a structured version of the same information helps those tools build from it directly. Ask every developer you talk to for a quote against the same spec.

What are the most common mistakes?

Specifying features instead of the problem; interviewing only the person who had the idea; skipping the exceptions; leaving disagreements between departments for the developer to discover; and leaving ownership of the finished app for later.

If you would rather not run this yourself, Mochlion runs the interviews and produces the specification; here is a sample of what you get.