How to Start a Custom Software Project

Projects rarely come apart during the build. They come apart before it, in the part where nobody wrote down what the software was supposed to do. This is the order of operations that avoids that, and most of it is work you do yourself, before you talk to anyone.

Start with the problem, not the software

The instinct is to start picturing screens. Skip that. Pick one process that costs you something, and write down what it costs, in hours or in work you lose. The order is deliberate: a problem you can measure gives you a way to decide whether the software was worth it, and a way to stop if it is not.

If you cannot say what the process costs you, you are not ready yet, and that is a useful thing to learn before you go any further. Pick a different process or leave it for now.

If you are still deciding whether this is a software problem at all, part one of this series covers what custom software is and how to tell whether you need any.

Pick the smallest version worth using

A first version covers one process, for the people who do that process. Ask yourself what would be worth using on Monday morning, and build that. Everything else goes on a list for later.

This is the decision that sets your timeline and your price, more than any choice about technology. The projects that run for a year are usually the ones that tried to replace everything at once. The ones that land are the ones where somebody drew a line around one job.

Things that can usually wait: the second department, the reports you could pull by hand for a few more months, the connections to systems you touch twice a year, and anything you described with the words "and eventually".

Write down how the work runs today

This is the most useful thing you can prepare, and it is not a feature list. Nobody needs your opinion on the technology. They need to understand the job. Write down, or be ready to walk somebody through:

• The steps, in order. What happens first, what happens next, and who does each one.
• What you use now. Bring the actual spreadsheet, the paper form, the screen you copy from. Real examples with real data beat a description of them.
• The exceptions. Every sentence that starts "we do it this way, except when". These matter more than the normal path.
• The rules nobody has written down. The pricing judgment one person makes, the customer who gets different terms, the job that skips a step. A rule that lives in somebody's head is the thing that surfaces late and changes the work.
• What the customer sees, and when. Which parts of this are visible outside your business, and what they are waiting for.
• Where it goes wrong. The step that gets missed, the information that arrives too late, the thing you find out about a day after you needed to know it.

Involve the people who actually do the work, not only the person paying for the software. The gap between how a process is supposed to run and how it runs is where most of the useful detail lives.

Then pick who builds it

With the problem written down you can have the same conversation with several people and compare the answers, instead of comparing three numbers that each mean something different.

Three questions belong in the contract rather than in an email: who owns the code once the final invoice is paid, whose accounts it runs in, and whether another developer could pick it up. Part eight of this series goes through the rest of what to ask for and check.

Discovery is where the guessing stops

A quote given from a phone call is a guess. Discovery is the step that turns what you described into something specific enough to price and sign. It should end with three things you can hold: a written scope another person could read and understand, a firm price for the build, and something you can click, so you are reacting to software rather than to a document.

Expect to pay for it. Producing a prototype and a written scope is real work, and paying for it is the normal arrangement. Ours starts at $1,500, a fixed fee that is credited against the build if you go ahead, and it produces the prototype, the written scope and the build quote.

The best outcome of discovery is not always a build. Sometimes the scope comes back and the answer is that a product you can buy covers this, or that the process needs fixing before any software is pointed at it. Finding that out at the end of discovery is far better than finding it out at the end of a build.

Sign the scope and the price together

The scope and the number belong on the same document, signed before anyone writes software. A price with no scope attached cannot be held to anything, and a scope with no price is not a commitment.

Settle what happens when you change your mind, because you will. Ask how a change to the scope gets priced and approved, and what the payment stages are. Our builds start at $15,000, with the scope and the price fixed and signed before work starts.

Your job while it is being built

Signing is not the end of your involvement. The projects that go well have a customer who stays in the room.

• Name one person who can make decisions without calling a meeting.
• Answer questions in a day rather than a week. A blocked question stops work.
• Look at it early, while it is ugly and easy to change.
• Put it in front of the people who do the job, not only in front of yourself.
• Write new ideas on a list instead of adding them mid-build. The list gets read after version one is live.

Going live, and what you hold at the end

Going live means real work running through it, not a pilot that never ends. Pick a date, move one process across, and keep the old method available for a short while rather than forever. Running both permanently is how a system ends up half used.

When the last invoice is paid you should be holding the code, the documentation for deploying it, and the accounts it runs in. For our work, you own all deliverables on final payment, and you get the full repository transfer plus deployment documentation. No lock-in.

After that it is a tool you use and maintain, which is a different job with its own costs. Part nine covers maintenance and support.

The short version

• Pick one process and write down what it costs you.
• Describe how it runs today, exceptions included.
• Decide the smallest version worth using.
• Ask about ownership before you ask about price.
• Pay for discovery and get a scope, a prototype and a firm number.
• Sign the scope and the price together.
• Stay available while it is built, and keep new ideas on a list.
• Go live on real work, and take delivery of the code and the accounts.