Before You Spend $100,000 Building Software, Ask These 10 Questions
Someone in your business has a good idea. Maybe it’s an app for customers, or a system to replace the spreadsheets that run your operations. You ask a developer for a quote, and it comes back at around $100,000.
That’s a lot of money. When expensive software goes wrong, the cause is usually a question nobody asked before the work started. These are the ten we ask before anyone writes code. You can answer most of them yourself, this week, for free.
Written for Small business owners, founders and public-sector managers who are about to pay for software and don’t write code themselves.
The 10 questions
- 1. Do we really need custom software?
- 2. Can software that already exists solve this?
- 3. What business problem are we solving?
- 4. Who will use it, and how?
- 5. What should the first version include?
- 6. What will it cost to keep running?
- 7. Who owns the code and the data?
- 8. What happens if the developer leaves?
- 9. How will we know it worked?
- 10. What could go wrong if we build too much, too early?
Why these questions come before the code
Changing a plan costs an afternoon. Changing software after it’s built can cost weeks.
The cheapest time to find a mistake is before any code exists. Once software is built, every change touches other parts that already work, and each one has to be tested again.
The questions below are in the order we’d ask them. The first two decide whether you should build anything at all. The rest decide what to build, and how to protect what you paid for.
Questions 1 and 2: Do you need custom software at all?
1. Do I really need custom software?
Custom software is an application built only for you. It can fit your business exactly. You also pay for every feature, every fix and every update, for as long as you use it.
Most businesses don’t need it for most things. Accounting, payroll, email, scheduling and basic customer lists work the same way in thousands of companies. Products for those already exist, and they cost far less than anything you could build.
Custom software starts to make sense when the work is specific to you. It might be a way of pricing jobs that no product handles, or a process that ties together four systems your team copies data between. A public agency might have a rule or a reporting format that no off-the-shelf product supports.
2. Can existing software solve my problem?
Before you build, spend a week looking. Search for products made for your industry. Ask people who run similar businesses what they use. Check whether the software you already pay for has features nobody switched on. That happens more often than you’d think.
A product that does most of what you need is often a better deal than custom software that does all of it. Changing your process a little to fit a product costs less than building and maintaining your own.
Sometimes the answer is neither buying nor building. If your tools are fine but people copy information between them by hand, connecting the tools may solve the problem. That’s usually a much smaller job than a new application. Our article on software that works together explains how.
Should you buy, automate or build?
Three questions sort out most situations. Start at the top and follow your answers.
Start at the top. Stop at the first question you can answer yes. Most businesses stop before they reach “build.”
- Yes
Is this a common task that many businesses do the same way?Accounting, payroll, scheduling, email, a basic customer list.
Buy existing softwarePick a proven product and adjust your process a little to fit it.No - Yes
Do you already have the right tools, but people copy information between them?The apps work. The typing between them is the problem.
Connect and automateLink the tools you have so information moves on its own.No - Yes
Is the work specific to your business, and worth paying to maintain every year?A process no product handles, that matters to how you earn money or serve people.
Build custom softwareStart with a small first version. Grow it from real use.No - Don’t build yetKeep what you have, fix the process, and look again in six months.
The tree is a starting point, not a verdict. One hard requirement can change the answer, such as a law about where data must be stored, or a customer contract that needs a feature no product has. If you’re weighing a product against a custom build, Custom Software vs. SaaS compares the costs over five years.
Questions 3 and 4: The problem and the people
3. What business problem am I solving?
Write the problem in one or two sentences, without naming any technology. “We need an app” isn’t a problem. “Our sales team spends two days every month building quotes by hand, and customers often find mistakes in them” is a problem.
A clear problem tells the developer what to build and what to leave out. It also gives you a way to judge the result later. If you can’t write the problem down yet, you aren’t ready to pay someone to solve it. Working it out is the first step, and it costs much less than code.
4. Who will use the application?
Name the people, not the departments. The office manager entering orders at a desk. The technician on a job site with a phone and a weak signal. The customer who logs in twice a year and forgets how it works. Each of them needs something different.
Talk to them before anything is built, and watch them do the work the old way. The people who do the job every day know where the time goes and which steps can’t change. Software designed without them often looks good in a demo and gets ignored in real life.
Public-sector teams should include the residents or businesses who use the service, and check accessibility requirements early. Designing for accessibility from the start is much cheaper than adding it later.
Question 5: What should the first version include?
One problem, for one group of people. Everything else waits.
Developers often call the first version an MVP, short for minimum viable product. A plainer name is “the smallest thing that’s useful.”
Here’s a test for every feature on the list: if you removed it, would the first users still get value? If the answer is yes, it waits for a later version.
Say a company wants an app for its field technicians. The wish list includes scheduling, invoices, inventory, photos, customer signatures and a manager dashboard. The first version might only let technicians see today’s jobs and mark each one done with a photo. If they use it every day, you add the next piece. If they don’t, you learned that for a fraction of the cost.
- Wish list
Everything anyone asked for. Keep it, but don’t build it.
- First version
One job, done well, for one group of users.
- Real use
A few weeks of actual work. Watch what people do.
- Next piece
Chosen from what users asked for, not what was guessed.
Questions 6 to 8: What happens after launch?
6. How much will maintenance cost?
Software is more like a car than a building. It needs regular care to keep running safely. The parts it’s built from get security updates. Browsers and phones change. Your business changes, and the software has to follow.
A common planning rule is to budget 15 to 20 percent of the build cost every year. It’s a rule of thumb, not a measured number, but it’s a sensible place to start. For a $100,000 project, that’s $15,000 to $20,000 a year. Ask any developer for their own estimate, in writing, before you sign. If someone tells you the software won’t need maintenance, treat that as a warning.
| Cost | What it covers | If you skip it |
|---|---|---|
| Hosting | The servers or cloud services that run the software, usually billed monthly | The software goes offline |
| Security updates | Updating the building blocks the software uses when problems are found in them | Known security holes stay open |
| Fixes | Bugs found by users, and problems caused when other services change | Workarounds pile up and staff stop trusting it |
| Small changes | New fields, new reports, a rule that changed in your business | The software slowly stops matching how you work |
Ask for each of these as a separate line in any quote or maintenance agreement.
7. Who owns the code and the data?
Ownership depends on your contract, not on who paid. Your agreement should say the code and everything created for the project belong to you once you pay. Then make it real. The code should live in an account your business controls, not in the developer’s personal account. The same goes for the domain name, the hosting account and the database.
Your data is yours too. Make sure you can export all of it, in a common format, whenever you want.
8. What happens if the developer leaves?
People change jobs, close their businesses and get sick. If one person is the only one who understands your software, your business depends on that person. Ask now: is the setup written down? Could another developer take over in a few weeks? Are the passwords stored somewhere you control? We cover this in detail in What happens when the developer who built your software leaves.
Question 9: How will I measure success?
Decide what success looks like before the work starts, and write down today’s number.
Good measures are simple and tied to the problem from question 3. For example:
- Hours spent on the task each week
- Mistakes or complaints each month
- How long a customer waits for an answer
- How many of the intended users actually use the new software
If you don’t record the starting point, you’ll never know whether the $100,000 paid off. Neither will the developer, which means they won’t know what to improve next. Our article on the cost of manual work shows how to put a dollar figure on the hours.
Question 10: What are the risks of building too much too early?
Big first versions feel safer. They usually carry more risk.
- You pay for features nobody usesFeatures built on guesses often go unused. Each one still has to be tested, fixed and maintained.
- You learn too lateThe first real feedback arrives after the money is spent, when a wrong guess is most expensive to fix.
- The project runs longBigger projects have more surprises, and each surprise adds weeks.
- The software gets harder to changeMore features means more parts that can break when you change one of them.
- Your business moves onA year-long build can finish after the need it was built for has changed.
Small steps are safer. Build the first version, use it, measure it, then decide what comes next. You can always add more. Taking features out is harder, and you don’t get the money back.
What weak and strong answers sound like
Use this when you talk to a developer or compare quotes. Strong answers are specific, and they’re written down.
| Question | Weak answer | Strong answer |
|---|---|---|
| What problem are we solving? | “We need an app.” | “Quotes take two days a month and customers find mistakes in them.” |
| Who will use it? | “The sales team.” | “Four salespeople, mostly on phones, between customer visits.” |
| What’s in the first version? | “Everything on the list.” | “Create a quote from a price list and email it. Nothing else yet.” |
| What will upkeep cost? | “It won’t need much.” | “About $1,500 a month for hosting, updates and small changes, in writing.” |
| How will we know it worked? | “People will like it.” | “Quote time drops from two days to two hours, measured for three months.” |
The strong answers are examples. Yours will have different numbers. What matters is that they’re specific enough to check.
When to get a second opinion
If you have a quote in hand and can’t answer these questions yet, it’s worth an hour with someone independent before you sign. A good adviser will help you write down the problem, check whether a product or a simple connection would do, and size the first version.
Yippify is a small software engineering company. We build custom software when it’s the right answer, and we say so when it isn’t. If you’re still deciding who should do the work, our guide on hiring a developer, a consultant or a development company compares the options.
Frequently asked questions
How much does custom software cost?
It depends mostly on scope, the number of systems it connects to, and how clearly the problem is defined. Clutch’s pricing guide puts the average project on its platform at $132,480, though most projects there fall between $10,000 and $49,999. A small internal tool sits at the low end. A product with many users and integrations sits at the high end.
Is $100,000 a reasonable price for custom software?
It can be, for a system with several kinds of users, connections to other software, and security needs. It can also be far too much for a simple tool. Compare quotes against the same written description of the problem, ask what the first version includes, and ask for the yearly maintenance estimate in writing.
Should I build a small first version before the full system?
Almost always. A first version that solves one problem for one group of users costs less, ships sooner, and shows you what people actually use. You can add the next piece based on real use instead of guesses.
How much does it cost to maintain custom software?
A common planning rule is 15 to 20 percent of the original build cost each year, covering hosting, security updates, fixes and small changes. It is a rule of thumb, not a measured figure, so ask any developer for their own estimate before you sign.
Holding a quote, or about to ask for one?
Tell us the problem you want to solve and who would use the software. We’ll help you answer these ten questions, and we’ll tell you if buying a product or connecting the tools you already have would do the job.
- A plain answer: buy, connect or build
- A first version sized to the problem
- Ownership and upkeep agreed up front
A rough description is enough to start. No specification needed.