Commissioning Software Without a Technical Co-Founder

The uncomfortable part of commissioning software is not the money. It is that you are buying something you cannot inspect, from people whose competence you cannot assess, to a specification you are not sure is right, and the first point at which you will definitely find out is months away.

Every piece of advice below exists to shorten that distance. None of it requires you to learn to program, and none of it depends on finding unusually honest people, which is not a strategy.

Decide what you are building before who builds it

Most first conversations with a supplier happen before the buyer has decided what the thing is, which means the supplier ends up deciding. They will do it reasonably and in good faith, and they will do it in the direction of what they are good at and what is comfortable to quote.

The decision that matters most is also the one most often skipped: whether you are building something to learn from or something to sell. A prototype exists to answer a question and should be disposable. A first sellable version has to survive contact with customers, which costs several times more and looks almost identical in a demonstration. Prototype or MVP is the clearest fork in this whole process, and getting it wrong costs a quarter either way: a prototype treated as a product collapses under real use, and a product built to answer a question is money spent proving something you could have learned in weeks.

After that comes scope, which is not a document for lawyers. Scoping an MVP without cutting what matters is the practical version, and the discipline it describes is subtraction: every feature in the first version delays the date you learn whether anyone wants it.

Enough language to not be managed

You do not need technical knowledge. You do need enough vocabulary that nobody can use words as a way of ending a conversation.

The specific failure to avoid is nodding. When an explanation does not land, the instinct is to accept it and move on, because asking feels like admitting you are out of your depth. In practice, suppliers who are good at their job are relieved when a client asks what something means, because an uninformed client is a source of risk to them too. A plain-English glossary covers the terms that actually come up.

One test is worth more than the vocabulary: ask for an explanation of a technical decision in terms of what it means for your business. Someone who understands their own recommendation can always do this. Someone who cannot is either guessing or has not thought about your situation, and both are useful to know.

Why nobody can tell you what it costs

The question every buyer asks first is the one that cannot be answered responsibly from a description. Software cost is not driven by the number of features, which is why two apps that sound identical can differ enormously.

What drives it is the number of states the system has to handle, how many other systems it must talk to, how bad a failure would be, and how many kinds of user exist. What actually drives app development cost goes through them, and what a booking system costs is a worked example of how something that sounds like a calendar turns out not to be one.

The practical consequence is that a precise quote from a vague description is not precision. It is either a guess with a margin built in, or a number that will be defended later with arguments about what was agreed.

Structuring the arrangement

Fixed price and time-and-materials are both legitimate, and the choice is not about budget size. It is about how well the work is understood before anyone starts. A defined piece with a clear edge can be fixed honestly. A first version of a new product cannot, because nobody knows enough yet, and fixing the price just means fixing a guess and padding it.

Fixed price or time and materials sets out both, and the arrangement that usually works in practice: a small fixed first piece that produces a plan, then the larger work under whichever model the plan has made honest. The property that structure has, which neither pure model does, is an early and cheap exit.

Three terms matter more than the pricing model, and all three are yours to insist on while you still have leverage. Who owns the code, with repositories under your accounts from day one. What happens at the end, including a handover somebody other than the author has performed. How changes are agreed, written down before the first one arrives.

Choosing who, when you cannot judge the work

Portfolios are weak evidence. You cannot tell from a finished screen who built it, how long it took, how much was rescued by somebody else, or whether it still works.

What you can judge is the sales conversation, which is a live sample of how they will behave when they are trying hardest to impress you. How to choose a development partner without being technical goes through this properly, and the single most reliable signal is the ratio of questions to assertions. A supplier who agrees with everything in the first meeting has not understood the problem, or has and is not telling you.

Ask what they would refuse to build. Ask what they think is the riskiest part of your idea. Ask what they would do if they discovered halfway through that the agreed approach was wrong. The answers tell you more about the next six months than any rate card or case study.

Knowing whether it is going well

This is where non-technical buyers are most exposed, because the usual signals are easy to produce without progress. Status updates, percentages complete and lists of tasks closed all describe effort rather than outcome.

There is one signal that cannot be faked: something working, that you can use yourself, at a regular interval. Not a screenshot, not a walkthrough on a call, but a link you open on your own device. If that exists every week or two from early on, you will know the state of the project continuously, and a supplier who cannot produce it is telling you something whether they mean to or not.

The corollary is to resist long stretches with nothing to try. A plan where everything integrates at the end is a plan where every risk is discovered at the end, and the end is the worst moment to discover anything.

If you are replacing something that already works

A large share of commissioned software replaces a spreadsheet, a paper process or an off-the-shelf tool that no longer fits. That situation has a specific trap: improving the process while rebuilding it.

The existing process is usually stranger than it looks and right more often than it looks, because its odd parts are scars from real problems. Replacing the spreadsheet that runs your business makes the case for copying it first and improving afterwards, when improvements can be judged against reality rather than argued about in a meeting.

Ending well, including badly

Plan the ending at the beginning, because the version where you part on good terms and the version where you do not require the same things: accounts in your name, a build that works without the author present, and a written account of how it is deployed.

If a relationship does end badly, the work of recovering is well understood and the order matters. What to do when a developer disappears covers it, and the short version is that access is harder to recover than software, so it comes first.

And if you are considering taking on something somebody else built, have it read before you commit a budget. What a code audit covers describes a few days of work that can save a quarter, which is the best return available anywhere in this process.

The three ways this usually goes wrong

Across projects that disappoint their buyers, the causes cluster. None of them is a supplier being incompetent, which is the failure people expect and the rarest in practice.

The first is building the wrong thing well. Everyone behaved professionally, the software works, and it turns out customers did not want it in that shape. The protection is not better project management, it is getting something in front of real users early enough that being wrong is cheap.

The second is scope that grew without anyone deciding to grow it. Each addition was individually sensible and nobody ever compared the total to the original intent. The protection is a written note of what the first version is for, revisited whenever something is added, so the question becomes whether this beats something already on the list rather than whether it would be nice.

The third is dependency that was never examined. The product works, the relationship is fine, and you could not continue without this specific supplier if you had to. That one accumulates silently and is entirely preventable by the ownership terms above, which is why they are worth insisting on even when everything is going well. Especially then, in fact: that is the only time you will have the leverage to ask.

What happens after it launches

Commissioning conversations treat launch as the finish line, and budgets are built the same way. It is closer to the halfway point, and the second half is cheaper but never zero, which is the part that surprises people who planned for a project rather than a product.

Some of the ongoing cost is unavoidable and has nothing to do with your product changing. The platforms underneath it move: mobile operating systems raise their minimum requirements on a schedule, browsers change, libraries receive security updates, and payment providers deprecate the way they did something two years ago. An app that is never touched does not stay the same, it stops working, and the first symptom is usually a store listing that can no longer be updated.

The rest is the work that only real users can reveal. The flows people actually struggle with, the device nobody tested on, the part of the process everyone does differently from how it was described. This is valuable work and it cannot be specified in advance, which is exactly why the budget should not be fully committed before launch.

So three things are worth settling while you are still negotiating. What support means in practice, stated as what gets responded to rather than as a response time you cannot verify. Who holds the keys to publishing, which should be you. And whether there is an agreed way to make a small change without opening a new commercial conversation, because a product where every fix requires a quote is a product that stops being fixed.

A reasonable supplier will raise all of this themselves. One who treats launch as the end of their involvement is either inexperienced or is describing a relationship you should price accordingly.