How to start a software business in 2026

The tools for building software are incredible now. With Lovable, Claude Code or v0, someone who has never written a line of code can have a working app in a few days. That's brilliant news if you've spent years watching a problem in your industry and wishing someone would fix it. You can fix it yourself.

It also means anyone else can build your idea. So can a competitor with more money, and quite often so can your customers, by asking ChatGPT to do the job your software would do.

So the question that decides whether your idea becomes a business is the one it always was: will people choose it, pay for it and keep using it? When CB Insights read through startup post-mortems, "no market need" came up again and again as one of the main reasons founders gave for failing. That was true long before AI. What's changed is how easy it is to build something nobody needed, and how quickly you can find out whether anyone does.

This guide shows you how to find out, using your own idea. Keep it in mind as you read, and by the end you'll have your guesses written down and a good idea of what to do next.

What's different in 2026

Three things have changed, and each one affects how you should work.

1. You can build in days. That's a real advantage, because you can put something in front of customers far sooner. The risk is that building is so easy and so satisfying that you keep going while learning very little about who will pay. It's easy to mistake a growing product for a growing business. I've written about that trap before: the Product Illusion.
2. So can your competitors. If your idea works, someone can copy the features quickly. What takes them much longer to copy is knowing your customers better than anyone else does.
3. So can your customers. Plenty of jobs that once needed their own app can now be done with a good prompt in a general AI tool, or by the customer building their own version. Your software has to be worth more than that.

So build, but keep talking, selling and delivering at the same time, and let what customers do decide what you build next.

Write down your guesses

Every new software idea rests on a handful of guesses. Who it's for. What's bothering them. Why they'd choose you. What the product needs to do. What they'd pay. You probably have answers to all of these already, even if they're only in your head.

The trouble is that they feel like facts, and they're connected. Change who it's for and the problem changes, and so does what they'll pay. We call these connected guesses your Business Hypothesis.

It helps to picture them across two worlds. Your customer's world is where the problem lives, and you don't control it. Your world is what you build and decide. Between them is your offer: the promise you make them, and the price and package you ask them to accept for it. That's where the two worlds meet. You know your own world well. What you know about theirs starts as guesses.

There are five elements to work through, and each one matters for a reason.

Customer

Who is it for, who needs it first, and how will you find them?

It's tempting to make your software for everyone. A bigger market feels like a bigger opportunity, and narrowing it down can feel like thinking small.

Years ago, I worked on a video platform that we pitched as the place where anyone could publish anything for everyone to watch. It's an easy vision to get swept up in, because it sounds ambitious and exciting. It was also the problem. A platform for everyone needed every feature for every kind of video, from a gaming stream to a wedding to a training course, so there was always more to build before it was ready. And there was no way to describe it that made any particular person think "that's for me". Who would we sell it to first, and where would we find them? We never had a good answer.

Starting narrow fixes all three problems. You only build what one group needs. Your promise can speak directly to them, in their words. And you know where to find them. People in the same group also talk to each other, so a happy customer leads to the next one.

You can still have a grand vision. You just need a plan for getting there, one step at a time. Jeff Bezos wanted to build a store that sold everything, which is why Amazon's logo has an arrow from A to Z. But he started with books. There were millions of titles in print, far more than any shop could stock, so an online store had an obvious advantage. A book is the same wherever you buy it, so people were happy to order one without seeing it first. And books are cheap to post and easy to catalogue. Once Amazon had won book buyers, it used the same customers, website and warehouses to add music and films, then electronics, toys and almost everything else, and later let other sellers use it too.

So pick who needs it most. Your first customers should be the people with the most painful version of the problem, because they're the ones who'll try something new and forgive a rough first version.

Then work out how you'll reach them. This is the part that's easiest to gloss over, and it matters as much as the product. How you find customers and sell to them, often called your go-to-market, decides whether a good product becomes a business. If you can't reach the right people at a cost that's less than they're worth to you, and keep doing it month after month, the product's quality doesn't save you.

Your first few customers will probably come from people you know, and that's fine. The harder question is where customer 20 and customer 200 come from. The usual routes are places your customers already gather (trade shows, associations, online communities), people who already sell to them (suppliers, consultants, accountants), software they already use (an integration or a listing in its marketplace), and your existing customers telling others.

Each route shapes the rest of your hypothesis. Selling through a partner means giving them a cut, so your price has to allow for it. Selling online with no conversation means setup has to be simple enough to do alone. Selling to larger companies means a sales process measured in months. So pick a likely route now, and try it alongside the product.

If you've worked in the industry, you're already ahead. You know people with the problem, you know where they meet and you know how they talk about it. That's exactly the kind of advantage a competitor copying your features can't copy.

A useful answer is specific enough to find the people:

• Vague: "small businesses"
• Useful: "office managers at accountancy firms with five to 20 staff, starting with the ones I know through my old firm, then reached through regional accountancy networks"

Your turn: write down who needs it most, what makes their version of the problem the most painful, and three places you could find twenty of them. If you're still deciding whether the idea is worth pursuing at all, see how to know if a SaaS idea is worth building.

Problem

What are they struggling with, what do they do about it now, and what does it cost them?

What they do about it today is your real competition, even if it's a spreadsheet, a phone call or putting up with it. Before Calendly, most people booked meetings with a run of emails going back and forth about times. That was the competition, and it's why "send a link and let them pick a time" was such an easy thing to understand.

What it costs them tells you how much the problem is worth. If a problem costs a business £300 a week, a £49 monthly fee is an easy decision. If it costs £30 a week, it isn't. Cost can be money, time, stress or risk, but the clearer you can make it, the easier the rest becomes.

• Vague: "chasing invoices is a pain"
• Useful: "office managers spend about four hours a week chasing late invoices, and the firm waits an average of 50 days to be paid"

Your turn: write down what your customers do about the problem today, and what it costs them each week or month.

Promise

What outcome are you promising, and why would they choose it?

Your promise is the outcome you're offering, said in their words. It's one half of your offer. The other half, the price and package, comes under Commercial.

Your promise also has to beat everything else they could do instead. That includes what they do now, a competitor's product and asking a general AI tool. If a customer could get most of the way with a good prompt, your promise needs to explain what they get from you that they can't get from that.

• Vague: "an AI-powered platform for streamlining operations"
• Useful: "get paid a fortnight sooner, without anyone in the office chasing clients"

Your turn: write your promise in one sentence a customer would say out loud, then list the three things they'd do instead and why they'd pick you.

Solution

What must the first version do to keep that promise?

Only what's needed to deliver the outcome. Everything else can wait, and we'll come back to how small that can be.

• Vague: "a complete accounts management platform"
• Useful: "polite reminders that go out automatically when an invoice is overdue, and a list of who's late each Monday"

Your turn: write down the smallest thing that would keep your promise for your first customers.

Commercial

What will you charge, how will you package it, who pays, and will that cover what each customer costs you to serve?

The Commercial element spans both sides. The price and package are the other half of your offer, the part the customer sees. How you charge and what each customer costs you to serve sit in your world.

Price is part of the hypothesis from the start, because it changes everything else. A product at £10 a month needs thousands of customers who can sign up on their own. A product at £1,000 a month needs far fewer, and they'll expect to talk to you first.

Packaging is what each price includes and who it's for. Slack, for example, charges per active user, and only for people who actually use it, which makes it easy for a team to start small and grow. A single business might pay one price, while a group of businesses pays per site, or a bigger plan adds features a small customer doesn't need.

Who pays isn't always the person who uses it. In a business, the people with the problem are often not the ones holding the budget: a team might use your software every day while a finance director or business owner signs off the spend. Your promise has to land with both.

Cost to serve is what each customer costs you, including payment fees, the time you spend setting them up and supporting them, and any AI your product uses.

• Vague: "freemium, then a subscription"
• Useful: "£49 a month per firm, with a 30-day trial, and I'll set each one up myself for the first ten customers"

Your turn: write down a starting price, what it includes and roughly what each customer will cost you to serve. There's more on this in how to price B2B software for your first customers.

Any of your answers could be wrong. Maybe the person with the problem isn't the person who can buy. Maybe the price is far too low, or far too high. Writing them down gives you something to check against what customers actually do.

Cross into their world

Everything you've written down so far comes from your world. To find out what's true, you have to go into your customers': talk to people, put something in front of them, ask them to pay and deliver what you promised. Their world won't move for you, so you move towards it, changing your promise, your price and your product as you learn.

You don't have to do these one at a time. Talk, build, sell and deliver can all happen in the same week, and each one teaches you something the others can't. A conversation suggests a change, you build it that afternoon, and you show it to the same person the next day with a price on it.

The Evidence Loop

It still helps to have a rhythm, so the learning doesn't get lost in the busyness. We call it the Evidence Loop, and it has five steps. To make each one concrete, imagine you're working on the invoice-chasing idea above.

1. Choose what to find out. What do you most need to understand to move forward? A good place to start is the guess that's most likely to be wrong and would hurt most if it were. If you've lived the problem, that's often whether people will pay, whether the person with the problem can sign off the spend, or whether you can reach enough of them. Say you decide to find out whether office managers would trust software to chase their clients for them.
2. Make a useful move. Have a conversation, build something, make an offer or deliver the outcome yourself, whichever helps you find out. You build a rough version in an afternoon that drafts the reminders, and ask two office managers you know if you can sit with them while they try it on last month's overdue invoices.
3. See what customers do. Give the right people a real chance to respond, try it, buy it or come back to it, and watch closely. One works through it happily. The other stops at the first reminder and says she'd never let anything email a client without her checking it first.
4. Make sense of what happened. What does it tell you, what surprised you and what's still unclear? Neither reaction settles anything, but the second one is a real worry you hadn't thought about, and probably not hers alone.
5. Decide what comes next. Keep going, change something, look into it further or stop. You change the next version so every reminder waits for a click before it's sent, and plan to show it to three more office managers next week.

Building belongs throughout this loop. When a rough version takes an afternoon, letting a customer try it can teach you more than another week of planning. Building early is fine, as long as what customers do with it shapes what you build next.

When you're running a specific test, it's worth writing down beforehand what result would change your mind. Otherwise every result looks encouraging, and "two people were quite interested" becomes a reason to carry on. Something like:

If fewer than [3] of the [5] [people who fit my customer] I speak to describe [the problem] from the last [fortnight] without me prompting them, I'll look again at whether it's common enough.

That won't always give you a clear answer, and it isn't meant to. It keeps you honest about what you're seeing.

Then keep the loop moving quickly. Trying something costs far less than it used to, and that's true for your competitors too, so waiting has become the riskier choice. When you're unsure what to do next, pick the move that puts something real in front of customers sooner.

Useful moves for each element

Each element of your Business Hypothesis has its own question, and some moves are better at answering it than others.

• Customer: Can you reach them? Try to book five conversations in a fortnight, with at least two coming from outside your own network. If you can't, that tells you how hard selling will be once your contacts run out.
• Problem: Is it real, and what does it cost? Ask about the last time it happened, what they did about it and what it cost them. Better still, ask them to show you.
• Promise: Does it make sense to them? Put a one-page website with your promise and a price in front of people who fit your customer, or show them a rough version, and see what they do next. Do they ask questions, book a call or ask when they can start?
• Solution: Does it work? Let a few customers use a rough version on their real work, or deliver the outcome by hand for them. Watching what they do with it teaches you what the product really needs.
• Commercial: Will they pay? Ask for money, or a commitment to pay. More on this below.

Finding your first five conversations

Start with people you already know: former colleagues, people you've worked alongside, suppliers and customers from previous jobs. Then try industry groups, local business networks and LinkedIn. A short, honest message works best:

Hi [name], I'm looking into how [type of business] deals with [the problem], and I'd love 20 minutes to hear how you handle it. I'm not selling anything yet. Would you be up for a quick call next week?

Five conversations won't give you statistics, and they don't need to. They'll show you whether the problem is real, how people describe it and who makes the buying decision.

Judge what people do

In these conversations, it's tempting to ask about the future. "Would you use this?" "How much would you pay?" People want to be helpful, so they say yes. It's like asking someone whether they plan to go to the gym every week next year. Almost everyone says yes, and January tells a different story.

So ask about the past and the present. When did this last happen? What did you do about it? What did it cost you? What have you already tried? There's a fuller list in what to ask potential customers about your idea. Rob Fitzpatrick's book The Mom Test is the best guide to this, and it's a quick read.

Then judge people by what they do. Someone saying they'd use it is weak evidence. Trying it on a real task is stronger. Paying shows they're willing to commit. And coming back when the need comes round again shows your product has a place in their work.

Making sense of messy results

This is the hard part, and it's where most of the real work is. Results rarely come back clean. Here's what tends to happen, and what helps.

• People sound interested, but nothing happens. Polite interest costs nothing. Look for what someone did: booked a follow-up, shared their numbers, introduced a colleague, tried it on real work. If they did none of those, treat it as a maybe at best.
• Feedback conflicts. One person loves it and another wouldn't touch it. Before deciding who's right, check whether they're really the same customer. Different reactions often mean different situations, sizes of business or roles, and that can tell you who to focus on.
• A result surprises you. That's usually the most useful thing you'll learn. Write down what you expected and what happened instead, then ask why before you change anything.
• The answer is "it depends". Then you've probably found the next thing to find out. It's normal to come back to the same question two or three times as your offer changes.
• You want it to be true. Everyone does. This is where writing down beforehand what would change your mind earns its keep, and where talking it through with someone who isn't attached to the idea helps.

Evidence helps you decide what to do next, even when it doesn't prove anything outright.

Why a yes doesn't always mean a sale

Here's a frustrating pattern you'll probably meet. A customer sees your demo, says it's exactly what they need, and a month later they're still using the spreadsheet.

The jobs-to-be-done framework explains why. People buy a product to make progress in a particular situation, and switching to yours means leaving business as usual: how they handle it today. The framework describes four forces at work. Two make them want to switch:

• Push of the situation. Something about how they do it today is frustrating enough to want a change.
• Pull of your product. The better future your product offers them, which is your promise.

Two keep them where they are:

• Habit of the present. What they do now is familiar, and it works well enough most of the time. These days, habit might also be "I'll just ask ChatGPT".
• Anxiety about switching. They worry it won't work, will be a hassle to set up, or will make them look silly if it goes wrong.

People switch when the push and the pull are stronger than the habit and the anxiety.

So when someone loves the demo and still doesn't switch, the pull is usually fine. They've just told you they like it. The tempting response is to add features, which adds more pull where there's already plenty. It often works better to reduce the anxiety instead, with a short pilot, a guarantee or doing the setup for them. That's also what makes the next step, asking for money, much easier.

The same forces apply to founders, by the way. Building is a comfortable habit, and talking to customers creates anxiety. That's a big part of why the Product Illusion is so hard to leave.

Your turn: write down what would make a customer anxious about switching to you, and one thing you could do to reduce it.

Ask for money early

Asking someone to pay tells you far more than asking whether they like the idea. A payment means they've accepted your promise and your price, which is a real commitment across the gap between your world and theirs. So don't leave the price until the end. Put it into the conversation sooner than feels comfortable.

You don't need finished software to do this. You can sell the outcome and deliver it by hand at first, or alongside a rough version. It helps to have the words ready:

It's [£49 a month]. I'm only taking on [three] [customers] to start with, and I'll [set it up and run it with you myself] while the software is being built. Would you like to be one of them?

There's more on this in how to pre-sell software before building it. If they're keen but not ready to pay, ask for a pre-order, where they pay now for something you'll deliver later, or a letter of intent, a short signed note saying they'll buy at a stated price once it's ready. If you offer early customers a discount, make it a fair trade: a lower price in return for feedback and a case study, with an end date.

A payment matters, and there's still more to learn after it. It shows someone accepted your offer. Whether they get the outcome you promised, come back when they need it again and keep paying is what you find out next, and that's where a business starts to take shape.

Use AI to learn, as well as to build

AI is just as useful for learning as it is for building.

• Research. Ask it to map who has the problem and what they use today, for example: "List the ways [type of business] handles [the problem] today, the software they use for it and what it costs." Then check what it tells you, because it will happily fill gaps with confident guesses.
• Something to react to. A one-page website with a price, or a rough working version, takes an afternoon now. People react much more honestly to something real than to a description.
• Rehearsal. Practise the conversation first: "You're [a busy office manager at a small accountancy firm]. You're sceptical about new software and short on time. I'm going to ask you about [the problem]. Answer realistically, and push back if I start pitching."
• Making sense of it. Paste in your notes from five conversations and ask where people agreed, where they contradicted each other and what nobody mentioned. It won't make the decision for you, but it helps you see the pattern.

You can do all of this on your own or with ChatGPT. We built Sal, a free AI business coach, for the parts that are hardest to do alone: working out which move to make next, then making sense of what happened and updating your plan.

When to invest in the first real version

You'll be building rough versions all along, to learn. At some point the question changes from "what can I try this week?" to "what's worth building properly?" That's the moment to invest in a first real version, and it usually comes when what customers have done gives you a clear enough picture of who it's for and what it must do. Ideally, at least one of them has paid or committed to pay.

You won't know everything, and you never will. But by then you know who the first version is for, what it has to do and what to leave out, which makes it smaller and quicker to get right.

Start smaller than you think

The first version of most software is much smaller than its founder expects. It only needs to deliver the one outcome your first customers are paying for.

A simple way to keep it small is a roadmap with three columns. Now is everything you need to deliver that smallest first version. Next is what you expect to build once customers are paying. Later is what you'll build only if customers keep asking for it. Now is a commitment. Next and Later are your current best guesses, and what you learn from customers will almost certainly change them. That's fine. They still give you a direction, keep good ideas from getting lost, and stop you selling things you haven't built.

Some of what's in Now doesn't need building yet. Paul Graham's essay Do things that don't scale makes the case for doing things by hand at first: setting up each customer yourself, sending reports as emails you write, handling the awkward cases personally. They're still roadmap items, and they're still part of delivering the first version. You'll learn far more about what customers need than any feature would teach you, and once something has earned its place, it moves into Next to be built properly.

Your turn: sort what you want to build into Now, Next and Later, using what the first version should include as a guide. Then go through Now and mark everything you could do by hand for your first ten customers.

When you build with AI, give the tool a clear brief. Say who uses the app, what each of them needs to do in it, the important rules and edge cases (what happens when a customer cancels halfway through a month?) and which features each plan includes. Write it from what you've learned with customers, and Lovable, Claude Code and developers will all do better work than from a one-line prompt and a lot of back and forth. That back and forth is also where most of the money goes, as what it costs to build an app with Lovable, Bolt or Replit explains.

Set up charging as you grow

A payment link or an invoice is enough for your first few customers.

Things get more involved as you grow. A customer with several sites asks for a price per site, or you want a higher plan with extra features, or you want to charge per user like Slack. That's packaging, and it's what we built Salable for. It handles pricing, payments and which features each customer can use, so you can change your prices and plans as you learn without rebuilding your app. It's free to start.

Keep an eye on cost to serve as well. If your product uses AI, every request costs you money, and a busy customer can cost far more than a quiet one. Your price needs to cover that.

What a good first month looks like

A good first month might be five conversations with people who have the problem, a rough version that two or three of them have tried on real work, a one-page website with a price, and at least one person paying or committed to pay. That's early evidence that a business could work.

It's a start, and the work carries on from there. A business takes shape as customers choose your product, get the outcome you promised and keep coming back, and as you find more customers like them. Customers change and new alternatives keep arriving, so keeping close to their world is the ongoing job.

If you've already built something, start with what to do after building your app. For answers to the questions founders ask most, see all the questions.

Here's how to start this week:

1. Write down your Business Hypothesis: your best answer for each of the five elements.
2. Choose the one thing you most need to find out.
3. Book five conversations with people who fit your customer, and ask about the last time the problem happened.
4. Put something real in front of them, like a rough version or a one-page website with a price.
5. Ask at least one of them to pay, then make sense of what happened and decide what comes next.