Software Development, Explained for Non‑Technical Founders

• You’re about to spend real money on something you can’t personally inspect. That, not the code, is the problem to solve.

• There are roughly seven phases. The two that get skipped are the two that decide whether the other five were worth doing.

• Half your arguments with a developer will be vocabulary. “Done”, “simple” and “MVP” mean different things on each side of the table.

• The build isn’t where the money goes. Most of what software costs over its life gets spent after it launches.

• You have a job on this project too. Decisions, access, and being the only person who knows how the business really works.

• One test outranks every status report: can you open the thing yourself, on your own phone, this week?

Most explanations of software development are written for the people doing it. Seven boxes in a row, a list of methodologies, an argument about which one is better. That’s fine if you’re going to write the code. It’s close to useless if you’re going to pay for it and can’t check a line of it. This is the other version.

Every firm draws the same diagram, and the diagram isn’t wrong. It’s just written as a list of activities rather than a list of things you actually receive. Here is the same sequence, described by what lands on your side of the table.

• Discovery. Someone learns how your business really runs, then writes it down. You get requirements, user flows, and a scope that states what is excluded as clearly as what is included.

• Design. What goes on each screen and what happens when people press things. You get rough wireframes first, then finished screens you can click through before a line of code exists.

• Architecture. The decisions nobody shows you: where data lives, what talks to what, what the system does when a third party goes down. You get a short technical plan you can’t evaluate, which is fine, because you can evaluate the reasoning behind it.

• Build. The coding. You get working pieces every week or two, not one reveal at the end.

• Testing. Not a developer checking their own work. You get a run against written acceptance criteria, on the devices your users actually hold, by someone whose job is finding what’s broken.

• Launch. Data moved across, accounts created, the old way switched off on a named date. You get a live system and a short list of what went wrong on day one, because something always does.

• Everything after. Fixes, changes, the integration that quietly changed its rules. You get most of the total bill, spread over years.

In practice this isn’t a straight line. Most teams run it in loops, designing and building and testing one slice at a time, and that’s usually better. Looping changes the order. It doesn’t remove any of the work.

Two phases get skipped, and it’s always the same two. Discovery goes first, because paying someone to talk and write feels like paying for nothing. It’s the phase that decides whether the price you’re quoted means anything, and skipping it is how a fixed number ends up attached to a scope that was a paragraph in a sales email. Testing is the other one, because it sits between the team and a date somebody already promised. What gets cut there doesn’t disappear. It moves into the phase where your customers find it instead.

A surprising share of project conflict is two people using the same word for different things and neither noticing for six weeks. These are the four that cost the most.

“Done”

To a developer, done often means the code is written and behaves correctly. To you it means a customer can use it. Between those two sit testing, deployment, moving the old data across, and somebody being trained. Ask what done includes, in writing, per item. If the answer is a shrug, that’s the finding.

“Simple”

You mean a small screen. They mean few decisions. One form field that has to check something against your accounting system, cope with that system being unavailable, and behave differently for three kinds of user is not simple, and the screen it lives on will look like nothing.

• “MVP.” You hear a cheap first version. It means the smallest thing that tests the riskiest assumption. If your MVP contains everything on your list, it isn’t one, and calling it that only makes the price confusing.

• “Integration.” It sounds like connecting a cable. It means agreeing what happens when the other system is slow, down, or has changed its rules without telling anyone. Most integrations are cheap to connect and expensive to make reliable.

The fix is the same in all four cases and takes ten seconds. Ask them to tell you what will be true when it’s finished, in one sentence you could check yourself without help. If they can’t say it, it isn’t defined, and undefined is the thing you pay for later. The same discipline works in the other direction when you’re the one asking for something, which is what a request a developer can act on looks like.

Most first-time buyers budget as though the build is the project. It isn’t, and the gap isn’t small.

The IEEE Computer Society’s SWEBOK Guide puts it plainly: maintenance takes a significant portion of the financial resources spent across a software’s life. What surprises people is what that maintenance turns out to be. The same guide reports that over 80 percent of it goes to non-corrective work, meaning not bug fixes. It’s changing a working system to fit a world that moved: a tax rule, a phone operating system, a supplier who altered their API, a process your own team changed in March.

Then there’s the bill nobody quotes. In 2022, CISQ put the cost of poor software quality in the US at a minimum of $2.41 trillion, roughly $1.52 trillion of which was accumulated technical debt. Technical debt is a plain idea with a technical name: interest on decisions taken quickly, paid later by whoever is still there. It won’t appear on a quote. It appears two years on, when a change that should take a week takes six.

So when you ask what custom software development for business costs, the useful question isn’t the number, it’s what moves it. Roughly in order: how many kinds of user there are, how many other systems it has to talk to, whether existing data has to come across, how much of the interface is genuinely new rather than conventional, whether it has to work on a phone or without a connection, and whether anyone did discovery before quoting. That last one changes the number less than it changes whether the number holds.

This is close to how we structure engagements ourselves. Scope gets defined before a price is attached to it, then the price is fixed, which is only a safe promise to make if the scope is real. You can see the shape of it on our services page, and the longer argument about why preparation protects you more than the contract type does is in the piece on fixed-cost versus hourly.

One thing worth saying plainly, because it’s the mistake that repeats: the cheapest quote is usually the most expensive project. You pay for it twice, once to build it and once to fix it.

Nobody pitching you has a reason to write this section. There’s a job on this project with your name on it, and it can’t be bought.

• One decision-maker. Not a committee that reconvenes fortnightly. Someone who can settle a question in a day and won’t be overruled next month.

• Decisions inside days. Do the arithmetic once. A two-day review that actually took nine days, four separate times, is a month of the delay you’ll be angry about later.

• Access. Accounts, credentials, sample data, and the one person in your business who understands the system you’re replacing. Withholding any of those stops work without looking like it stopped work.

• The domain knowledge. You’re the only one who knows about the exception that happens twice a year and breaks everything. Nobody discovers that from the outside, and it always surfaces late.

• Discipline about your own ideas. Adding something mid-build is allowed. Adding it without moving the date is not, and when the date doesn’t move, somebody quietly absorbed the work and the schedule paid for it.

• Someone to test it who isn’t you. You already know where the buttons are. You stopped being able to see it weeks ago.

If the honest answer to three of those is “not really”, the problem isn’t the developer. Replacing them reproduces it, several months later, with a restart cost attached.

None of these need technical judgment. You can run all of them from your phone.

• Healthy: you can open a working version yourself, on your own device, every week or two. Sick: screenshots, recorded walkthroughs, a demo somebody else drives, a percentage.

• Healthy: you hear a date is at risk the week before. Sick: you hear on the day, or you find out by asking.

• Healthy: you ask what’s blocking something and get a specific. The payment provider rejects test cards from Canada and their support hasn’t come back. Sick: you get reassurance. They’re on it. It’s a priority.

• Healthy: a change you ask for comes back with what it does to the date, before anyone starts it. Sick: changes get absorbed silently and the date is fine, right up until it moves by a month.

• Healthy: somebody has told you not to build something. Sick: every idea you’ve had has been a great idea.

The last pair matters more than it looks. A team that never pushes back either isn’t thinking about your business or has decided it’s cheaper to build whatever you ask for than to have the conversation. Both are expensive for you. The pre-signature version of this, the questions to ask before anyone starts, is in how to identify the right development partner.

Someone will tell you, probably while selling you something, that AI has made all of this faster and cheaper. Part of that is true, and knowing which part is worth more than the claim. Google’s 2025 DORA report, drawn from nearly 5,000 technology professionals, found 90 percent using AI at work and more than 80 percent saying it had improved their productivity. In the same survey, 30 percent reported little or no trust in the code it produces.

The finding that matters to you is the headline one: AI amplifies what a team already is. Strong teams get faster. Struggling teams get faster at struggling. Read that against the seven phases and it lands in an obvious place. AI has compressed the middle, where code gets written. It has done almost nothing to the parts that were already the bottleneck, which are deciding what to build, agreeing what done means, and having someone competent check the result. More code arriving faster puts more weight on testing, not less.

There’s a practical version of this for you. A working prototype can now appear in days, and that’s genuinely useful for finding out whether you want the thing at all. It’s a poor way to find out what it costs to run for three years, because it skips exactly the phases that always get skipped. Treat a fast prototype as a question answered, not as a head start on the build. The version of this argument aimed at established businesses rather than founders is in why legacy companies fall behind in the AI era.

Ask whoever is building your software for a link you can open on your own phone, without them on the call, showing what is finished right now. Not a demo. A link.

What comes back, and how fast, will tell you more than the next month of status meetings. A team that has one sends it the same day, because it already exists and they use it every day. A team that doesn’t will send a summary of effort instead, and that gap is the whole diagnosis. It takes no technical skill to read, which is the point.

If you haven’t hired anyone yet, ask each candidate what their discovery phase produces, in writing, before you ask what the build costs. The first answer decides whether the second one means anything. And if something is already built and you can’t tell what shape it’s in, our product readiness assessment runs that check in a structured way.