How to Tell if a Software Idea Is Feasible Before You Pay for It
Six checks that decide whether an idea can be built, the ones you can run yourself, and what to do when the answer is no.
On this page
- Written for
- Anyone with a software idea who has not paid for a build yet
- Level
- Beginner
- Format
- Guide
- Series
- Getting software built
Almost anything can be drawn on a whiteboard. Whether it can be built, for a price that makes sense, with the data and the systems you have, is a separate question. The cheapest time to answer it is before a build starts.
This guide covers the six checks I run when someone brings me an idea. Several of them you can run yourself in an afternoon with no technical background. For each check you get the question to ask, how to look for the answer and what a bad answer looks like.
What “feasible” means
“Can it be built?” sounds like a yes or no question. In practice there are three answers.
- Feasible. It can be built as you described it.
- Feasible with changes. Most of it can be built. One or two pieces need to shrink, move or be replaced by something that already exists.
- Not feasible as asked. A piece the idea depends on can’t be done, or costs more than the idea is worth. There is often a nearby version that works.
“Feasible” also has three parts. An idea has to pass all of them.
- Technical. The software can do the thing at all.
- Economic. Building it and running it costs less than what it earns or saves.
- Practical. You have the data, the access and the people it needs.
Passing the first part is not enough. An idea can be technically possible and still fail because something around it is missing.
Check 1. Does the data exist?
Every piece of software works on information. The first question is where that information comes from and whether you are allowed to use it.
Ask: for each thing the software has to know, where does it live today, and who owns it?
How to check yourself: write a list of everything the software would need to show or decide. Next to each item, write where it comes from. Put a mark beside anything you wrote “somewhere online” or “the app will figure it out” for.
A bad answer looks like this: the idea depends on information that nobody collects, that belongs to another company, or that would have to be typed in by people who have no reason to do it. An app that shows live prices from every supplier in your trade needs those suppliers to publish their prices. If they don’t, there is nothing to show.
Check 2. Will the other systems cooperate?
Most useful software connects to something else: an accounting package, a calendar, a payment processor, a supplier’s ordering site. Whether that works depends on the other system.
Ask: does each tool have a supported way for outside software to read from it and write to it? In technical terms this is called an API.
How to check yourself: search for the tool’s name plus “API” or “integrations”. Look for a public developer page. Check whether it is included in the plan you pay for, because it is often limited to higher tiers. If you can’t find anything, email the company’s support and ask: “Can outside software read and create records in my account?”
A bad answer looks like this: the tool has no API, or it has one that reads data and can’t write it, or the feature is only on a plan that costs far more than you pay now. Software that works by logging in and clicking through someone else’s website the way a person would is fragile. It tends to break whenever that site changes, and it may be against the site’s terms.
Check 3. Do the platform’s rules allow it?
Some ideas are technically simple and blocked by rules. App stores review what they publish. Phone carriers have requirements for businesses that send text messages. Payment companies restrict certain kinds of business. Email providers limit bulk sending. Industries such as health care and finance have laws about how records are stored.
Ask: who controls the channel this software uses to reach people, and what do they require?
How to check yourself: list every way the software touches the outside world: an app store, text messages, email, card payments, phone calls. Search for each one’s policy for business use. If your industry has a regulator, look at what it says about electronic records.
A bad answer looks like this: the main feature is the thing the platform forbids. Rules that add a step, such as a registration or a review period, are fine as long as you know about them early. They change the schedule. Rules that ban the feature change the idea. For anything touching legal or regulatory requirements, I name the question and tell you to confirm it with someone qualified in that field. A software engineer is the wrong person to give you a legal opinion.
Check 4. What is the hard part, and has anyone solved it?
Every idea has one piece that is harder than the rest. Login screens, forms, lists and reports are ordinary work. The hard part is the piece that makes your idea different.
Ask: which single piece, if it didn’t work, would make the rest pointless?
How to check yourself: describe the idea to someone in two sentences. The part you find yourself explaining for longest is probably the hard part. Then search for a product that already does that one piece, even in a different industry. If one exists, the piece is possible. If nothing does, either you found a gap, or others tried and hit a wall. Both are worth knowing.
A bad answer looks like this: the hard part requires perfect accuracy from something that is never perfect. This comes up most with AI features. A language model can draft, summarize, sort and extract, and it is good at all four. It also makes mistakes at some rate, and that rate is never zero. So the question to ask about an AI feature is what happens when it is wrong.
| If a mistake means | Then the feature is |
|---|---|
| A person sees a slightly worse draft and fixes it | Feasible |
| A person has to review every output before it goes out | Feasible, and the review time is part of the cost |
| A wrong answer reaches a customer with nobody checking | Feasible with changes. Add a review step or narrow the task |
| A wrong answer costs money, breaks a law or hurts someone | Not feasible as asked, unless a person makes the final call |
Check 5. What does it cost to run?
The build is a one-time cost. Running the software is a monthly one, and it does not stop.
Ask: what gets charged every month this software exists, and what gets charged every time someone uses it?
How to check yourself: list the paid services the idea would use. Typical ones are hosting, text messages, email sending, maps, payment fees and AI model usage. Each publishes its prices. Estimate how many times a month each would be used, and multiply. Use your real volumes from today, and then try again at five times that.
A bad answer looks like this: a cost that grows with every use, attached to a product that earns a flat fee or nothing at all. If each customer action costs you a few cents and customers can take as many actions as they like, your costs rise with popularity. That can be fixed with limits or pricing, and it needs to be designed in from the start.
Check 6. Who keeps it alive?
Software needs someone to look after it. Services it depends on change, security updates come out, and the people using it need help.
Ask: in a year, who answers when it stops working, and who inside your business makes sure people use it?
How to check yourself: name the person. If the software depends on staff entering information, ask those staff whether they would do it. Software that the team quietly ignores has failed even though every feature works.
A bad answer looks like this: nobody has the job, or the idea needs people to change a habit and gives them nothing back for doing so.
The six checks on one page
| Check | The question | You can check it yourself by |
|---|---|---|
| 1. Data | Does the information exist, and can you use it? | Listing every input and where it comes from |
| 2. Other systems | Will each tool let outside software in? | Searching the tool’s name plus “API”, and checking your plan |
| 3. Platform rules | Does the channel allow this? | Reading the business policy for each channel |
| 4. The hard part | Has the difficult piece been done before? | Finding one product that already does it |
| 5. Running cost | What does each month and each use cost? | Multiplying published prices by your real volume |
| 6. Upkeep | Who looks after it? | Naming the person |
An afternoon of checking, step by step
You can get through a first pass in a few hours.
- Write the idea as one job for one kind of person. The brief template helps.
- List every piece of information it needs and where each comes from.
- List every tool it must connect to, and look up whether each has an API on your plan.
- List every channel it uses to reach people, and skim each policy.
- Name the hard part and search for one product that does it.
- Look up prices for the paid services and multiply by your volume.
- Write down who would maintain it.
Mark each line as “fine”, “not sure” or “problem”. The “not sure” lines are the ones worth paying an engineer to answer.
A worked example
This example is hypothetical. It is invented to show how the checks play out.
Someone wants an app where customers photograph a broken appliance and get an instant, exact repair price.
- Data: the business has a price list for common repairs. That part passes.
- Other systems: none needed for a first version. That part passes.
- Platform rules: a phone app has to go through app store review. That adds time. A web page that works on a phone avoids it.
- The hard part: identifying the fault from one photo, exactly. A model can often name the appliance and suggest likely faults. It can’t see inside the machine. An exact price from a photo is the piece that fails.
- Running cost: each photo analysis has a small fee. At the business’s volume this is minor.
- Upkeep: the office manager would handle the requests that come in.
The verdict is feasible with changes. The customer sends a photo and a short description. The software suggests the likely repair and a price range from the list, and the office confirms it before the customer sees it. The promise changes from “instant exact price” to “a confirmed estimate the same day”. That version can be built.
When the answer is no
A no on one check does not have to end the idea. There are four ways forward, and one of them often fits.
- A smaller first version. Drop the piece that failed and build what is left. Be clear with yourself about what you give up.
- A product that already exists. If your search for the hard part turned up something that does most of the job, it may cost less than a build.
- A spreadsheet and one automation. Many ideas are a list plus a rule. A shared spreadsheet and one automatic step can cover that for a long time.
- Wait. Sometimes the missing piece is a tool that does not allow connections yet, or a model that is not accurate enough yet. Write down what would have to change, and check again in six months.
A clear no before you spend on a build is a good result. It leaves your budget intact for the version that works.
When to pay for an answer
Running these checks yourself will settle a lot. It will also leave you with a few lines marked “not sure”, and those are where an engineer earns their fee. Reading an API’s documentation to see what it really allows, estimating running costs at volume, and judging how reliable an AI feature will be all take hands-on experience.
That is what my consulting session covers. You send me what you have, we go through the idea piece by piece, and you leave with a written verdict and a roadmap. The verdict says feasible, feasible with changes, or not feasible as asked, along with the risks I would test first. The page is yours whether I build it, you build it yourself with coaching, or you take it to another developer.
If the answer is yes and you want it built, custom software explains how I scope and quote. For the full path from idea to handoff, start with How to Get Custom Software Built When You Are Not Technical.