The short answer
To get a software quote, send a developer one page that answers eight things: the problem in two sentences, who uses it, three to seven things it must do written as "a user can..." sentences, what it must connect to (payments, email, accounting), who the admin is, a rough budget and deadline, one or two apps you like, and what is not in the first version. That is enough for a developer to ask the right questions and give you a believable range.
You do not need drawings, technical language or a finished specification. A short, honest brief gets a better and faster quote than a long, vague one, and a sensible developer will still scope the project with you before fixing a price. If you have written a brief for a web designer before, this is the same idea extended to software and apps: see what to give your web designer.
What to write down before you contact a developer
What do I write down and send a developer so they can quote me?
Write these eight answers in plain English. One or two sentences each is fine. Bullet points are fine. Typing them into an email or a message is fine.
- The problem in two sentences. Say what is going wrong today and who feels it. "Our guests book by phone and we lose bookings when nobody answers" is a good start. Do not describe the solution yet.
- Who uses it. List every kind of person: customers, your staff, a manager, a partner. Each kind of user usually means a different screen, so this list drives the size of the project.
- What it must do, in three to seven sentences. Start each one with "A user can..." for example "A customer can pick a date and pay a deposit" or "A staff member can mark a booking as paid". If you need more than seven, you are probably describing version two.
- What it must connect to. Name the payment provider you want or already use, the email or WhatsApp tool, your accounting software, and any existing website or spreadsheet it must read from. Every connection adds work, so list them honestly.
- Who the admin is. Name the person (or the job) who will manage it day to day, and what they must be able to change without calling a developer: prices, photos, users, refunds.
- Rough budget and deadline. A range is fine. If you are unsure, run your idea through our software project cost calculator first and tell us where you landed. Say whether the deadline is fixed by something real, like a season or a launch event, or just a wish.
- Examples of apps you like. Two or three, with one line on what you like about each, and one thing you do not like. This is the fastest way to show taste without drawing anything.
- What is NOT in the first version. Write this down on purpose. It protects your budget and your deadline, and it tells the developer where to stop.
A filled example: a booking tool for a small guest house
Here is what the eight answers look like when they are filled in. The business is made up for this example, and your own brief can be shorter or rougher than this.
Problem. Guests book by phone and message, and I lose bookings when nobody answers. I also double book rooms because the calendar lives in a notebook.
Who uses it. Guests booking a room. Two reception staff. Me, as owner.
What it must do. A guest can see which dates are free for each room type. A guest can book and pay a deposit online. A guest gets a confirmation email with the dates and the balance due. A staff member can add a phone booking so it blocks the dates. A staff member can mark the balance as paid. The owner can see a list of upcoming arrivals for the week.
Connects to. One card payment provider. Email for confirmations. A monthly export my accountant can open in a spreadsheet.
Admin. Me and the head receptionist. We must be able to change room prices and block dates ourselves.
Budget and deadline. I have tried an online cost calculator and can spend up to the upper end of the range it gave me. I want it live before the busy season opens in about five months.
Apps I like. I like booking sites that show a calendar with the price on each night. I do not like checkouts that take many steps.
Not in version one. A mobile app, discount codes, a loyalty scheme, multiple languages, and connecting to other booking websites.
That page took ten minutes to write and contains almost everything a developer needs to start asking useful questions. A customer portal, an internal tool or a first version of a software product follows the same shape: only the sentences change.
How detailed, what to leave out, and whether you need designs
How detailed does my brief need to be?
One page is plenty, and two is the most that helps. The test is simple: could a stranger read it and describe back to you what you want? If yes, it is detailed enough. Where you are unsure, write "not sure" instead of guessing. A clear "not sure" is more useful to a developer than a confident guess that turns out wrong, because it tells them where to ask.
What should I leave out of the first version?
Leave out anything that is not needed for your first real customer to use it and for you to get paid. Common things to cut: a mobile app when a mobile-friendly website will do, several languages, discount and loyalty features, fancy reports, and connections to every other tool you own. Everything you cut now can be added later, and a smaller first version is cheaper, faster and teaches you what users actually do. This is the idea behind a minimum viable product, and our guide to SaaS MVP development goes deeper if you are building a product to sell.
Do I need drawings or designs before I talk to a developer?
No. Rough sketches on paper, a screenshot of an app you like with notes written on it, or a photo of a whiteboard are all useful, but none of them is required. Proper screen designs are part of the project and a good developer or designer will make them with you. Paying for finished designs before you have agreed the scope is a common way for owners to spend money too early.
Why a brief gets a better and faster quote
A quote is a guess about work that has not happened yet. The less the developer has to guess, the closer the number is to the final cost. A clear brief removes the biggest unknowns: how many kinds of users there are, how many things connect to the outside world, and how much is in version one, and whether you already have data in spreadsheets that must be moved in. It also shortens the back and forth, which is a common source of early delay.
Here is how it plays out on the kinds of projects owners usually bring us, with our starting prices. These are starting points, not quotes, because the final price depends on your answers.
| What you are building | Our price | What a clear brief changes |
|---|---|---|
| A custom booking tool, portal or internal system | Your "a user can..." sentences become the build list, so the quote is based on real features. | |
| A customer relationship system built around your process | Naming the connections and the admin up front avoids surprise work later. | |
| A mobile app on one platform | A clear "not in version one" list keeps the first release to one platform. |
Time works the same way. If your deadline is tied to something real, say so, because it changes what we recommend leaving out. Our guide on how long it takes to build a website or app shows what drives the schedule.
Why do we still scope together before fixing a price?
A brief tells us what you want. A scoping conversation finds what you have not thought of yet: the awkward case, the old spreadsheet nobody mentioned, the approval step your accountant needs. We would rather find these in a conversation than in the middle of the build. After that we give you a fixed quote before work starts, so the number you approve is the number you pay.
What happens after you send it, and when we are not the right fit
Send your brief through the quote form or on WhatsApp at +256 702 946 946. Here is what follows.
- A person reads it. A senior engineer reads your brief and replies with the questions that would change the price. Expect questions, not a sales script.
- A video call. We scope it together on a call. Our team in Kampala works East Africa Time (UTC+3), which overlaps the UK and European working day and the start of the US East Coast day, and a US team member joins the call.
- A fixed quote. We write up the scope and give you a fixed quote before work starts, with the 50/25/25 payment plan. You own the code and the data.
- The build, with a team that stays. We aim to keep the people who scoped your project on it, so you are not re-explaining everything to a new face. Growth Informer Software Services is a US-based company with remote teams, and we have 37 live website and app builds on our portfolio page. See our custom software development services for how we work.
We are not the right fit in every case. If you only need a simple brochure website, a template site will cost you less. If you need something working in a few days, we cannot honestly promise it. And if you cannot yet say who the users are or what problem you are solving, spend a little time on that first. A brief written badly on purpose, just to get a number, wastes everybody's time.
Frequently asked questions
How detailed does my software brief need to be?
One page is plenty. If a stranger could read it and tell you back what you want, it is detailed enough. Where you are unsure, write "not sure" so the developer knows where to ask.
What should I leave out of the first version?
Leave out anything your first real customer does not need and that does not help you get paid: extra platforms, several languages, discount and loyalty features, fancy reports and connections to every other tool. Write the list down so everyone agrees where version one stops.
Do I need drawings or designs before I talk to a developer?
No. Rough sketches, screenshots of apps you like with notes, or a photo of a whiteboard help, but they are optional. Finished screen designs are part of the project and are best made after the scope is agreed.
How much does custom software cost if my brief is clear?
Custom systems start from with us. A clear brief lets us turn that starting point into a fixed quote based on your actual features, users and connections.
Why scope together if I have already sent a brief?
A brief says what you want. A scoping call finds what has been missed, such as awkward cases and hidden connections. We do this before giving a fixed quote so the price does not change mid project.