Before you hire an app developer, write a short brief in plain language: the problem you are solving, who will use the app, the few tasks it must handle on day one, how the work is done today, which systems it must connect to, what data it holds, any real deadlines, who makes decisions, and how you will know it worked. Two pages is plenty. You do not need a technical specification, and you should not try to write one.
Developers can work from a conversation, and a good one will ask the right questions. But the conversation goes much further when you have thought these points through first. You get an estimate based on your actual situation rather than assumptions, and you find out early whether an app is the right answer at all.
Why preparation changes the outcome
Most app projects that go wrong do so for reasons that were visible at the start: nobody agreed what the first version had to do, a key system turned out not to share its data, or the person who could approve decisions was never in the room. None of that is technical. All of it can be caught with an hour or two of preparation. The scope you describe is also the biggest single factor in what an app costs, as our guide to app development cost factors explains.
The brief, section by section
1. The problem, in one paragraph
Describe what goes wrong today, for whom, and what it costs in time, errors or lost business. "Our technicians write job notes on paper, the office retypes them, and invoices go out a week late" is a problem. "We need an app" is not. If you cannot write this paragraph, that is worth knowing before you spend anything.
2. Who uses it
List each type of user, how many there are, and what they need. A simple table works:
| User type | How many | Where and on what | Main need |
|---|---|---|---|
| Field technicians | Number of people | Phones, often with weak signal | See today's jobs, record work and photos |
| Office staff | Number of people | Desktop browsers | Assign jobs, check notes, send invoices |
| Customers | Rough count | Their own phones | Know when the technician is coming |
The number of user types matters more than the number of users. Each type usually means its own screens and permissions.
3. What it must do on day one
Write the core tasks as short stories from each user's point of view, then mark which ones are essential for the first version.
- "As a technician, I see my jobs for today in order, with the address and the customer's notes." Essential.
- "As a technician, I take photos and they attach to the job automatically." Essential.
- "As a manager, I see a weekly report of jobs per technician." Later.
Aim for a short essential list. The rest is a wish list, which is useful to keep but should not drive the first estimate. If you are unsure what can wait, our guide to MVP app development covers how to choose.
4. How the work is done today
Collect the real artefacts: the paper form, the spreadsheet, screenshots of the current software, the group chat where jobs are assigned. These show a developer the actual steps, including the exceptions people handle without thinking. Note what works well today, too. The new app should not lose it.
5. Systems it must connect to
List every system the app needs information from or must send information to: CRM, accounting, calendar, payment provider, inventory, an industry-specific package. For each, note the product name, who holds the admin login, and whether you know if it can share data with other software. Whether a connection is possible is checked during discovery, but knowing the list up front avoids nasty surprises.
6. The data
- What information the app will hold: customer details, job records, photos, payments, health or financial information.
- Where that information lives today, and whether existing records need to move into the app.
- Anything sensitive or regulated, and any rules your industry follows for it.
- How long records must be kept.
Sensitive data changes the design and the testing, so say so early. Our cybersecurity page covers the network protections around systems that hold it.
7. Platforms and devices
Say what your users actually carry and where they are when they use it, rather than choosing a technology. "Technicians use company Android phones in basements" is more useful than "we want a native app". The developer can then recommend phone apps, a web app or both; our comparison of native, cross-platform and web apps explains the options.
8. Deadlines, and why they exist
A real deadline has a reason: a busy season, a contract start, a trade show, the end of a software licence. Write the reason down. It helps the developer suggest what can be ready by that date and what can follow.
9. Who decides
Name one person who can approve designs and answer questions within a day or two, and anyone else who must sign off. Projects slow down most when decisions wait for someone who was never involved.
10. How you will know it worked
Pick one or two measures you can check after launch: invoices going out the same day, fewer calls asking where the technician is, hours of retyping removed. These shape the first version more than any feature list.
Materials worth gathering
- Your logo, colours and fonts, or your website if that is where the brand lives.
- Two or three apps you like, and what specifically you like about each.
- Sample data with private details removed, such as a week of jobs or a few anonymised customer records.
- Current forms, documents and templates the app will replace or produce.
- Any rules written down for how the work must be done.
Accounts and ownership to sort out
These are easy to arrange at the start and painful to untangle later:
- Domain name, registered to the business.
- App store developer accounts with Apple and Google, if the app will be in the stores, in the business's legal name. Verification can take time.
- Admin access to every system the app will connect to.
- Hosting and code: agree who holds the hosting account and the code repository, and in whose name.
Ask any developer how ownership, licensing and hosting will be set out in the agreement before work starts.
What you do not need to prepare
- A technology choice. Describe the job and the users; let the developer recommend the tools and explain why.
- Database designs or technical diagrams.
- Perfect screen designs. Rough sketches on paper are welcome, but design is part of the work.
- Every feature for the next five years. Keep a list, but do not let it set the first scope.
The budget conversation
It helps to say what matters most: the date, the feature list or the total investment. All three can rarely be fixed at once. If you have a range in mind, sharing it lets a developer propose a first version that fits instead of a quote you have to cut down. If you have no idea yet, say so; a good developer will explain what moves the number before giving one. And sometimes the honest answer is that an existing product does the job, as we discuss in custom software vs off-the-shelf.
A worked example
Hypothetical: the business and details are invented to show what a brief looks like. It is not a real client.
A landscaping company writes its brief in an afternoon:
- Problem: crew leaders get the day's jobs by text, write notes on paper, and the office retypes them. Invoices go out late and photos of finished work get lost.
- Users: 8 crew leaders on company phones, 2 office staff on desktops. Customers later, not now.
- Day one: crew leaders see the day's jobs in order, record time and materials, take before and after photos, and mark the job done. The office sees completed jobs ready to invoice.
- Today: a paper job sheet, a shared spreadsheet and a group chat, all attached.
- Systems: the accounting package, which holds customers and invoices. The office manager holds the login.
- Deadline: before the spring season, because that is when the backlog is worst.
- Decision maker: the owner, with the office manager reviewing screens.
- Success: invoices sent within two working days of a job being completed.
That brief fits on one page, and it already answers the questions that decide most of the estimate.
Questions to ask the developer
- What would you build first, and what would you leave for later?
- Phone app, web app or both, and why, for our users?
- How will you check that our systems can connect before committing to a price?
- Will we see designed screens before building starts, and working versions during the build?
- Who will we deal with day to day?
- How are ownership, hosting and support after launch handled in the agreement? Our guide to app maintenance and updates lists what support should cover.
Bring your brief to us
Our App Development service starts with exactly this kind of conversation. Discovery begins with the problem, not a feature list: who uses the app, what it must do on day one and which systems it needs to talk to. Then you see click-through screens in your colours, the build happens in stages, launch includes testing on real devices, and support is on terms set out in your agreement. If you do not have a brief yet, the first conversation can help you write one. Platforms, timelines and other specifics are confirmed in your consultation, and you get a written estimate before you commit. The consultation is free, Phil Morales is your point of contact throughout, and we usually reply the same day. Book a time, call 478-758-8091 or text (347) 870-0965.
