Decide four things before you search
Most bad hires start before the first call. If you can’t describe what you want, every company fills the gap with its own guess — and their quotes can’t be compared, because each one is pricing a different product.
- 01
The outcome
What should be different once this is live? “Customers book appointments without calling us” is far more useful than “we need an app”.
- 02
The people who will use it
List every type of user: customers, staff, managers, admins. Each type adds its own screens and permissions, so this drives the size of the project.
- 03
The date that matters
A trade fair, a festive season, a funding round. A real date lets a good team plan backwards and tell you honestly what fits.
- 04
A budget range
You don’t have to share it on the first call, but know it. It decides whether you start with a complete product or a focused first version.
If you want a structure for this, our guide on writing a software project brief includes a template you can copy.
Agency, freelancer or in-house team?
| What matters | Freelancer | Software company | In-house team |
|---|---|---|---|
| Best for | Small, well-defined tasks | Complete products: design, build and launch | Long-term products that are your core business |
| Skills covered | Usually one or two | Design, frontend, backend, testing, deployment | Whatever you hire for |
| If someone leaves | Work stops | The team continues | You re-hire, which takes months |
| Your management effort | High — you coordinate everything | Medium — a project lead coordinates | High — you manage people and process |
| Paperwork | Varies | Company contract and GST invoice | Employment contracts and payroll |
For the first version of a business product, a small software company usually gives the best balance of cost, speed and continuity. Once the product proves itself and becomes central to your business, it often makes sense to build an in-house team and have the company hand over properly.
12 questions to ask — and what a good answer sounds like
How a team answers matters as much as what it says. Listen for specifics. Vague answers on the first call become vague deliverables later.
| Ask this | A good answer sounds like |
|---|---|
| What questions do you have about our business? | They ask about your users, your current process and what success looks like before they talk about technology. |
| How will you decide the scope and price? | A short discovery step that ends in a written scope, milestones and a fixed quote — not a number after a ten-minute call. |
| Can we see something similar you have built? | A live link or demo you can click through, and an honest note on which parts were theirs. |
| Who will actually work on our project? | Named roles: who designs, who builds, who tests, and one person who is your main contact. |
| How will we see progress? | A private preview link updated every week or sprint, so you judge working software, not status reports. |
| How are payments linked to the work? | Payments tied to milestones you approve — for example an advance to start and the rest on delivery. |
| What if we want to change something midway? | A clear change process: they estimate the change, you approve it in writing, then it is built. |
| Who owns the code and the designs? | You do, in writing, once the project is paid — with access to the code during the project. |
| Which accounts will be in our name? | Domain, hosting, app store and payment gateway accounts registered to your business, not theirs. |
| How do you test before launch? | Testing on real phones and browsers against the agreed scope, plus time for you to test it yourself. |
| What support do we get after launch? | A stated support period for fixes, and a clear option for ongoing changes after that. |
| What would you advise us not to build? | A real opinion. Good teams cut features that don’t earn their cost. |
Red flags that should end the conversation
- 100% payment upfront. Milestone payments protect both sides. A full advance removes your only leverage.
- A price before any questions. If they priced it without understanding it, the price will change later.
- No written scope. “We’ll handle everything” means nothing is defined — and nothing can be checked at the end.
- No visibility until the end. You should see a live preview or the code repository throughout the project.
- Accounts in their name. If the domain or app store listing belongs to the developer, you don’t fully own your product.
- Everything is “easy” and “quick”. Honest teams tell you what is hard and where the risks are.
- Only screenshots, never live links. Screenshots can come from anywhere.
How to compare quotes fairly
Quotes for what looks like the same project can differ several times over. Usually they are not quoting the same thing. Put each quote against this list and mark what is included:
- Design is included, not just development
- An admin panel for your own team is included
- User roles and main screens are listed
- Integrations are named — payments, SMS, WhatsApp, maps, accounting
- Testing on real devices is included
- Deployment, domain and SSL setup are included
- App store submission is included (for mobile apps)
- The support period after launch is stated
- Handover covers source code, credentials and documentation
- Hosting and third-party running costs are listed separately
A quote that leaves out half of these isn’t cheaper. It’s incomplete, and the missing parts come back as extra bills. We explain the main cost drivers in what decides the cost of custom software.
What the first two weeks should look like
Once you sign, a healthy project shows momentum quickly. Within roughly the first two weeks you should have:
- A kickoff call and a written plan with dated milestones.
- Agreement on the design direction — key screens or a style reference.
- One shared place where questions and decisions are recorded, instead of scattered WhatsApp messages.
- The first visible progress on a preview link you can open on your phone.
If two weeks pass with nothing but “we’re working on it”, raise it early. Delays rarely fix themselves.
Questions people ask
- Is it safer to hire a big company or a small one?
- Fit matters more than size. A small team that gives you a senior person as your contact is often better for a first product than a large firm where you are a small account. Always check who will actually work on your project.
- Should I sign an NDA before sharing my idea?
- It is reasonable to ask, and any serious company will sign one. In practice ideas are rarely copied — execution is the hard part — so don’t let the NDA delay a useful first conversation.
- How many companies should I talk to?
- Three is usually enough. Fewer and you can’t compare; more and the comparison turns into noise. Give all of them the same written brief so the quotes line up.
- Can I work with a software company in another city?
- Yes. Most software projects run remotely. What matters is a fixed weekly rhythm, one shared place for decisions and a live preview you can open at any time.
Planning something like this?
Tell us what you want to build. You’ll get a written scope and a fixed quote before any work starts.